On Tue, Sep 19, 2006 at 12:19:00PM -0400, Scott Kitterman wrote:
This has even evolved now into "you are authorizing everybody sending
through the servers to use your name" which is just plain wrong. The
protocol does _not_ say this.
But it is, IMO, a reasonable conclusion. If I get a message and it says
Pass, then that server is an authorized source of messages for the name.
What other conclusion can one draw, but that the message is authorized.
You have no reason at all to draw such a conclusion. The only conclusion
you can draw is that the server has a right to send messages using this
return path.
No other semantics are present. Any other conclusion is yours, and yours
alone, not the publisher's.
Shared server without technical means to prevent cross-user forgery gets
an SPF Pass has risks.
That's why there is a section on cross-user forgery in paragraph 10.
You mean 10.4 ? The section starting with "By definition ..." then
continuing to explain why SPF is not (!) designed to look at individual
users?
I should think this section defends my position, not yours.
I argued for a separate result for some form of 'I do send mail through
this server, but other people do too, so there are no guarantees', but lost
that point 2 years ago. What we have is what we have.
No offense, but it seems to me you are still fighting to massage the
protocol into what you want it to be, in stead of accepting the way
the majority decided on.
Yes, I've seen "v=spf1 a mx ptr ?include:provider1 ?include:provider2
?all".
My first SPF record looked something like that. Make the statements you
can safely make (positive and negative) and no more. People do better over
time.
Clearer example: "v=spf1 ?include:provider ?all".
Pointless, and unnecessary. This should be one of the following three:
a) "v=spf1 include:provider ?all"
b) "v=spf1 ?include:provider -all"
c) "v=spf1 ?all"
And the publisher does not want (b) nor (c), so (a) is the only remaining
option.
Overloading the protocol's semantics with what you advocate removes that
option as well, leaving no viable choice for this user.
SPF is, according to the abstract, designed to authorize hosts. Any
other explanation is wrong. If you believe shared hosts do not deserve
a pass, it means you are looking at individual messages, not at the
right the server has to use your domain as reverse path.
But as a receiver, I get messages one at a time. How else can I look at at?
This is the same attitude as when people saying "the message was SPF
authorized but it is still spam". Wrong conclusions drawn because of
wrong anticipations.
I should probably mention that I have at least a small professional
interest in this debate as I've recently started offering what I would
describe as "safe" shared SMTP services:
http://www.controlledmail.com/
Which is, assuming everything works as designed, certainly better from
a reputation point of view. People who's reputation was damaged because
of a shared customer email service without such a responsible setup would
probably want to know about alternatives. This is such an alternative.
Alex
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com