Alex van den Bogaerdt wrote:
On Thu, Feb 24, 2005 at 06:35:44PM +0100, Julian Mehnle wrote:
I do not agree completely. Although the SPF specification talks about
what receivers should do depending on the various SPF result codes, I
still think SPF is neither a "rejection method" nor a "approval
method", but an "authentication method".
I think the difference between "authentication" and "authorization" is
large enough to say once more: SPF is an authorization method, not
an authentication method.
A domain's SPF record _authorizes_ IP addresses to send mail "from" that
domain. Based on the SPF record, receivers _authenticate_ the sender
address domains of mail. Based on the SPF-authenticated sender address,
the receiver can then perform another _authorization_ step if it wants
(using a white- or blacklist, for instance).
SPF is an authorization method from the domain owner's POV, and an
authentication method from the sender's and receiver's POV.
This is simply not true right now. You will be correct, in the
hopefully not too distant future. Right now you are not correct.
SPF fail can mean anything from "the sender wasn't authorized(!)
to use the domain name" to "the published goofed up, with or without
the knowledge of the domain owner"
As long as SPF is a relatively new technology and as long as people
are trying it out, we should discourage rejecting email. Flag it
all you want, just don't reject.
This kind of nihilism is the best means to kill off any standard right
away before it has a chance to take off. Incompetence cannot be an excuse
for lowering security standards.
If a domain owner publishes "-all", it is everyone's absolute right to
assume that this is what he meant. Otherwise, what "now we can begin
taking SPF records seriously" switch date would you suggest?
Still, if domain owners _do_ publish a "-all" policy, this must be
respected by the receiver in all cases in order to make SPF work.
Even if the receiver generally decides not to reject unauthentic
mail, he must treat mail failing the SPF check as unauthentic mail.
Period.
I say again: We've seen many cases where domain owners are unaware.
This is regrettable but true.
Would you classify Microsoft designing Internet Explorer in a way that it
violates web standards just so it renders broken pages "correctly" as a
valid approach? As I said, this is the best way to make standards
irrelevant.
When domain owners hear from their peers "Hey, your mail was flagged
as probably unauthorized use of your domain name", they may start
looking into SPF. OTOH if they get their mail bounced, without
knowing about SPF, the introduction to SPF is not a good one.
You are grossly overestimating people's ignorance. As long as bounce
messages include a clear explanation of what went wrong, there won't be
any more resentments against SPF than the other way.
If publishers publish "-all" without knowing about the consequences,
this
Are you aware that the one publishing is not always the one owning?
So what? This problem is roughly orthogonal to SPF. If domain owners
allow third-parties to define their DNS entries, there's nothing we can do
about it. By your argument, one could declare DNS meaningless altogether.
is what needs to be changed, not any standards-conforming
receiver-side methodology.
There is no standard yet to conform to. I think we are talking
about a BCP here, and we don't agree on rejecting.
You say: No statement about rejecting is made by SPF. I say: We
should make a statement that it is not wise to reject right now.
Such a statement should not be part of a standards document that is
supposed to live for a long time. Perhaps if you provided a meaningful
switch date?