Re: OT: SPAM filtering at the MUA? (was: Re: Support for 'folder'
On Mon, February 26, 2007 14:39, Dave wrote:
> 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).
Sounds reasonable for most parts. I guess it may be possible to write
a set of two filter programs for adding and/or rewriting headers that
could do most of the trick. (Is it possible to configure from a single user
* incommingMail -> mckin -> procmail
* mutt -> mckout -> qmail-inject
If so that would be great, I could let mckout create or rewrite the
Reply-To header with an appropriate key, and could let mckin add a set
of 'X-Mck-' headers that the procmail config could filter on and/or the
user could interpret as such:
X-Mck-Invalid : indicating why the key is invalid (missing,bad-format,
bad-secret-id,bad-digest,expired,revoked,banned)
X-Mck-IssuedTo: The mailbox of the person the key was originally issued to
X-Mck-Petname: A pet name the user has set for this key.
X-Mck-RevokeCount : The number of keys that were 'revoked' for the given
'IssuedTo' value, useful to let the user determine if
to revoke the key used for spam, or to bann 'all' keys
that this entity may have been issued.
There would however still be two important things still missing to make
the concept work with a pleasant user experience that make me think the MUA
should still play an essential role.
>From a user point of view it would be convenient to be able to be able
to ban (issued-to) or revoke (key) as a result of a received spam
message from the MUA.
Second, if mail comes in where the key was delegated (and thus the sender
and issued to differ) and thus used for the very first time, it would be
convenient if the user would be able to set or update the pet name for the
key to reflect this delegation.
Rob