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

From: "Michael Kaplan" <[email-masked]>
Date: Sun, 05 Dec 2004 14:21:41 -0500

----- Original Message -----
From: "Matt Schneider" <[email-masked]>
To: [email-masked]
Subject: Re: [Asrg] Please critique my anti-spam system
Date: Sun,  5 Dec 2004 18:28:10 +0000 (GMT)

Almost every criticism you have is answered in my article, but I will repeat the points.

> 
> 
> Hello, there is a standardized reply form out there for these sorts 
> of things, but I couldn't find it right away.
> 
> Anyway, I see several problems with this:
> 
> - the sub-address doesn't add anything, it's no different than 
> making up a new email address

If you made up a new email address then people who use your old address cannot contact you.  With my system you never fear losing contact because of an address change.

> - without using this system, you can already set up an 
> autoresponder on old addresses to let people know where to find you

A spammer could easily harvest your new adddress from the autoresponder.  Spammers don't bother since so few people do this now.  My system is designed to be used by a billion people and still remain secure.

> - I don't like that you're supposed to spam everyone you know and 
> they're supposed to immediately drop everything and go change you 
> in their address book (and this expects that grandmothers that are 
> just getting the hang of their AOL will be able to figure this out 
> or even understand what this all means).

Each individual can decide for themselves whether to activate this system or not.  I assume you are talking about what happens the first time someone activates this system.  Everyone on your contact list is sent your new email address, but you can elect not to have this initial mass mailing.  Remember, these people are white listed so their emails will get through even without a sub-address.  Grandma can send you email using your old address, she'll just be sent a reminder to update her address when she sends you an email without a sub-address.

> - white listing is nothing new

Whitelisting in this context is completely new.  

> - challenge/response is nothing new

This is not challenge/response, this is far superior.  I clearly contrast these two systems in my article.

> - if you want to not burden your friends with an initial 
> challenge.. instead of spamming them to change the email address 
> they have for you (still a burden) then why not add everyone in 
> your address book to the "already passed the challenge procedure" 
> list ?

The only people who ever need to decode a CAPTCHA are people who are not using a valid sub-ddress and who are not on the white list.  

> - CAPTCHA assumes everyone using this system speaks English.

My CAPTCHA usuable across all languages.  People almost always communicate via email with people who can read the same language.  Correspond with someone who has Chinese as their default language and the instructions for the CAPTCHA will be in Chinese.  There are additional logical ways that the language issue will be addressed.

> - As soon as a spammer starts getting CAPTCHA responses, they will 
> fire these off to a sweatshop in China or India to have them 
> solved, then they will have live, valid e-mail address, with 
> complete sub-address, that they can now sell to other spammers at a 
> premium.

See the second yellow highlighted text block in my article to understand why this is not feasible.

> - Nobody's going to upgrade their own SMTP servers to process 
> bounces from every anti-spam system out there.

No upgrade is needed.  The upgrade I proposed was for convenience.  Servers today are already fully compatible with my system.

> 
> Let's say I send out 2 inquiries to sales departments about buying 
> something.  If one of them sent back this CAPTCHA thing, I probably 
> wouldn't even bother jumping through all the hoops, I'd just go buy 
> from the other place.  The moral of this story is, this system 
> can't be used by anyone who places any sort of value on receiving 
> email from non-spammers.

I highly doubt that a sales department would routinely distribute an email address with a deactivated sub-address.  Remember, my system intergrates perfectly into the current email system.  Traditional email addresses will still function, and an email address with a valid sub-address will function exactly like an ordinary email address.

Michael G. Kaplan

P.S.  Can someone let me know the proper way to respond to these emails.  I've been hitting reply and then I've CC'd [email-masked] but when I do this I notice when I got to the discussion board archive thread index that you can't tell which email I'm responding to.

