Comment Run Away! (Score 1) 316
Some spam will inevitably get into the MUA, after all, the end user is the one who has to initially identify spam.
Here is my proposal: Run Away. How? There is a new, but improperly implemented (so far) email addressing standard called plus addressing, where your address is like "user+box@host" where the "+box" part is supposed to be ignored yet passed on from the MTAs and MDAs to the MUA.
Unfortunately, some ISPs still bounce this kind of addressing as unrecognized, even if "user@host" is a valid email address. If you think of the plus addressing part ("+box") as a personality (in Eudora parliance) then your email address now can be filtered into as many pieces as you need.
Now, when I asked a couple of ISPs why my envelope recipient (RCPT TO: part of the SMTP protocol) isn't in any of the headers on a BCC email, I got an answer like "well, if it got to your mailbox, it's for you," but with this new addressing paradigm there remains the question of which me? i.e. which personality does the email belong to? so that argument needs to be thrown out the window.
I have read that some ISPs have recompiled their MDAs to include a header like "Envelope-to" or "Delivered-To" or "Envelope-to" or "rcpt-to" (all optionally preceeded with an (X-") but not mine, of course. If my plus address were included in a header like this, I could easily filter all bcc email to personalities I want, and then force the spammers to use it.
A really good ISP would allow me to upload a list of plus addresses that were allowed, and block everything else at the RCPT TO stage of the SMTP protocol (it might also provide end users with some Eudora, etc. plug ins to better manage personalities, signatures, addresses and filters as a personal information management (PIM) with one personality per contact.)
If the spammers guessed one, I could simply give another one to the person who communicates to that personality, and turn off (or send to bitbucket, or report as spam) all future communications to the compromised personality.
I found one through another post here on slashdot that pretty much allows me to do this: I filter every contact based on the Envelope filter, which they make available via their web interface, at fastmail(DOT)fm.
They're still working on the PIM idea, but what they have works; I can even get their Sieve filter to bounce my "user@host" address and still let all my plus addressing through.
I still think in the SMTP protocol, you could let an end user let SMPT refuse a RCPT TO their user@host address and accept RCPT TO to an end user defined list of user+box@host addresses. Why not!?
Here is my proposal: Run Away. How? There is a new, but improperly implemented (so far) email addressing standard called plus addressing, where your address is like "user+box@host" where the "+box" part is supposed to be ignored yet passed on from the MTAs and MDAs to the MUA.
Unfortunately, some ISPs still bounce this kind of addressing as unrecognized, even if "user@host" is a valid email address. If you think of the plus addressing part ("+box") as a personality (in Eudora parliance) then your email address now can be filtered into as many pieces as you need.
Now, when I asked a couple of ISPs why my envelope recipient (RCPT TO: part of the SMTP protocol) isn't in any of the headers on a BCC email, I got an answer like "well, if it got to your mailbox, it's for you," but with this new addressing paradigm there remains the question of which me? i.e. which personality does the email belong to? so that argument needs to be thrown out the window.
I have read that some ISPs have recompiled their MDAs to include a header like "Envelope-to" or "Delivered-To" or "Envelope-to" or "rcpt-to" (all optionally preceeded with an (X-") but not mine, of course. If my plus address were included in a header like this, I could easily filter all bcc email to personalities I want, and then force the spammers to use it.
A really good ISP would allow me to upload a list of plus addresses that were allowed, and block everything else at the RCPT TO stage of the SMTP protocol (it might also provide end users with some Eudora, etc. plug ins to better manage personalities, signatures, addresses and filters as a personal information management (PIM) with one personality per contact.)
If the spammers guessed one, I could simply give another one to the person who communicates to that personality, and turn off (or send to bitbucket, or report as spam) all future communications to the compromised personality.
I found one through another post here on slashdot that pretty much allows me to do this: I filter every contact based on the Envelope filter, which they make available via their web interface, at fastmail(DOT)fm.
They're still working on the PIM idea, but what they have works; I can even get their Sieve filter to bounce my "user@host" address and still let all my plus addressing through.
I still think in the SMTP protocol, you could let an end user let SMPT refuse a RCPT TO their user@host address and accept RCPT TO to an end user defined list of user+box@host addresses. Why not!?
