ietf-asrg
[Top] [All Lists]

Re: [Asrg] Please critique my anti-spam system

2004-12-05 14:11:54
On 05/12/04 15:07 -0500, Tripp Cox wrote:
I've been thinking a bit more recently about schemes like this, and they 
generally revolve around the practice of giving the recipient some kind of 
unique namespace and permitting them to create as many names within that 
space as they wish.  This creates the potential, but not the necessity, for 
the recipient to use one-time or disposable email addresses.  The most 
common suggestion in this realm is to use context indicators in the local 
part of an otherwise static local part.  For example, I might subscribe to 
mailing lists as tripp+lista(_at_)corp(_dot_)earthlink(_dot_)net, 
tripp+listb(_at_)corp(_dot_)earthlink(_dot_)net, etc.

Another approach I personally have been using more recently is this: give a 
single recipient a domain and deliver email to any address within that 
domain to the user.  If anyaddress(_at_)personaldomain(_dot_)name is valid, 
the user 
quickly becomes trained to reject any incoming messages that aren't part of 

This isn't really all that useful. While the first suggestion of using
plussed addresses is good, it doesn't really prevent spam from hitting
the mailbox. What it does offer is a whitelistable set of addresses
within the namespace of a single mailbox.

Instead of having a catchall, a better technique is to make it really
easy for the user to be able to create such mail addresses. However, in
scenarios where the user uses their ISP address instead of using a
vanity/personal domain, this would not work. For such cases, it might be
useful to allow the user to specify a list of valid plussed addresses
they wish to accept mail for.

For example,
devdas+asrg(_at_)dvb(_dot_)homelinux(_dot_)org would be a legitimate address, 
but
devdas+foo(_at_)dvb(_dot_)homelinux(_dot_)org would not. 

Now all that is needed is an easy way for the user to manipulate the list 
of valid extensions. However, this leads to problems about mail sent to
the parent address, devdas(_at_)dvb(_dot_)homelinux(_dot_)org in the above 
example. 
Also, MUAs will need to be updated to allow for automagic addition of
plussed addresses into the From: header and/or reply to.

<snip>
Generally speaking, this is sort of a shared-secret approach with a unique 
context for each relationship.  The pain factor for both the sender and 
receiver to change the shared-secret is very low, because each sender has a 
unique shared-secret and the recipient can grant and revoke them at will. 
The pain factor for the spammer is high.  They have to find a valid context 
the recipient is willing to accept, and if they violate his or her concept 
of appropriate use of that context, they will find the context quickly 
revoked.

Both these assume that the recipient user is competent and will follow the
rules. That assumption has repeatedly been proven false. There is simply
too much work involved in these cases for this to become popular with J.
Random user of Hotmail, or Yahoo, or mail.com.

Devdas Bhagat

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg