OT: SPAM filtering at the MUA? (was: Re: Support for 'folder' capability keys for Mutt. Assistence needed.)
On Mon, Feb 26, 2007 at 09:12:35AM +0100, Rob Meijer wrote:
> The 'mail capability key' or mck library is meant as an anti-spam solution
> using a 'folder extended' e-mail address as a capability key.
Isn't the MDA (i.e., procmail) and the MTA (i.e., qmail-inject) the correct
place to implement this? It might work something like this: {
MDA: {
A piece of mail comes in from the MTA. The MDA looks to see whether the mck's
been revoked; if so, it bounces the message, and aborts. Next, the MDA sets
appropriate header fields based on attributes of the mck in use. It then
delivers the message.
}; MTA {
A piece of mail arrives from the MUA. The MTA looks to see if the From
address has a valid mck; if not, it creates a new mck assigned to the
recipient of the message. It adds an appropriate header or two to annoy
recipients, and sends the message off to the MTA proper.
}};
Implementing equivalent functionality in the MUA, IMHO - even as an external
library, is bloating the MUA for something that isn't even its job (even worse
than the recent decision to bundle SMTP support into Mutt).
> The mck library aims to implements the concept of using key-extended
> e-mail addresses as capabilities in order to countermeasure the SPAM
> problem.
>
> The concept is that by using the folder notation <user>+<folder>@<domain>
> where instead of a regular folder we use a password capability, we can
> make e-mail addresses that can be used according to capability
> paradigms. That is, the e-mail address becomes a single unforgeable
> and sharable reference to the target, that can be revoked when at
> any time SPAM is received trough it, without the high impact of actually
> requiring a new e-mail address.
Note that many SPAMbots remove the SMTP resource (your "password") from email
addresses they send to their lists, so at best, this would only be a partial
solution. (In particular, you'd still need to deal with mail sent to
"user@domain" somehow.)
A more correct solution is to have "user" be a SPAM trap rather than your real
email addy, so "smart" SPAM bots end up getting the short end of the stick.
Also, make sure that the resource starts with something canned (say, 'pswd'), so
stupid SPAM bots that don't recognize '+' as a legit character in an email addy
(so "user+resource@domain" becomes "resource@domain" in their lists) can have
their mail redirected to user@domain, and trapped along with your other SPAM.
> The libmck library tries to implement the address as key in such a way
> that the following specifications are met:
>
> 1) A mailkey should be unforgeable.
> 2) It should be possible to trace back a mailkey to the entity to what
> it was originally issued.
> 3) It should be possible and simple to filter (revoke) 'all' mailkeys
> issued to a single entity.
> 4) It should be possible to trace back 'when' a mailkey was issued.
> 5) It should be possible to give a mailkey a certain validity period.
> 6) It should be possible and simple to filter (revoke) a single mailkey.
> 7) Sharing mailkeys as way of introduction should be encouraged, thus
> new mailkeys should be created in some quantities in communication with
> known peers.
> 8) It should be possible to use mailkeys with 'unpatched' mailing list
> servers.
> 9) It should be possible to periodically start using a replacement master
> secret key for mailkey generation without implicitly invalidating
> mailkeys generated with the old key.
> 10) It should be possible to 'petname' individual keys in order to keep
> track of keys used for introduction by peers.
If you control your own domain, aren't there systems that satisfy those
requirements already available, that are implemented in the server layer, rather
than at the client end?
HTH,
- Dave