On Fri, May 06, 2005 at 12:02:37PM -0500 or thereabouts, wayne wrote:
Note: I'm not trimming comments very much in this reply. My comments
are mostly short, but I think the context for the comments are
important and it was too much work to correclty paraphrase stuff.
=========================================================================
Based on several reviewer's comments (Julian, Frank, and indirectly,
Andy), the most controversial item left appears to be what to do when
a non-existent domain is encountered. Part of the problem is that
this subject has been controversial for a very long time and various
previous SPF specifications have said to do different things.
Moreover, different SPF implementations have done different things and
different versions of the same SPF implementation have done different
things.
Throwing in my opinion. SPF is asked one question.
"Is this email address a forgery?"
Answers are:
+ PASS positively no. The address is valid.
- FAIL positively yes. It is a forgery as defined by the domain
owner.
~ SOFTFAIL maybe, but I, the domain holder, am telling you to accept
the mail anyways.
? NEUTRAL I, the domain holder, am saying "I'm not positive either
way, you are free to use some other check".
none NONE "No answer found."
TEMPERR "I will check it again another time when resources are
available"
PERMERR "bad SPF record, domain owner needs to try again"
SPF was not asked if the domain exists, if it has a good reputation,
or if it has a high spam/signal ratio. It was asked if the address was
a forgery. The answer is "No answer found because no records exist".
It is up to the MTA to decide whether or not to accept the mail
from a domain that does not exist. 99% of servers do not need or
want to accept mail from domains that do not exist. But, if the
1% that want to have that functionality are cut off by a library call
that denies 100% of the time, that library will never be used.
You therefore ban the useage of SPF on 1% of machines.
The option of what to do with a non-existant domain name is for the MTA
and not the SPF library. IMHO, SPF MUST return "NONE" because it does
not have enough information to answer the "only" question it was asked.
Sendmail has the option FEATURE(`accept_unresolvable_domains') for
those domains that have to use it for some reason. The default is not
to accept, but the option is there. I have to use it on my UUCP gateway
machine. Yes, I still have UUCP customers. Throwing an error condition
criples the MTA by answering the WRONG question.
So, what implications would changing the result of SPF(non-existent-domain)
from ("None"|"Fail") to "PermError" have?
Compared to the earlier original result of "Fail", "PermError" would be no
significant change as receiver policies most probably don't differ much
between "Fail" and "PermError".
Compared to the result of "None", "PermError" would be stricter, probably
implying a rejection where one wouldn't have happened otherwise.
But considering that, like you said, most receivers probably reject
messages with non-existent sender domains right away anyway, without
subjecting them to SPF checks, I think defining SPF(non-existent-domain)
== "PermError" is unproblematic and is logically the right thing to do.
People just shouldn't expect SPF to work on invalid input data.
"most receivers" by definition means not all. There are some receivers
that will need to accept email from unresolvable domains. Forcing a
550 responce, means SPF cannot be run on those servers.
There is no "invalid input data" here. If the domain does not exist,
there is no SPF record. That is the same as if the domain did exist
and had not published. Both need to return the same answer, NONE.
As to include:foreign-isp.dom not existing, while I do not like PermError
as an answer for this, the domain publisher had been warned about the
possibility. I can be convinced that the PermError is correct.
The SPF publishing process has been started, and should be completed.
The odds of an foreign-isp.dom's SPF records totally disappearing after
existing are small. Penalties here are the same as any other DNS opperation.
Linking to outside zones requires trust the data will be there tomorrow.
-Mike Elliott
=========================================================================
I'm interested in hearing what others have to say on this issue.
Right now, I'm not convinced that the draft should be changed. Please
feel free to bring this issue up for a vote on the council.
-wayne