On Tue, 19 Sep 2006 23:34:19 +0200 Alex van den Bogaerdt
<alex(_at_)ergens(_dot_)op(_dot_)het(_dot_)net> wrote:
SPF is about authorization. You are talking about authentication.
Not necessarily (talking about authentication). See below.
Authorization and authentication are two different things. Related: yes,
the same: no. Mix 'em up and you'll make it difficult to understand.
Agreed.
I think the RFC is pretty clear on what SPF is and does. Why suddenly
change the semantics? I thought we had passed that stage already.
I agree, but what I thought what we had a consensus on is what I'm arguing.
With SPF you make a statement about a host, not about messages relayed
through that host. It says so right at the beginning of the RFC.
OK.
SPF authorizes servers, not authenticates messages. Cross user forgery
has to be solved by the ISP, not by the SPF publisher. You may have
written the paragraph but several other people have looked at it,
commented on it (or not) and thus approved it. If you ment something
different than what it currently says, that's something for 4408bis.
So far you're the only one I know of that doesn't agree with Julian.
SPF allows a receiver to quickly sift forgeries from other mail. It
does so by looking at the authorization status of a host. The remaining
messages (after throwing away obvious forgeries) still needs to be
examined further. Cross user forgery is such a case. It's just that
you only have to examine 10% (or so) of the original amount of mail.
Agreed, except it'll be more than 10% soon if it isn't already. Getting an
SPF pass for a random throw-away domain is pretty trivial. Reputation
systems will have to step up to fill that gap.
That 10% could then be processed, for instance with DKIM, SES, or any
other protocol demanding serious processing power. That's the point.
If you don't trust an ISP, publish `neutral'. But maybe you should
leave the ISP and find something you do trust. Most people do trust
their provider. That doesn't mean problems never occur. But it does
mean problems are expected to be solved, and will occur less frequent
than elsewhere on the net.
It's not a question in my mind of just trusting the provider, it's trustung
their however many hundred thousand customers too.
Currently I do not know of any commercial SMTP service that permits
'foreign' e-mail addresses to be used that will also prevent cross user
forgery, except mine. That's why I set it up. Telling someone to get a
provider that will not allow cross-user forgery today isn't much of a
choice.
100% certainty is impossible to reach. For nearly 100%, `pass' will do.
Don't forget that cross user forgery is more difficult to do, and at
a higher risc of detection, than any other form of forgery. It takes
more planning and research, thus is less cost effective for your
average spammer. Goal reached.
Not if you include: free mail providers. Agree cross-user forgery is not a
high risk today unless someone has a specific rreason to target your
particular domaim, but I still recommend Neutral as a future proofing
method. Most people aren't going to keep in touch with the latest trends
and know when to change.
"include:my_isp" is quite different from "all". If you want people to
publish "?include:my_isp" then there's no serious reason to allow "?all"
anymore. If that would be the case, then:
a) the default would be "-all", not "?all"
and
b) "all" by itself would be redundant and thus should go.
These days I generally recommend ~all for small domain owners so there some
distinction.
If you want authentication, the minimum is some form of encryption,
like SES. Do not mistake SPF for something providing authentication.
I would have said PGP or S/MIME. What does SES tell you beyond it passed
through a certain mail server that signed it. I'd say the same for DKIM.
I think we are disagreeing about what authorization is good for. I say if
example.com authorizes a server to send their mail and it comes out spammy,
then they should pay the price and have a bad reputation, get RHSBLed, etc.
I think authentication is for things like "You sent me a signed e-mail
accepting the contract, now you are obligated to pay".
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