...... Original Message .......
On Mon, 6 Jun 2005 22:06:55 +0200 Julian Mehnle <bulk(_at_)mehnle(_dot_)net>
wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Scott Kitterman wrote:
[...] 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.
[...]
From [the Neutral and Pass] 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...
[...]
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:
[quote of section 10.4, "Cross-User Forgery"]
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.
We resolved the issue as follows:
| 2.5.2. Neutral
|
| The domain owner has explicitly stated that they cannot or do not
| want to assert whether the IP address is authorized or not. [...]
| 2.5.3. Pass
|
| A "Pass" result means that the client is authorized to inject mail
| with the given identity. The domain can now, in the sense of
| reputation, be considered responsible for sending the message.
| Further policy checks can now proceed with confidence in the
| legitimate use of the identity.
| 10.4. Cross-User Forgery
|
| [...]
| 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). [...]
This implies the following vision:
From the definition of Pass, it follows that by asserting "+" (Pass) for
an IP address a domain declares that any mail coming from that IP address
and bearing the domain in the identity in question, may be considered by
receivers as having been sent by that domain.
This matches what draft-mengwong-spf-00 and -01 have been saying since
February 2003.
Domain owners are well advised not to assert "+" (Pass) for MTAs they do
not trust to prevent cross-user forgery. If they do it anyway (which is
their full right), they can't disclaim responsibility for cases of cross-
user forgery.
We had to choose between imposing onto domain owners the burden to secure
their authorized MTAs (or not assert "+"/Pass for them) and weakening the
meaning of Pass to a point where it means practically nothing; it would
not even have meant "you can confidently send bounces to this address" due
to the cross-user forgery problem.
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.
No, there are more alternatives. Domain owners can either assert "?"
(Neutral) for insecure MTAs (which is still useful if they assert "-" or
"~" for IP addresses that are definitely not authorized), or they can take
on the risk of their domain becoming ill-reputed due to cross-user
forgery.
There is really no way to solve this issue apart from solving the cross-
user forgery problem itself. I predict that as soon as cross-user forgery
becomes a common phenomenon, ISPs will start to implement mechanisms to
prevent it.
Thanks. I believe that these changes resolve the ambiguity that I was
worried about.
Scott K