Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Dec 13, 2005, at 11:07 AM, wayne wrote:

However, his complaints could not have possibly had any impact on the current limits in the SPF spec.

The reduction to 111 DNS lookups is not a resounding impact with respect to this concern. Defending this sequential lookup requirement will likely never be tested, as it must become an impediment for abusers first. Abusers remain a substantial portion of the initial adopters. SPF will not likely become a replacement for black-hole lists, but instead may be used to implement unfair reputations based upon email-address domain owners authorizations. This problem is a good reasons for ensuring scope is defined.

SPF is not about validating the purported author of a message. SPF deals with forged return-paths. For this protection, SPF depends upon wide adoption by others before a benefit is obtained, hence the reluctance to correct the lack of scope. BATV, on the other hand, provides immediate benefits when forged return-paths are used in DSNs (the only place where a return-path is intended to be used). This forged return-path technique is often used to evade black-hole lists. Even with BATV, there are about 6 packets exchanged without any data phase for the message, which pales against the benefits obtained from a black-hole list which often limits the exchange to no more than four when an error message is returned.

Without BATV, another 8 to 30 exchanges often occurs with a forged return-path DSN where content is commonly returned. The DSNs must be filtered as the forged return-path has become a common exploit. The heavy filtering of DSNs is troubling as this will reduce the integrity of a store and forward SMTP system. One of the greatest benefits of store and forward scheme is efficiency. Holding open a session with the upstream server to check acceptance or for AV and Spam filtering completion, is not optimal. BATV does not require any additional DNS lookups or published DNS records. The BATV tag is transparent and can be handled by all existing MTAs. BATV offers the same challenges as any authentication scheme, where the admin must know where all their outbound MSAs are located for the domain that wishes to filter BATV tags at the MDA. If the admin misses an MSA, or a sender uses the wrong MSA, only the DSN would be at risk.

The forged DSN is a serious problem. Castigating those willing accept email on good faith and then issue DSNs is counter to establishing either integrity or efficiency. Making the forged return-path exploit not offer any value for the sender is what _must_ be done. There are black-hole list protections at the front-door, but no protections at the back-door. At this point, ensuring common acceptance criteria upstream is the only sensible stop-gap measure. Something like BATV can return integrity and efficiency to SMTP. SPF does not offer an efficient model going forward, and is in jeopardy of establishing a wholly unfair reputation scheme based upon authorization and not the actual sending of messages.

-Doug


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]