ietf-asrg
[Top] [All Lists]

[Asrg] Re: Default SPF Enablement?

2006-01-31 07:01:28
Douglas Campbell wrote:

you are saying that SPF breaks forwarding (and aliasing)
to foreign e-mail addresses. But  does it?

Generally receivers cannot check SPF behind their border MX,
and 1123 5.3.6(a) aka "251 user not local" _is_ behind their
border.

Something has to give.  Otherwise they'd get an emulation of
"551 user no local".  Calling that "breaks forwarding" is a
simplification.  Actually 1123 broke it 16 years ago, it was
fine in STD 10 with its (literally) reverse paths:

251-forwarders knew that they get the mail back if it doesn't
work out, therefore they always had the option to reject (551).

All "MSAs" (at that time "smart hosts") and relays knew that
they cannot accept arbitrary Return-Paths, because they were
responsible to return this if it doesn't work out.  SMTP was
a simple and robust protocol, designed by Jon Postel, it took
the 1123-committee to "break" it.  SPF allows to "fix" this.

After the spammers found and abused this loophole for their
own purposes (they need MAIL FROMs surviving call back tests)
about twelve years after 1123 was published.

Probably nobody expected in 1989 (when 1123 was published)
that today most mails are spam with forged Return-Paths.  Or
maybe they thought that "MX" should cover the concept "RMX",
some kind of default "v=spf1 mx a ~all".

It's a subtle bug, all reasons given in RfC 1123 for dropping
the source routes are convincing.  Only the side-effect "this
allows to use arbitrary Return-Paths" turned out to be very
bad, more than a decade later.

In other words, if I forward e-mail, shouldn't the envelope
and headers change to reflect that I forwarded?

Yes, if you do that - aka 1123 5.3.6(b) - there's no problem
with SPF at whatever next hop:  It would check your policy
against your "RMX" IPs and get a PASS.  Or if you have no SPF
policy it would get NONE, but not a FAIL as with the original
MAIL FROM policy checked against your IPs.

trying to understand history, in an effort not to repeat it.

The problem is that some forwarder claim that 251-forwarding
is a "feature" (it really was before 1123) and don't accept
that it's now a "bug".  Same situation as with "open relays",
that was a good (or at least possible) idea for some time.

                             Bye, Frank



_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg