On 6 Dec 2018, at 20:52, Autumn Tyr-Salvia wrote:
I have a lot of experience with SPF, though admittedly, I don't have
as
much experience with SPF failures (I see a lot of cases of no SPF, or
passing but not aligned SPF, but comparatively few actual failures),
but I
haven't heard this distinction between hard and soft fail modes
before.
I'm surprised by that, as it is a core part of SPF's design and on the
receiving side, the distinctions between PASS, FAIL, SOFTFAIL, and
NEUTRAL SPF results have been discussed ad nauseam in regard to their
usefulness and definitions. For example, I've spent insane amounts of
unremunerated time arguing in public the seemingly obvious point that
the multiple paths to a "NEUTRAL" result are in fact strictly identical
and must be treated as such.
How common is it to have receiver systems set so that SPF hard fail
will
reject messages even if they otherwise pass DKIM and DMARC, but to
accept
them on the DKIM pass if the domain uses SPF soft fail?
Much more common in the long tail of small receivers than elsewhere.
Less common 5 years ago than 10 years ago, but anecdotally more common
now than 5 years ago.
In principle, rejecting mail on a SPF (hard) FAIL should be harmless and
it is substantially cheaper than proceeding to the DATA phase to figure
out whether in fact the owner of the envelope domain is unaware of how
their legitimate email may be routed. Early in the life of SPF, some
hard-liners rejected on FAIL as a matter of principle, while other
hard-liners argued that "-all" (the only way to reach FAIL) as the
default in a policy that include paths to PASS was essential to making
SPF useful. Pragmatically, it turned out that SPF provided many non-bulk
senders a lesson in the unanticipated ways their domains get used
innocently, if not exactly legitimately, to send mail. Meanwhile,
high-attention receivers learned that their own users and important
correspondent domains endemically failed to understand those edge and
corner cases where "-all" expresses an unrealistic certainty of
knowledge. Those issues took out a lot of "-all" records AND a lot of
MTA configs that took them seriously.
The spread of sender rewriting schemes and DKIM (and reduced domain
admin naïveté) have revived the use and trust of "-all" in more
prudent ways. It's much safer to strictly honor a FAIL today than ever
as it has become much more rare that FAIL occurs at all, especially by
accident. So senders who are still living in the fantasy of absolute
knowledge about the use of their domains in envelope sender addresses
are at increasing risk.
The SOFTFAIL result of the SPF test exists to express the imperfection
of such knowledge. It is useful to treat FAIL and SOFTFAIL differently
on the receiving side and *in principle* it should be entirely safe for
receivers to trust the certainty of FAIL because senders have the option
of admitting their uncertainty with SOFTFAIL. However, as others have
noted, the most common safe utility of "-all" is for domains where that
is the entirety of the SPF record, expressing the fact that the domain
must not be used at all in sender addresses. I find it also has niche
usefulness for idiosyncratic domains used for research.
Given this situation, the customer is now considering whether they
want to
move every domain they own to SPF soft fail instead, so I wanted to
ask
around and get a feel for how common this is before they change all of
their many domains.
Using "~all" as the SPF default is the most useful reasonable choice for
domains that are used in envelope sender addresses. A small number of
cases merit "?all" because the domain owner is sure that they cannot
know a substantial fraction of the fully legitimate sources of the
domain but can assert legitimacy of some sources. The use of "-all"
should be limited to cases where the domain owner is willing to accept
silent failure of email that does not flow strictly via the authorized
routes in the same record.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Available For Hire: https://linkedin.com/in/billcole
_______________________________________________
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
