In <CA441326-1E63-11D9-A608-000393A56BB6(_at_)glyphic(_dot_)com> Mark Lentczner
<markl(_at_)glyphic(_dot_)com> writes:
Some points:
* The language in question has been in the drafts I've worked on since
* at least early July.
Those drafts were for SenderID, not SPF. The PRA creates huge numbers
of rejections on legimate emails and does not have the fall-back to
the HELO domain so such problems are not as big a deal.
Besides, the SenderID spec had so many other much more important
problems (for example, the licensing), that I didn't want to distract
the discussion with smaller errors such as this.
* check_host() returning "Fail" with a reason of "Domain Does Not
* Exist" need not map to rejection if you so wish. Do whatever you
* like with that result. It can be distinguished from "Fail" with
* reason "Not Permitted", which is the domain advised forgery case.
* This is the reason the reason codes exist. (Though I admit that
* this point may not be as clear in the draft as it could be.)
Not only does the draft not appear to be very clear on this point, I
find no where that suggest that it might be a good idea treat
different "fail" codes differently.
From the definition of "fail" (section 2.4.3)
A Fail result is an explicit statement that the client is
not authorized to use the domain in the "MAIL FROM" identity.
I have no idea how anyone can claim that a domain owner which has
never published any SPF records, who doesn't like SPF, and doesn't
want anything to do with it has somehow denied authorization via SPF
because of the NXDOMAIN.
* Had we not distinguished different "Fail" cases with a reason code,
* we'd be distinguishing different "None" cases with a reason code,
* since some people will want to treat the RCODE 3 case differently
* from the no SPF record case. Or we could have had yet another
* return code. Technically there is no difference, though once could
* argue that there is a different implication to the naive user. At
* over 45 pages, however, this spec should never be implemented by a
* naive user!
As other people have pointed out, most MTAs already have checks for
NXDOMAN built in. Why would anyone need to have this as part of the
SPF spec?
* Back in July I choose to make the check_host() function have a
* result for all inputs. Hence, there are inputs, such as for domains
* that don't exist, or for mal-formed domains, or mailboxes that are
* really address literals, for which I think it is rightly claimed
* that the SPF test can't even be performed, yet check_host() needed
* to return something. These are the "Fail" returns with reasons
* other than "Not Permitted".
I can't recall the SPF-classic equivalent of check_host() ever having
a case where it didn't return something.
Oh, for what it is worth, earlier drafts of SPF-classic said that the
NXDOMAIN should return "unknown" (aka PermError) rather than "none".
* (Incidentally, I think this is another nail in the coffin for the
* null reverse path rule.)
Huh? I don't see that.
* I don't recall the discussion on #spf, so I can't comment. (Do I
* sound like Ronald Regan here? I suppose the relevant logs will be
* supplied soon enough...)
Here are the logs.
[discussion about using zone-cuts snipped]
Sep 27 18:38:45 <markl> well NXDOMAIN isn't an issue -- that is an automatic
Reject
Sep 27 18:39:30 <grumpy> is it?
Sep 27 18:39:34 <grumpy> I hope not
Sep 27 18:39:43 <markl> But good, especially if we're looking for an SPF RR,
then www.foo.com is going to reutnr NODATA, and hence the SOA, and hence we
know where the zone cut is
Sep 27 18:40:07 <grumpy> it was once upon a time, but the problems it
caused were too much and Meng changed it back.
Sep 27 18:40:16 <markl> Sure NXDOMAIN is a Reject: If you see "MAIL From:
bob(_at_)icky(_dot_)aol(_dot_)com" and icky.aol.com doesn't exist - it can't be
a valid mailbox! REJECT!
Sep 27 18:40:25 <grumpy> NO!
Sep 27 18:40:32 <markl> That isn't SPF -- it is just common MTA configuration!
Sep 27 18:40:35 <markl> No? Why no?
Sep 27 18:40:35 <shew> markl: My understanding was that mail forwarders were
implementing it, and we've gotten requests/notices on the list about other
places starting to use it. I figured it merely lagged behind spf adoption by
6-9 months or so.
Sep 27 18:40:36 <grumpy> ok
Sep 27 18:41:04 <grumpy> as long as it isn't SPF. We shouldn't be
defining SPF_REJECT for domains unless they say so.
Sep 27 18:41:13 * markl agreed
Sep 27 18:41:22 * grumpy breaths easier
-wayne