-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of Seth
Goodman
Sent: Sunday, January 02, 2005 3:36 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: RE: [spf-discuss] Should I include major ISPs in SPF for our
hosted domains?
From: william(at)elan.net
Sent: Sunday, January 02, 2005 3:26 AM
On Sat, 1 Jan 2005, Stuart D. Gathman wrote:
On Sat, 1 Jan 2005, Nick Phillips wrote:
It's your point 1 here that I think is misplaced. A PASS is
not saying that
mail coming from that server with your domains on it is
really yours, it's
saying that it could be, as that server is authorised to send
mail from
your domains.
I disagree. A NEUTRAL says that it could be yours. A PASS
says that to the
best of your knowledge and ability (i.e. assuming your servers
weren't hacked,
etc), the mail is yours. If your mail might go out via other
ISPs without
meaningful authentication (i.e. that prevents cross customer forgery),
then they should be listed with '?'.
You're not correct. SPF does not look at local parts and SPF records for
domains are often very widerange to allow any user from domain to be
authenticated. As such it does not provide very strong sense of the email
is truly yours and is not a good way to judge reputation on.
I disagree with your analysis. Nowhere did Stuart mention authenticating
local parts. SPF is a designated sender scheme for domains. To the extent
that a domain is in control of its outgoing MTA's, and as long as an
ancillary protocol is used to deal with forwarding, SPF gives a perfectly
good _domain_ authentication that is suitable for reputation assessment.
Depending on the ancillary protocol chosen, the result is quite different.
If SES is used, the original domain can be authenticated in the presence of
forwards and spam will be attributed to the originating domain, as it
should. If SRS is used, only the last hop will be authenticated and any
spam will be attributed to the last hop, even if it is a forwarder.
To the extent that domains designate third party MTA's that allow their
customers to forge any domain they choose, this weakens the policy
statement
of the SPF record. For SPF to work best, a domain should provide SMTP AUTH
so that only MTA's under its direct control are designated as permitted
senders.
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.
It's really up to the domain owner to decide. There is no dedicated MTA
under my control for my domains. I've made the decision as a domain owner
that I do NOT want to give a pass to shared MTAs that do not have technical
means in place to prohibit cross-customer forgery (SMTP-AUTH alone is not
enough for this).
If you as a domain owner want to decide differently, it's up to you. I
would, however, recommend you take note of the next logical step described
in the SPF FAQ:
http://spf.pobox.com/faq.html#churn
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.
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....
Scott Kitterman