On Mon, 2004-04-26 at 08:14, Seth Goodman wrote:
From: Andy Bakun
Digging deeper, I could see a need for making a distinction between
"domain doesn't exist", "domain doesn't publish SPF records" and
"domain's SPF records are unparsable/invalid", but this only has
usefulness outside of the MTA proper. As far as the MTA is concerned,
any of these three states are exactly equilvent, ...
I'm with Meng on this one. There is a real distinction between these three
cases, and it is very relevant to the MTA. It is just not part of SPF.
You are correct of course. I've got ancronym overload, confusing MTA
with the entire process. The distinction is valuable, but making the
distiction doesn't change the actual action taken as part of the whole
'mail acceptance and delivery' process, which is largely locally
determined (rather than determined by the SPF publisher).
Now, an argument could be made that the state of "domain's SPF records
are unparsable/invalid" might be better as a reject state rather than an
unknown state -- otherwise there is no reason to have people fix broken
records. But that doesn't outweigh certain facts like 1) people don't
read bounce messages 2) people think that a reject is always "the other
guy's fault" 3) we want minimal invasiveness with SPF deployments 4) and
makes the correct people responsible for busted SPF records (as far as
the intent of SPF). The decision to make the three states outlined
above map to 'unknown' is a pragmatic one, and one that I agree with.
To explain #4 some more... since the intent is to allow domain owners to
publish their own policy and SPF does not specify much, if any,
enforcement, it's not anyone's responsiblity other than the domain
owner's to make sure their policy is accurately represented in SPF and
is understandable to the necessary audience. In light of this, if
unparsable/invalid SPF records forced mail to be rejected, that would be
interpreting the domain owner's ambiguous wishes in a non-backward
compatible fashion. When I want to get a message across, I go through
some effort to ensure that it will be understandable and presumablly SPF
publishers should do the same, by running some kind of validator (which
may be built into a DNS server, maybe a webpage like we have now, etc).
SPF is to mail acceptance as P3P is to privacy policies (mentioning P3P
should not be interepreted that I have an opinion on P3P). The old
method of domain name use in email transactions, pre-SPF, might have
been Bob calling Joe and saying "Don't accept mail from my domain unless
it's from x.x.x.x" -- but this has obvious scale problems. The new
method, using SPF, makes that machine readable, machine evaluatable and,
perhaps, machine enforceable. But like many tasks that are automated,
they should still be overrideable and subject to human review (through
changes in locally implemented policy).
Since many people already configure their mailers to do forward
confirmed reverse DNS on the connecting IP, NXDOMAIN results would
cause SMTP connections to be terminated before you ever get to the SPF
check.
Exactly -- I remembered this component soon after I hit send. But this
is still one component, just like SPF is a single component, and I hope
I didn't present SPF as the first line of defense in any anti-spam
anti-virus setup someone may have -- it is logically further down the
stack, but still before the entire email has been accepted (as however
local acceptance policy has been configured). People are welcome to
implement SPF checks as a means to increase the robustness of spam and
virus checkers, but that's not SPF's goal and thus doesn't solely
fulfill it (but we all know this :) ).
--
Andy Bakun <spf(_at_)leave-it-to-grace(_dot_)com>