Mark Shewmaker wrote:
[...]
Since by definition:
NXDOMAIN result: spf(domain that doesn't exist) == None
No SPF record: spf(existing domain w/o spf record) == None
The above chart would translate to:
| non-existent domain | domain w/o SPF record
-----------+---------------------+-----------------------
include: | None->not match | None->not match
redirect= | None | None
However, there's one minor annoyance with the above scheme which I think
can be entirely answered:
There's always been a bit of a disagreement as to what would be the best
definition of spf(non-existent domain).
The current defined result is "None". The logic behind that
decision/compromise as I understand it is that:
One camp: Some want FAIL or PermError to be the defined
result so they can immediately reject.
Another camp: Some want it to be defined to be "None",
since there really isn't an spf policy
published.
Compromise: Since most people already reject on a
nonexistent mailfrom domain anyway, the
issues group (1) care about are already
taken care of, so the technically pure
(2) answer is still a safe answer for
that group. This means that making the
definition conform to (2)'s wishes
still placates both groups.
That works well for top-level spf evaluations, but the compromise isn't
quite as clear for recursive-type evaluations, because receivers aren't
already handling the issue in a way that's conveniently compatible with
current/future spf practice.
I accept the rationale for perhaps not using PermError for this --
considering your later statement that it might best be reserved for
syntax/usage errors. My compromise to (1) would be to instead consider
having NXDOMAIN result in SoftFail. This would raise awareness of the
problem without (presumably) resulting in the immediate rejections Fail
or PermError might. None seems to me to just be too weak in this case.
Yes, administrators *should* have their MTA configured to verify EHLO
(or MAIL FROM domain) existence prior to doing SPF checks, but what if
they don't? (The parallel thread regarding a desire for ID in addition
to EHLO and MAIL FROM should raise some doubt whether to expect these
checks really occur or are meaningful.) Is this something SPF should
assume -- and, if so, perhaps consider qualifying in the spec as
something it *does* assume? Or should SPF instead evaluate it's policies
without respect to what else the receiver may or may not be expected to
also be checking? It has been my understanding that there is a strong
desire not to assume receiver behavior or policy when defining SPF.
[...]
However, it's entirely possible that a receiver could legitimately
include a nonexistent domain. Say they're switching their email setup
around, and to be safe include: domains in a top-level spf record for a
time period slightly past the time in which the domains themselves are
defined.
Should we cause the domain owners to suffer if they do that, based on a
desire to make sure the typos other domain owners make get fixed fast?
In practice, domain migrations (especially where email delivery is
critical) would be much better than planned than this suggests. In most
cases (corporate or not) that I've seen when a domain is planned for NX,
it is in reality left online for quite a while longer than the changes
start occurring... until such time has passed that no one is likely to
be referring to the old domain (or it's so old you don't care any more).
To me this seems a corner case, but perhaps others see this as a larger
concern.
[...]
The downside here is that folks who enter records such as:
v=spf1 a mx include:nonexistent-domain -all
or
v=spf1 a mx redirect:nonexistent-domain
will just have to deal with the more difficult troubleshooting caused by
their include or redirect modifiers going "invisible" if the referred-to
domain's records disappear.
There is an advantage in this: People in a large organization that's
putting together spf records can "include:" other records ahead of time,
instead of having to be *VERY* careful to fill out
leaves-before-branches, so to speak.
Perhaps it's just an anal-retentive preference, but to me this would be
right up there with adding an MX or NS record for a host that wasn't
already online. :-) In my view, care should be taken with such things...
perhaps even moreso when one's email domain reputation (and message
delivery!) may be affected as a result.
Bill