der Mouse wrote:
I submit that neither view is particularly helpful to
reaching any sort of workable resolution.
Nobody is forced to publish SPF FAIL policies, and nobody
is forced to reject SPF FAIL, that's IMHO as "voluntary"
as possible.
When some of the SPF folks got carried away and discussed
to eliminate the "without MX try A" rule, or to enforce
"HELO must make sense" up to "IP-literal is always evil"
or other variations of "receiver policy" it didn't fly.
The S in SPF is for Sender, not reengineer SMTP from scratch.
There is an incompatability between SPF and .forward-style
forwarding; I think everyone agrees on that.
Without reverse paths since about 1989 (RfC 1123), it used
to be fine before, when ".forward" also modified MAIL FROM.
Let MAIL FROM do what it says, and SMTP works as designed,
including 251-".forward".
SPF proponents see this as a problem with .forward;
opponents, a problem with SPF. Neither view is
automatically "right".
Maybe we could still agree that the SPF view is (1) older,
(2) treats MAIL FROM more verbatim, and (3) is based on the
literal meaning of "reverse path" / Return-Path.
The opposition claims that STD 10 was always bogus, and a
better name for MAIL FROM would be ERRORS TO. That's like
Euclidean and non-Euclidean geometry, "right" or "wrong"
is not really the question,
SPF is an option, like 6.1 "enforced submission rights" in
PS 2476 and DS 2476bis. PRA (Senderid) is _another_ option,
like 8.1 "MAY add Sender" in RfC 2476(bis). Ignoring some
technical problems like Resent-* with the latter.
CSV is unrelated to 2821-From or 2822, it's more like a kind
of "single hop DKIM", without the huge 2822-overhead of DKIM.
The SPF HELO checks can roughly achieve the same effect as
CSV as side-effect of normal SPF checks. And if a receiver
uses SPF only to check HELO it's also okay. Above all SPF
is voluntary, "do what you like and cause no harm".
The .forward facility is a) a good idea, and b) entirely
legal within all current standards.
The same could have been said of open relays, when they
first began to be a problem.
This is not to say that I want to argue on either side. I
simply find this line of argument unconvincing; I am
presenting an opposing point not because I oppose the
conclusion but because I oppose the argument.
The argument that CSV could replace SPF was already dubious;
CSV is an alternative to DKIM after reducing the problem to
the critical hops from original sender to initial receiver,
from initial receiver to next "251"-destination, and so on.
DKIM integrates this into "let any MON on the route sign
the message, and let any later MRN check this signature".
Or in other words DKIM is interesting if there's more than
one critical hop between signer and checker, otherwise its
overhead is beyond all reasonable limits: There are much
simpler schemes like MTAMARK or CSV or SPF HELO to get a
grip on "legit mailer" (in combination with a white list).
It's a bit beyond me why folks bother with CSV, or SPF HELO,
or DKIM (sorted by potential overhead) if they could as well
use something as simple as MTAMARK (maybe in combination with
reliable DUL-lists, worst case their own private list).
Of course DKIM with STRONG signing policies is another matter
"phishing" in the muddy waters of PRA. But "pure" DKIM is
much ado about nothing - more convenient for 251-forwarders
than SPF, less convenvient for mailing lists than SPF. Where
PRA managed to combine both worst case scenarios... <sigh />
I think the question we need to be asking is "is this,
however widespread and however longstanding, something we
will ultimately be forced to give up?".
Give up on "the originator as indicated in the Return-Path" ?
That would kill several RfCs starting from 2821 up to 3834.
Bye, Frank
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg