ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Draft summary of SSP functionality

2007-12-06 09:48:42
Dave Crocker wrote:
 Do envision a reasonable scenario where a receiver has adopted SSP and
conforms to it, but does not have the stated sender enforcement request
override the reputation assessment for a signer?  Note that this either
implies or explicitly violates the request of the SSP domain owner.

Could you provide some examples of such scenarios?

Yes, trivially. Look at the way Spamassassin works. It grades various
message features numerically where positive is spammy and negative is
hammy. Were Spamassassin to incorporate SSP information, I would expect
that -- just like their use of DNSBL's -- SSP might be like:

SSP_STRICT_FAIL = 4
SSP_ALL_FAIL = 2
SSP_UNKNOWN = 0

Where you need to get to 5 to be declared spam. A 4 score is usually
a death sentence for a message, but not necessarily. An all fail means
essentially that the message better be on its best behavior.

Spamassassin actually tunes these numbers using their message corpus
to get acceptable false negative/false positive rates. Lots of other
spam filters work essentially the same way. That is, they don't count
on silver bullets whatsoever. SSP used in this way is *exactly* the
right kind of information that a spam filter wants: more, and
*reliable* (fsvo reliable), information so that can make a better
estimate.

        Mike

PS: note that this is the reason I'm dubious to hostile to the addition
    of the new "disposition" stuff in the SSP record. I don't think it
    provides anything new or useful, and in fact leads to the
    possibility of silly states like strict/pass.
_______________________________________________
NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html