----- Original Message -----
From: "Mark" <admin(_at_)asarian-host(_dot_)net>
Newsgroups: spf.-.sender.policy.framework.discussion
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Thursday, June 02, 2005 1:21 PM
Subject: [spf-discuss] Request for Input on the meaning of "pass".
There is an issue regarding "pass" that we, the SPF Council, would like to
have your opinion on.
2.5.3. Pass
A "Pass" result means that the client is authorized to inject mail
with the given identity. Further policy checks, such as reputation,
or black and/or white listing, can now proceed with confidence in
the identity.
Mark,
Here is my take.
I think we all agree on what Authentication vs. Authorization means:
Authentication - indicates how the sender is true who he says he is.
Authorization - indicates how the sender is allowed to perform its task.
I will add a few more which you want to "switch" to using more:
Verification or Validation - The generic process of performing an
Authentication or Authorization process.
SPF is or shall I say, I believe, it a EMAIL DOMAIN (MAIL FROM)
authorization scheme.
However, it also a IP authentication scheme too when you take into account
the CLIENT DOMAIN (HELO/EHLO).
Take SPF out of the picture for a moment. Forget that it exist.
In theory, the IP::HELO relationship must match. There is no theoretical
ambiguity here. This why the CSV people think it is stronger proposal to
base a security framework.
However, in practice, the client domain is not reliable and there is no
guarantee that there is an A for PTR record for the IP address.
SPF or NO SPF, this would be an AUTHENTICATION concept when you try to make
sure the IP address matches the client domain name. You don't need SPF for
this.
Now, Authorization comes into play when you begin to define a policy for
that sender.
Since SPF is only designed as a answer to the question:
Can this machine send mail using this domain?
Then it is not a matter of whether this sender is truly who he says he is,
but rather whether he is authorized to send mail.
Look at this way. Lets say tomorrow we have an SPF concept where we begin
to define who can send local mail vs. remote (route) mail?
v=spf3 local_ip4:xxxxxxxxxx remote_ip4:xxxxxxxxx -all
At this point, you are defining authorization policies.
I know this is redundant because we already have standard methods for
authorizing remote routing, which brings me to my final point:
SPF should note attempt to replace how SMTP authorizes senders using current
methods and it should attempt to replace how local or remote mail is done.
So what I think you should do is reword things "verify" or "validate" and
describe exactly what the results mean, not necessarily how they be used
for POLICY.
So here is how I would change the specs:
2.5.3. Pass
In general, a PASS will be used to indicate a "positive trust" on the
transaction. A Pass result simply indicates the SPF policy has
been verified for the HELO or MAIL FROM domains.
While it is out of the scope of this technical specification to apply
a trust value, for the pass result, a SPF processor *may* perform
further policy checks, such as 3rd party reputation checks or use
a local black and/or white listing policy depending on the
implementation and the local mail policy.
2.5.3.1 Pass for HELO/ECHO domain checks
A "Pass" result means that the client has been authenticated by
verifying the client domain name is among the authorized set of
IP address(es).
2.5.3.2 Pass for MAIL FROM domain checks
A "Pass" result means that the client is authorized to use the
email domain name by verifying the email domain name is among
the authorized set of IP address(es).
I know this is all subjective, so I don't envy you :-) But I think if there
are areas of "question" then you hit it head on and minimize all attempts to
define how a SMTP server should behave. SMTP developers are not stupid,
they will know what has to be done. All SPF1 can do at this point is say:
"We have a SPF domain policy for this transaction and here
are the results. Act Accordingly"
---
Hector Santos, Santronics Software, Inc.
http://www.santronics.com