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 <mich...@talamasca.ocis.net> _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html