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

[Devdas Bhagat <devdas at dvb.homelinux.org>]

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.earthlink.net, 
> tripp+listb at corp.earthlink.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.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.homelinux.org would be a legitimate address, but
devdas+foo at dvb.homelinux.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.homelinux.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.org
https://www1.ietf.org/mailman/listinfo/asrg