This is getting somewhat off topic for spf-help. I've sent this to
spf-discuss if you care to continue the discussion there.
On Tue, 19 Sep 2006 17:46:58 +0200 Alex van den Bogaerdt
<alex(_at_)ergens(_dot_)op(_dot_)het(_dot_)net> wrote:
On Tue, Sep 19, 2006 at 11:15:00AM -0400, Scott Kitterman wrote:
By specifying 'authorized', you imply a certain amount of trust in
the server, and/or its keeper. Should a google user forge your
name, you trust the origanization will punish that user and stop
the abuse.
A problematic perspective in my view since the most they can go is cause
someome to have to sign up for a new account.
Much better in my view to give a Neutral result to such providers. I
think
the only shares servers that should get an SPF pass are those with
technical means in place to prevent such abuse in the first place. I
don't
use Gmail, so I've no idea which camp to put them in.
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.
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.
Everybody needs to be aware of the implications, sure. What I
strongly oppose to is the "shared server deserves neutral" mantra.
This would make it impossible to end a record with "?all".
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.
One can end a record with ?all if one wants. Neutral means None and that's
it.
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.
(and worse even).
If you know you send mail via gmail, you can authorize that host. There's
nothing wrong with that. If you are afraid messages go via this channel
but aren't yours, other protocols exist. PGP comes to mind.
Yes and don't complain when your domain ends up in an RHSBL.
And if gmail would frequently be abused, but gmail would not stop this
abuse (for instance by making cross-user forgery impossible) then anyone
using this service deserves a bad reputation.
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?
At the very least defenders of the "shared hosts should get neutral"
philosofy should acknowledge in their post that this is an opinion,
not a rule, and that other opinions exist as well. Especially so
since the RFC says otherwise. Also consider the example given in
the RFC, about forwarders. A slightly modified example, including
gmail as a neutral producing modifier would already result in the
pointless excercise as given in the example above.
(... ?include:gmail.com ?all)
Note that I said "In my view". The RFC examples are what you say, but
there is also an explicit warning in paragrapgh 10.
A longer exposition of my view is that Pass for shared servers that do not
prevent cross-user forgery is not a major risk today, but as RHSBLs and
named based reputation services grow insignificance, it will become an
increasingly big issue.
Personally, when I mostly used shared servers, I didn't want to discover it
was a problem when my mail couldn't get delivered.
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/
This isn't a big money maker for me, but something I feel strongly enough
about that I decided to offer a seervice to help people avoid the problem.
Scott K
-------
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