On 24 Jan 2020, at 9:31, Gregory Heytings via mailop wrote:
In my opinion, "-all" is good only when it is the *only* entry in
the SPF record, ie. SPF record indicates that the domain does not
send mail *at all*. In all other cases, I think that even if
original SPF record specifies "-all", the receiving server should
override this and interpret it as "?all".
I tend to disagree. If you allow every IP to send mail on your
behalf, then why even bother putting an SPF record. For me, only -all
makes sense, all others are just as meaningful as having no SPF
records at all.
What you write would be correct if SPF was the only spam filtering
mechanism. But it is only one of the many spam filtering mechanisms,
along with DKIM, content filtering, IP reputation, etc. Each of these
mechanisms have a positive or negative effect on the final result:
mark / do not mark this email as spam.
For SPF, the "all" keyword is only reached if processing the previous
policy rules did not result in a positive answer, which means
"interpret this a sign that the email is likely not spam, but use the
other filtering mechanisms before taking a decision" (it's a "+1").
At that point:
"?all" means "do not interpret this as a sign that the email is likely
spam, please use the other filtering mechanism to take a decision
instead" (it's a "+0"),
"~all" means "interpret this a sign that the email is likely spam, but
use the other filtering mechanisms before taking a decision" (it's a
"-1"),
"-all" means "interpret this a sign that the email is certainly spam,
do not use any other filtering mechanisms to take a decision" (it's a
"-infinity").
That is not how the SPF specification describes SPF testing and is not
how any widely used implementation of SPF checking actually works.
A SPF check as specified and as widely implemented ENDS when any
mechanism specified in the record is matched.
As I and others said, given in particular the case of forwards and
mailing lists, "-all" is seldom a good idea,
For traditional transparent forwarding (e.g. /etc/aliases or ~/.forward)
this is true, and between that problem, DKIM "p=reject," and simple
errors in SPF records causing damage, the real harm from using "-all"
has fallen over the past decade to the point where "-all" is only
stronger in practice than "~all" when it is the only element in the SPF
record, indicating an absolute lack of any legitimate mail using the
domain as the RFC5321.MailFrom or RFC5321.HELO domain.
For "mailing lists" the effect of "-all" is also quite small. There are
lots of variants on what a "mailing list" is, from MUA-expanded aliases
and MX-expanded aliases to robust discussion platforms like Mailman and
Listserv. Simple alias-based lists are harmed by ~all or -all, because
they simply convert a target address into multiple target addresses and
may then forward messages from the exploding system to other systems
without modifying the RFC5321.MailFrom. For mailing lists that are
managed by tools external to MTAs, it has been the norm for 30 years to
re-send messages with a RFC5321.MailFrom pointing back to the list
server itself simply to solve the issue of where bounces of list mail
should go. In short: "real" mailing lists don't have a problem with the
original author having a -all SPF default.
and certainly not a good idea for a small personal server.
That is not my direct experience. In principle, if -all was in fact
problematic for mailing lists in general, I should receive a substantial
number of bounces, as I have used per-list sender addresses in a domain
with a -all default for as long as SPF has existed. I have in fact NEVER
received a bounce of a message that I have sent with those addresses. I
also put a -all derfault on my primary domain for testing before the SPF
RFC was published and in all the years since I have had only a handful
of bounces due to transparent forwarding and no evidence of silent
failures or delivery in to "spam folders" as a consequence. I have not
had any bounces caused by my SPF record (except as a consequence of
forgery in spam) in the past decade. The sole edge case here is that
sending mail into Hotmail and its equivalents at MS is always a
crapshoot into a black hole, but that's true for all mail from anywhere
as far as I can tell.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not For Hire (currently)
_______________________________________________
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