-- 
_______________________________________________
Find what you are looking for with the Lycos Yellow Pages
http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: "Tripp Cox" <[email-masked]>
Date: Sun, 5 Dec 2004 15:07:10 -0500

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 [email-masked], 
[email-masked], 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 [email-masked] is valid, the user 
quickly becomes trained to reject any incoming messages that aren't part of 
a known context.  At the same time, the recipient can use the context 
provided on all messages accepted to get visibility into how the sender 
obtained permission to communicate with them.  This has the benefits of 
challenge-response, but completely eliminates the need for challenges.  The 
only address I have is one I've given out, and those are generally dedicated 
to a specific context.  If you try to contact me within a fabricated 
context, I won't entertain it.

So, I start off with a clean slate with personaldomain.name.  I registered 
the domain with godaddy.com, so I tell them to contact me at 
[email-masked].  I tell my mom that my email address is 
[email-masked], Google uses [email-masked], ASRG uses 
[email-masked], etc.   At a point of critical mass, spammers would 
start social engineering and spam everyone at [email-masked], 
assuming a majority of folks have a relationship with Yahoo.

When that happens, the user would just have to set a new context with that 
sender by changing their email address.  Fortunately, this does not impact 
any of the other senders with whom the user has established a communication 
context.  In this case, you could tell yahoo to use 
[email-masked] if you wanted to get really 
obscure about it.

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.

You don't need CAPTCHA to do this, and you don't have to bounce mail sent 
within an unknown or revoked context.  It is deliverable; the user just 
refuses to accept it.

----- Original Message ----- 
From: "Michael Kaplan" <[email-masked]>
To: "Matt Schneider" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, December 05, 2004 2:21 PM
Subject: Re: [Asrg] Please critique my anti-spam system

> - challenge/response is nothing new

This is not challenge/response, this is far superior.  I clearly contrast 
these two systems in my article.

> your address book to the "already passed the challenge procedure"

The only people who ever need to decode a CAPTCHA are people who are not 
using a valid sub-ddress and who are not on the white list.

> - CAPTCHA assumes everyone using this system speaks English.

My CAPTCHA usuable across all languages.  People almost always communicate 
via email with people who can read the same language.  Correspond with 
someone who has Chinese as their default language and the instructions for 
the CAPTCHA will be in Chinese.  There are additional logical ways that the 
language issue will be addressed.

---

From: Devdas Bhagat <[email-masked]>
Date: Mon, 6 Dec 2004 02:26:15 +0530

> 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,
[email-masked] would be a legitimate address, but
[email-masked] 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, [email-masked] 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>
> of appropriate use of that context, they will find the context quickly 

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

---

From: John Levine <[email-masked]>
Date: 5 Dec 2004 23:14:55 -0000

>give a single recipient a domain and deliver email to any address
>within that domain to the user.  If [email-masked] is
>valid, the user quickly becomes trained to reject any incoming
>messages that aren't part of a known context.  At the same time, the
>recipient can use the context provided on all messages accepted to
>get visibility into how the sender obtained permission to communicate
>with them.

This is an often-used technique, and it works well so long as you
don't have unrealistic expectations.  I registered johnlevine.com five
years ago and ever since then I've been using [email-masked]
addresses whenever I sign up on a web site for something.

For my other users who are less vain than I am, I've done per user
subdomains, so mail to [email-masked] turns into
[email-masked] which qmail handles via its normal subaddress
mechanism.  This was really easy, one line of wildcard DNS and about
two lines of mail script to translate the addresses.

This scheme has a variety of advantages.  When I sign up at a place
like nytimes.com that sends newsletters, I can route the newsletters
directly to an appropriate mailbox.  When I get mail from other
places, if the recipient address matches the sender, I have a strong
indication that it's legit.  (Often I think it's spam, then I see the
address and I remember why it's OK.)  If they don't match, I know who
leaked it.  If an address gets a lot of spam, I can turn it off or
reroute it to the spamtrap.

