-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of wayne
Sent: Tuesday, May 31, 2005 11:03 AM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: [spf-discuss] New SPFv1 spec: draft-schlitt-spf-classic-02pre1
Well, I've decided to release the latest and greatest version of the
SPF spec. The reviews on the IETF lists have not generated as many
suggested corrections as the -00 review made earlier this year, and
even the discussions here seem to be slowing down.
My plans are as follows:
On Wednesday, there will be an SPF council meeting that needs to
review a few more things that we didn't get to in the last meeting.
On Friday, the two week pseudo-last-call will end in the IETF lists.
I will collect any further comments and publish a last -02preXX
release over the weekend.
First, fwiw, wrt the other issues I brought up, I'm comfortable with what's
in this draft, but I'm still not sanguine about the result definitions
(sorry). For dedicated MTAs, what is there is, I think, fine. I don't
think that from the spec it is entirely clear what the shared MTA user is
supposed to do. I'm going to try this again. Here are the current
definitions:
2.5.2. Neutral
The domain owner has explicitly stated that they don't know whether
the IP address is authorized or not. A "Neutral" result MUST be
treated exactly like the "None" result; the distinction exists only
for informational purposes. Treating "Neutral" more harshly than
"None" will discourage domain owners from testing the use of SPF
records (see Section 9.1).
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.
From those definitions, a discerning user of a shared MTA that did not have
technical measures in place to prohibit cross-user forgery would, I believe,
be confused about how to proceed....
The shared MTA is authorized and the domain owner knows the MTA is
authorized, so Neutral [The domain owner has explicitly stated that they
don't know whether the IP address is authorized or not.] doesn't fit. The
domain owner does know.
So then the domain owner looks at Pass and at first it looks good [A "Pass"
result means that the client is authorized to inject mail with the given
identity.] That's true. The MTA is authorized. Buth then the rest of the
definition gets troublesome [Further policy checks, such as reputation, or
black and/or white listing, can now proceed with confidence in the
identity.]. The domain owner knows that there is a risk that other
authorized users of the MTA might forge his domain. Giving a Pass
(volunteering to be exposed to reputation checks and RHSBL blocking) sounds
risky.
What to do? The first question is what does the SPF council/community think
that messages from this shared MTA should have as an SPF result? Unless you
want to give up on the "Further policy checks..." part of SPF, the anwer, I
think, has to be Neutral.
And in fact, if the discerning domain owner reads ahead, he sees this exact
concern addressed:
10.4. Cross-User Forgery
By definition, SPF policies just map domain names to sets of
authorized MTAs, not whole e-mail addresses to sets of authorized
users. Although the "l" macro (Section 8) provides a limited way to
define individual sets of authorized MTAs for specific e-mail
addresses, it is generally impossible to verify, through SPF, the use
of specific e-mail addresses by individual users of the same MTA.
It is up to mail services and their MTAs to directly prevent cross-
user forgery: based on SMTP AUTH ([RFC2554]), users should be
restricted to using only those e-mail addresses that are actually
under their control (see [I-D.gellens-submit-bis] section 6.1).
Another means to verify the identity of individual users is message
cryptography such as PGP ([RFC2440]) or S/MIME ([RFC3851]).
Now the answer hinted at here, is that he ought not be using a shared MTA
the allows the possibility of cross user forgery. The problem is that
today, that's essentially all of them. Just telling people in this
situation to go to another provider is not an answer that works today. If
that's as far as it goes, the spec is essentially telling this class of
shared MTA users to either set up their own mail server or come back to SPF
in a few years after the industry has changed. This is not, I would
suggest, a good answer.
Since changing the definition of Pass proved to be so popular, I'm going to,
instead, suggest that the definition of Neutral might be altered slightly to
deal with the current situation. Here's what I suggest, {proposed additions
to the current text are marked}:
2.5.2. Neutral
The domain owner has explicitly stated that they {either} don't know
whether the IP address is authorized or not {or they know that the
IP address is authorized, but that there is a technical risk that
other users authorized to send mail from the IP address may forge
the domain. See paragraph 10.4 for details}. A "Neutral"
result MUST be treated exactly like the "None" result; the
distinction exists only for informational purposes. Treating
"Neutral" more harshly than "None" will discourage domain owners
from testing the use of SPF records (see Section 9.1).
That would eliminate the ambiguity that I've been worried about here. Does
that work for everybody?
BTW, we need to be really clear on this. In all of Doug Otis' ranting about
the evils of SPF, this is the one issue that I believe we are vulnerable on.
We need to fix it.
Scott K