Re: [SPF v1 Draft] Last chance before I submit...

Sorry about the late reply but I wanted to say, I really strongly agree 
with Wayne on this one.  The original spec said "none" if domain does not 
exist, and I believe some popular implementations follow this.

--Mark Lentczner <markl(_at_)glyphic(_dot_)com> wrote:
> * 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.)

If "reason codes" are a new thing, why are we changing the rules for 
pre-existing results?  Maybe if reason codes had been present from the 
beginning, but if you are just now adding them, don't use "hey, look, new 
feature" to change the rules and behavior of pre-existing features.



> * 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!

I don't believe "domain does not exist" rises to the level of "Fail". 
Maybe error, maybe none, but not fail.

1. From a sysadmin perspective, think of it this way.  I already have 
Sendmail, Postfix, and $appliance configured to reject mail if the return 
address does not exist (5xx), does not resolve (4xx), or exists but doesn't 
contain A or MX records.  When I have a DNS problem (such as the dns server 
just not working, or worse, feeding the "phony" internal information 
instead of the external info) then I get DNS-related errors.
What I don't want to have is suddenly a bunch of SPF errors right after I 
roll out SPF -- situations that should have led to a reject anyway, but now 
SPF is doing the rejecting and not mailer+dns.  That will just get in the 
way of troubleshooting and give people at my site (or worse, my customers) 
the impression that SPF is the thing bouncing their mail.


> * RCODE 3, commonly called "domain does not exist" or NXDOMAIN, is well
> defined in RFC 1035, which is normative to the draft.
>
> * RCODE 3 is only returned when there are no records at all for a queried
> name.  If there records for the domain, but just none of the queried
> type, then RCODE 0 (no error) is returned, and an empty answer section.
> This later situation does not trigger the "Fail" with reason "Domain Does
> Not Exist" in check_host().

2. About the case where the domain exists but doesn't contain an A or MX: 
Obviously that should be rejected as well, not because it's a bad or 
nonexistent domain name, but because it's not a valid return address.  But, 
SPF doesn't take care of this, so I still have to do it in my mailer.  Now 
I have the awkward arrangement of nonexistent domains getting an SPF error, 
and exists-but-not-for-email domains getting a different error.  Again, 
this is bad for troubleshooting.
 user(_at_)10(_dot_)2(_dot_)3(_dot_)4        -> Fail, no .4 TLD
 user(_at_)co(_dot_)uk           -> None, .co.uk does not publish SPF records
 user(_at_)4(_dot_)3(_dot_)2(_dot_)10(_dot_)in-addr(_dot_)arpa -> None, PTR but 
no TXT
 user(_at_)_spf(_dot_)domain(_dot_)com -> None or Pass

If you make the case that non-existent domains should get Fail, you are 
halfway down the slippery slope that leads to "not having an A or MX record 
should fail too".  Either go whole hog or leave it alone.  Don't leave it 
in a state where SPF fails some of the mail that Sendmail should also fail, 
but not all of it.  For the sake of troubleshooting, and not causing people 
to panic right after I assured everyone at my site that SPF was safe, if 
nothing else.

3. If I read right, "definitely doesn't exist" is suggested to be Fail, but 
"failure or timeout looking that up" is a temp error.  Why does one kind of 
DNS problem get Error and another type get Fail?  Yet another 
inconsistency, and another false lead when it comes time to troubleshoot.


> * It would seem that rejecting mail from domains that have no way to
> reply to them (having neither A nor MX records) is common practice.

I would phrase this as "a problem which is solved or at least well known." 
This is much different from "a problem needing SPF as a solution".

> * 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".

The original spec said "None".  If you really think this is wrong and bad, 
might I suggest "Error"?  Not Fail.
"Error" would go really great with some language that says: "DEAR DUMBASS 
WHAT IS IMPLEMENTING THIS:  PLEASE CHECK THE DOMAIN EXISTS AND HAS A OR MX 
RECORDS, AND THAT MX RECORDS IF ANY DON'T POINT TO 127.0.0.1 OR "." - OR 
WHATEVER YOUR LOCAL POLICY IS.  SPF IS NOT YOUR NEW ALL-IN-ONE SOLUTION FOR 
EVERYTHING.  k thx bye"

> * If you don't want to reject messages with null reverse paths that fail
> the check_host() function with a reason of "Domain Does Not Exist", you
> can do so.  This case is discernible and  permitted.  (Incidentally, I
> think this is another nail in the coffin for the null reverse path rule.)

Hmm, this doesn't wash.  First we are offering to do more work for the user 
(sysadmin, implementer, etc) by returning Fail when we think they really 
should bounce it.  But, as we have seen above there are some key places 
where this A. falls down and doesn't Fail similar cases, and B. does things 
inconsistently.
Now we have introduced a third problem, which is that we can't even trust 
"Fail" results to mean "Always reject" and instead we have to put in 
double-checks for that case, and this double-check now needs to check three 
things: Result, Reason code, and Null return path.
By that I mean "If you don't want X you can do Y+Z" is only justified if 
you can say "Most sites WILL want this" which is definitely not safe to 
assume.  The possible benefit by guessing at what the receiver really wants 
and doing it for him is FAR outweighed by 1. hassle involved in deciding 
not to do X, and 2. possible risk of dropped mail if they don't want X and 
fail to read your disclaimer.

--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>