I don't find per user addresses useful for individual correspondents.
Partly that's because there's no reasonable way to tell each
correspondent to use a separate address, partly it's because
individual correspondents rarely leak addresses to spammers.  (They
may get viruses, but that's a separate problem.)

There have been a few projects to issue and handle unique addresses
automatically.  The best I know about is Reflexion,
http://www.reflexion.net/, which apparently has lots of happy users.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
http://www.taugh.com

---

From: "Tripp Cox" <[email-masked]>
Date: Sun, 5 Dec 2004 19:18:39 -0500

----- Original Message ----- 
From: "Devdas Bhagat" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, December 05, 2004 3:56 PM
Subject: Re: [Asrg] Please critique my anti-spam system

> This isn't really all that useful.

Well, I've certainly found it useful, but let's explore. ;-)

> [email-masked] would not.

Agreed.  We're talking about domains in the most general sense: unique 
namespaces.  You could apply this by using tertiary Internet domain names 
and/or modifcations to a single unique identifier for the recipient in the 
local part (e.g. user+foo).  Either way, there's a 1:1 destination to 
recipient ratio and a many-to-one address to recipient ratio.

In any case, the static part of the address is by definition a catchall. 
The only question is whether or not you do anything with the stuff that is 
addressed without a variable context.

Using Internet domain parlance:
goodguy1@domain -> tripp
goodguy2@domain -> tripp
*@domain -> /dev/null OR tripp w/ extra filtering

When all is said and done, this doesn't make it easier to separate desirable 
mail from undesirable mail.  What it does do is permit you to grant and 
revoke permissions using a token or "key."  This forces accountability on 
senders in the way they handle your email address, because unauthorized use 
of a key means that it has been compromised either by brute force (guessing) 
or by willful disclosure.  In either case, the penalty is swift, severe, and 
there is little collateral damage: revoke the priviliges for the variable 
part.  In today's completely static email address usage, revocation is a 
costly and burdensome process.

> the parent address, [email-masked] in the above example.

What to do with that is a matter of personal choice.  I've started with a 
clean namespace and have chosen to ignore by default anything not bearing an 
authorized context.

> plussed addresses into the From: header and/or reply to.

This is a very real hurdle to making a move in this direction.  One way to 
ease the transition could be to apply a default context to everything you 
send out.  This will enable you to distinguish between replies to 
communications you initiate and messages absent a valid context.  If your 
default context starts getting abused, you can revoke it and create a new 
one.

Let's say I used YYYY.mm as my context for outbound email.  If I revoke 
those after three months, they don't remain valid in perpetuity for the 
spammers to abuse.

> Random user of Hotmail, or Yahoo, or mail.com.

Spam is a social problem.  Some amount of retraining is going to be required 
to eliminate the annoyance of spam.  Receivers need to be retrained to 
manage how they share their addresses.  Senders need to be retrained to 
respect the wishes of those who share their addresses with them.  If 
recipients and their trusted senders don't give addresses to spammers, the 
spammers are left playing an increasingly unwinnable guessing game.

Sure, we could do this without tokens or other forms of sender/receiver 
permission schemes.  One way to do that is to white list based on the 
sender's identity.  The shared secret in this case is often unknown to 
either party.  I know how to address you, but I don't know how to ensure 
delivery.  What we're talking about here is making the "how do I address 
you" and "how do I ensure delivery" the same.  We're essentially adding a 
password to our email address.  Well, an unlimited number of them at-will, 
and a kind that is easy to grant and revoke.

Keep in mind that this isn't for everyone.  I am of the opinion that Spam 
isn't a significant enough problem for most people that they'd be willing to 
change their behavior.  Challenge-response isn't for everyone, but it is 
damn effective.  It has the potential to be network unfriendly, which can be 
solved by using recipient tokens rather than sender addresses as the 
whitelist fodder.  Not that they need to be mutually exclusive, but you 
*could* eliminate challenges.  If someone knows how to address you, then 
they'll have a key of some type, if we use a recipient-bound variable 
context identifier.  The only question is whether or not you like it.

Tripp