David Nicol wrote:
It's no illusion, it's the definition, and senders know that it can't
work reliably (if at all) if SPF is checked behind the border-MX.
As I understand it:
receivers that do SPF checks past the border are broken.
In theory receivers can determine their own border (with an MX query),
and identify the corresponding timestamp line (Received: header field).
There they'll find the connecting IP and HELO, and can check SPF for
an already accepted mail. SpamAssassin can apparently get this right,
and (in theory) SpamCop's default parser also uses this strategy.
SpamCop's "mailhosts" parser can handle forwarding scenarios, where a
simple MX query won't work. In practice SpamCop doesn't use SPF to
identify forged Return-Paths, because the submitter already said that
it's spam, a forged Return-Path or not is irrelevant for SC.
With SA's approach, if used after the mail was already accepted, SA
could still create a Received-SPF header. I can't tell if SA actually
does this, or if it just transform it into a configurable score. For
SIEVE the situation is in essence the same as for SA.
It's not really "broken" to check SPF too late, it's only hard to get
it right, and it's not more possible to reject a FAIL.
Another scenario are SPF HELO-checks, they work everywhere, not only
at the border. Combined with a white-list of known HELOs you can use
SPF to check the HELO everywhere, and skip the MAIL FROM checks for a
HELO PASS of a known "good" sender. With that approach the MXs could
always check HELO, forward mails between themselves, and skip further
MAIL FROM checks for mails already checked at the border.
But generally, without tricks and talking only about MAIL FROM, it's
as you say "broken" to check SPF behind the border.
Repair options include (1) special-casing border machines (2) doing
SRS forwarding from the border instead of plain forwarding.
See Mark' reply, you won't do SRS for any forwarding within the "MRN"
(mail receiving network), e.g. if a backup MX moves its stuff to the
primary MX, or to the MDA, or however that's organized internally.
For a definition of "internal" including outsourced MXs, not limited
to the same "ADMD" in Dave's terminology, but limited to the same MRN
in Keith's terminology.
Frank
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg