Alex van den Bogaerdt wrote:
On Thu, Feb 24, 2005 at 09:17:57PM +0100, Julian Mehnle wrote:
SPF is an authorization method from the domain owner's POV, and an
authentication method from the sender's and receiver's POV.
The only thing the receiver knows is that the sender does, or does not,
allow a certain host to use a certain domain name.
No claim is made about the authenticity of email nor about the address
used.
Yes, there is. Just because the SPF authentication is not as fine grained
as PGP or S/MIME, that doesn't mean it is not authentication.
I'd go even further and claim that SPF is not authorization at all, not
even from the domain owner's POV, and that an SPF record is just part of
an authentication database against which credentials (the sender's IP
address) are checked, and that you generally can only perform
authorization based on authentic identities.
(If you now argued that the hosts.{allow,deny} files on Unix systems were
part of an authorization scheme, I'd reply that identities, such as IP
addresses, _can_ be implicitly authentic, e.g. if you take them from TCP
packet headers.)
This view matches the customary definitions of "authentication" and
"authorization". But I don't exactly have time for this kind of thing, so
I'll desist from discussing it any further.
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.
Nobody asks to lower any security standard.
Yes, you are. You want "-all" not to be taken to mean "-all" (this IP
address is _certainly_ not allowed to use this domain) but "?all" (this IP
address is _probably_ not allowed to use this domain).
Now:
We are testing. Tests go wrong. Do not reject. Flag only and inform
the sender when appropriate. Rejection is strongly discouraged.
You are simply not listening to what I am saying. :-) All the time in
this thread, I have never suggested that _any_ SPF policy could mean that
the recipient should reject anything. I have talked in categories of "the
use of this domain in mail from this IP address is (not) authentic", not
in categories of "mail from this IP address using this domain should (not)
be rejected".
Whether a specific receiver rejects mail with unauthentic sender domains,
copies them into /dev/random, prints and files them away, or simply does
not tream them any special, I don't care. It's the meaning of "-all" that
I care about.
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?
IF<<< a domain owner publishes. Yes.
I need not suggest a date to claim right now is not the time.
Yes, you need to, because otherwise you're not being constructive. :-)
I estimate we communicate with a very small percentage of those
people. The rest are enemies of SPF for life, because "we" blocked
their email so SPF is bad and they can send to hotmail so microsoft
is good.
SPF does not block mail. MTAs block mail, on orders from real people. I
think most people do understand that (spammers usually don't).