----- Original Message -----
From: "Devdas Bhagat" <devdas(_at_)dvb(_dot_)homelinux(_dot_)org>
To: <asrg(_at_)ietf(_dot_)org>
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. ;-)
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.
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(_at_)domain -> tripp
goodguy2(_at_)domain -> tripp
*(_at_)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.
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.
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.
Also, MUAs will need to be updated to allow for automagic addition of
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.
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.
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
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg