On Mon, Jan 03, 2005 at 10:47:14AM -0500, Scott Kitterman wrote:
The specification used by most current implementations:
http://spf.pobox.com/spf-draft-200406.txt
is pretty clear on this matter:
Neutral (?): The SPF client MUST proceed as if a domain did not
publish SPF data. This result occurs if the domain explicitly
specifies a "?" value, or if processing "falls off the end" of
the SPF record.
Pass (+): the message meets the publishing domain's definition of
legitimacy. MTAs proceed to apply local policy and MAY accept or
reject the message accordingly.
I think wayne's latest draft puts it better
(http://www.ietf.org/internet-drafts/draft-schlitt-spf-classic-00.txt):
2.5.1 None
A result of None means that no records were published by the
domain. The checking software cannot ascertain if the client host is
authorized or not.
2.5.2 Neutral
The domain owner has explicitly stated that doesn't know whether the
IP is authorized or not. A Neutral result MUST be treated exactly like
the None result.
2.5.3 Pass
A Pass result means that the client is authorized to inject mail with
the given identity. Further policy checks, such as reputation, or
black and/or white listing, can now proceed with confidence in the
identity.
2.5.4 Fail
A Fail result is an explicit statement that the client is not
authorized to use the domain in the given identity. The checking
software can choose to mark the mail based on this, or to reject the
mail outright.
I would strongly recommend domain owners set a policy that avoids giving an
SPF pass to messages sent from sources that allow for cross-customer
forgery. This concern does not apply to properly secured MTAs under the
control of the domain owner.
Right. So you don't authorize poorly-run MTAs to send mail for you. Makes
sense.
For what it's worth, I was confused about this at first too. I was sure a
pass had to mean that the sender is permitted, not that the message was
authorized. I think that would have made more sense, but that's not the way
it went....
Well, I think the previous draft you referred to had started to fall into
the trap I described before -- SPF[*] does not and should not say *anything*
about the local part or the authenticity of an individual message, and to
start to pretend that it does was a Bad Thing. I'm *very* glad to see that
wayne's draft has corrected that.
In practice, there is not a whole lot of difference between the two
approaches -- either way neutral is giving you a way out of a potentially
nasty corner. It's just that wayne's phrasing matches what is actually
happening, and the other way was trying to make explicit something which
whilst it would probably usually be the case, need not necessarily be so,
and gaining nothing from it.
Maybe we should think of a "neutral" as the domain owner coughing and
changing the subject when you ask whether mail from their domain should be
arriving from the IP you looked up ;-)
[*] At least with the mechanisms included in SPF "Classic"
Cheers,
Nick