On Tue, 2 Jul 2013, Alessandro Vesely wrote:
That's off in the weeds. EDSP would not take any notice of i=, and is
not there to enhance SRS -- rather it's something of a competitor. (Both
try to make return path validation work in spite of forwarding.)
The point is what any of them might be useful for.
It's about deployability.
Many mail filtering strategies are not deployable widely even assuming
the smartest possible mail admin and perfect MTA software. They require
the cooperation of the end user in order to work properly.
I classify the strategies into three tiers.
On the first tier, you have things like Spamhaus ZEN, which can be
deployed across all users at a domain, without any knowledge of the
end-users habits.
On the second tier, you have things like Distributed Checksum
Clearinghouse, which require some information about the end-user's
habits in order to work properly. For DCC and most other second-tier
methods, this is a complete whitelist of their mailing list
subscriptions. Without the whitelist, DCC will correctly notice that
the mailing lists are bulk, and incorrectly assume that they are
unsolicited bulk.
On the third tier, you have things that require additional sacrifice (or
great arrogance...) on the part of the user. One third-tier approach I
personally use is blocking all HTML e-mails (including
multipart/alternative).
(I get away with that because I give any corporate entities I actually
wish to hear from special canary-trap addresses that aren't so
filtered.)
Anti-forgery mail filtering methods are special in that they have
separate receiverside and senderside components. Unless both components
are present, they will always false-negative.
(Note: below I'm counting "?all" SPF records as "not deploying SPF
senderside", and ADSP/DMARC policies that do not recommend rejecting
mail as "not deploying ADSP/DMARC senderside". Those configurations may
be useful but don't facilitate an easy decision to reject an e-mail.)
ADSP and DMARC are tier 1 on the receiverside and tier 3 senderside.
Not many domains can make the claim that no mailbox in them participates
in any mailing list.
SPF is supposed to be tier 2 on the receiverside (needs a forwarder
whitelist) and tier 1 on the senderside.
SRS is a failed attempt to make SPF tier 1 on the receiverside. SRS's
backers encouraged receivers to act as if it was already fully accepted
and deployed, in order to pressure forwarders to cooperate or face false
positives. But instead, this led many senders to avoid those same false
positives by treating SPF as tier 3 on the senderside.
A trick using VERPing (of which SES is a brand) can be used to make SPF
tier 1 senderside again despite the damage done by SRS. That requires a
special dynamic DNS setup, however. VERP also has a cost in that
whitelisting is made harder for the recipient.
"EDSP" would be tier 1 both senderside and receiverside. That's its
selling point.
The "dkim=except-mlist" ADSP enhancement I suggested back in 2011 would
be tier 2 receiverside and just-slightly-below tier 1 senderside. It
would not be obsoleted by "EDSP" or SPF, because when it can be
deployed, it can stop some messages where From: is forged but MAIL FROM
isn't. Although slightly less than ADSP or DMARC in the rare case that
those are deployable senderside.
TPA ADSP enhancements are tier 1 receiverside and just-barely-above tier
3 senderside. They could be as powerful as except-mlist in terms of
false-negative rate where deployed at both ends, but require much more
elaborate setup work at the sender.
---- Michael Deutschmann <michael(_at_)talamasca(_dot_)ocis(_dot_)net>
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html