> There are several known conflicts, as outlined in the appeal, > and they don't begin with "the sender intends". You appear to refer to: http://www.mhonarc.org/archive/cgi-bin/mesg.cgi?a=ietf&i=200508250045.27 704.julian%40mehnle.net * Many mailing lists rewrite the MAIL FROM identity when distributing messages, but do not change the header (PRA) identities. And they are not required to do so by RFCs 2821 or 1123 or any other current IETF standards. * Many organizations with their own domains outsource their bulk message sending (newsletters, etc.) to ESPs, who use their own domain in the MAIL FROM identity and the organization's domain in the From: header, but do not add a Sender: header.[12] * If the MAIL FROM is empty ("MAIL FROM:<>"), the MAIL FROM identity, as defined by the SPF specification, falls back to HELO identity[5, section 2.2], while the PRA identity is usually unpredictable. The first is simply a KNOWN FAILURE MODE of Sender-ID. The PRA check is known to fail in certain circumstances, just as the SPF check is known to give false positives. In both cases the overwhelming number of false positives come from poorly maintained records, not the internals of the protocol. The second is also a known failure mode of the PRA check. That is why the bulk mail senders have been adding Sender-ID records and adding From: headers. Paid bulk senders that have not fixed this already went out of business. PRA comaptibility is a checklist compliance item in all RFPs for that type of business. If you want to send bulk email you already have to meet this criteria, PRA checking is already live at several anti-spam vendors and it is not going to be turned off. The final case is one that Lyon and others strongly assert should be handled by a BATV type mechanism. Treatment of bounce mail is outside the scope of PRA because it can be handled much more effectively by other means. Since all these 'failures' are simply known properties of the PRA check there is absolutely no value in changing the version string. The PRA implementations are certainly not going to follow this advice if it is made. All that the IESG would achieve is to further confuse and complicate deployment of SPF/Sender-ID by giving advice that is ill-founded. Only the receiver of an email has any right to decide how their spam filter is going to work. The purpose of SPF is to provide the sender a mechanism that helps them to pursuade the recipient to receive the email message. The way that all email authentication checks work in practice is to look for any form of evidence that would allow the mail to be whitelisted. The fact that an email message might fail a particular test is irrelevant, the receiver is trying to help the sender to pass. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf