Re: Removal/replacement of DomainKeys-Status

[Jim F. <jf...@bl...>]

A little slow on the reply, but I don't think this point has been made
yet:

On Mon, 2004-07-12 at 16:12, Rand Wacker wrote:
> On Mon, 12 Jul 2004, Jos...@en... wrote:
> 
> > I'm integrating dk-filter results to my filter, to whiten or blacken
> > messages if information is available.
> 
> I would be very hesitant to use authentication results as a positive value
> in a spam filter.  Its not out of the question for spammers to
> authenticate themselves, and in the case of SPF, they already are.
> 
> Also, as has been pointed out, if SpamAssassin puts in a rule to look for
> a DK-Status header then spammers will just start spoofing it, as they did
> with Habeus and PGP already.

One likely use for the DomainKey-Status header is to allow a user, via
MUA filters, to apply his/her own policy, such as to file
unsigned/mis-signed messages into a "bulk mail" mailbox.  But the MUA
filters I'm familiar with (mostly Eudora) don't have a way to readily
base a decision on header order.

A more reliable/spoof-resistant way to do this would be to put the
verifying MTA name in the DomainKey-Status header and to strip out any
such headers with the same MTA name already in them.  The recipient
could then filter on the status and MTA name together, and could depend
on that result provided it trusts the verifying MTA and the path between
that MTA and the user is reliable (e.g., within a secure network).

-Jim