David MacQuigg wrote:
Is this failure due to fundamentally incompatible methods,
or due to a failure of the standards process?
Neither nor. MARID found a clean way to solve this problem,
sp2-0/mfrom IsNot (pat.pend.) spf2.0/pra (pat. pend.)
spf2.0/mfrom,pra or spf2.0/pra,mfrom are allowed. Of course
there are many arguments against PRA, e.g. what Bruce said
here about reordered Resent-* header fields.
What if the standard said each method could have its own
label and record format
They (MARID) came to this conclusion and then closed the WG.
The "bug" in the standards process is RfC 3710 chapter 4.3
(WG Termination) which does not reflect RfC 2418 chapter 4.
That's where the IETF dropped the ball, but there were a
lot of fouls before. Later Sender-ID tried again to abuse
v=spf1 policies, and SPF said again "thanks but no thanks".
The LMAP methods like SPF, CSV, BATV, etc. were "off topic",
MARID wasted its time with XML-over-DNS and patent issues.
At least "mfrom IsNot pra" was clear in the last MARID days.
If the dk1 folks are sensible, they won't make their record
formats too difficult for an spf2 process to use.
The best DK and others can do is to stay away from this mine
field. SPF can offer an op=dk to indicate "I always use DK"
in a sender policy, but that's not essential.
Could all methods live within this standard?
Several independent non-conflicting standards, which could be
used simultaneously, sure, that's possible. If you use CSV
and it says "bad", then you don't need SPF for a 2nd opinion.
The MTAs don't do these checks because they love to burn CPU
cycles on DNS servers, they want clear reasons to reject mails
a.s.a.p. (most mail is spam today).
Spam Bounces in an IP-authenticated transfer must go back
the path they came, not to some header address that might be
forged.
Welcome to the <quote> quixotic quest </quote> of reviving
822 reverse paths disguised as SPF (formerly known as RMX).
Is this something all sides could live with?
Depends, "bounces-to" mail-arch and "anti-phishing" PRA won't
acknowledge the underlying principle of a literal MAIL FROM.
They're free to ignore it, but is that "live with" ?
Is this issue really something that must be worked out in a
shared standard?
IMHO we can only tell it as it is, RfC 1123 5.3.6 (b) "alias"
is a part of the problem. RfC 2476 6.1 "enforced submission
rights" is a good step forward, RfC 2821 7.1 is again a step
backwards, SPF is again a step forward, Sender-id backwards,
RfC 3834 chapter 4 is IMO forward, mail-arch "bounces-to" is
backwards, etc.
We'll end with mail as a minor Jabber-function if neither SPF
nor MASS fly. CSV is IMHO a long shot, the clumsy SPF works
now (for those who want it).
Bye, Frank