h a l f b a k e r yFaster than a stationary bullet.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
Please log in.
Before you can vote, you need to register.
Please log in or create an account.
|
For long email recipient lists: a slash (/) before the name means: DONT SEND TO...
e.g. In the To: textbox you put: MyCompanyGroup //Albert
That way even if the name somehow mistakenly entered the list, it will be removed.
Two advanced features would be:
a. When a slash is detected,
always show a popup with the full list of names, mark names removed with a strikethru font, allow editing, and ask if we wish to continue.
b. "Did you mean...": Optional setting for names _SIMILAR_ to what you wrote, so that if you put /Pandansky it would highligh Pandanski in the popup.
(You usually are not sure what the exact email of the people you DONT want to send to, is...
Did you mean...
_22_20Do_20you_20me...HIS_20Marc_3f_20_22
[normzone, Mar 10 2016]
[link]
|
| |
There could also be a "don't reply to" symbol so that if someone hits Reply All, they end up not. |
|
| |
Good idea. Where I work, we sometimes get emails saying "Arthur is leaving; If you'd like to sign Arthur's leaving card, etc., etc." - and in order to send this to the 'global' email distribution list without Arthur seeing, his nme has to be removed from the list just to send this one email. [phundug]'s idea is good too - [+] for both of them. |
|
| |
After observing the situation Hippo describes, I was about to post this idea. You beat me to it, by a few years. [+] |
|
| |
A great idea ([+]), but too text based, I think, for my
organization, which assumes (rightly, sad to say) that most
people require thick layers of GUI between them and the
part of the software that actually does something.
If it
were ever implemented, instead of a single extra
keypress, it would involve three levels of submenus, a
couple of attractive but indecipherable icons, and an
animated paperclip (The deluxe version would have a
professional trainer from IT who insists on scheduling a
half hour appointment to teach you how to use your email
client). |
|
| |
2013 still not implemented. Anybody know how to
make an addon to chrome for gmail? |
|
| |
The problem is that server side email distribution lists
won't respect this. Even if you wrote a client side plugin to
handle the local case, sending mail to a listserv or
something like that would still result in the email going to
the intended non-recipient. |
|
| |
To really get this to work, I think it would have to be
adopted as part of the SMTP standard. Basically, the
DontSendTo field would need to be preserved whenever a
copy of the message is delivered, and the receiving SMTP
server would be responsible for refusing the message (or
silently discarding it) if the RCPT TO: matches an address
listed in that field. |
|
| |
Since custom fields (known as X-headers) are permissible in
SMTP, this is eminently doable with a simple procmail rule.
The trick is getting everyone to do it. |
|
| |
No, I'm looking for a client side pre-processor.
Removes the unintended recipient in advance,
before sending. |
|
| |
A chrome plugin could work for any web based email
(webmail) site, or for specific websites (MS OWA or
Gmail for example) |
|
| |
OR if I get this feature implemented in an email
client, that client would have the feature. |
|
| |