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.