-----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 Hector
Santos
Sent: Friday, January 07, 2005 6:04 AM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] Should I include major ISPs in SPF for our
hosted domains?
----- Original Message -----
From: "Julian Mehnle" <bulk(_at_)mehnle(_dot_)net>
To: <spf-discuss(_at_)v2(_dot_)listbox(_dot_)com>
Sent: Thursday, January 06, 2005 9:10 PM
Subject: RE: [spf-discuss] Should I include major ISPs in SPF for
our hosted
domains?
I meant:
1. Notice the SMTP-AUTH identity. See if MAIL FROM matches the
SMTP-AUTH
identity. If not, reject the MAIL FROM.
2. Notice the SMTP-AUTH identity. See if MAIL FROM matches the
SMTP-AUTH
identity. If not, simply override MAIL FROM with an e-mail address
that is appropriate for the SMTP-AUTH identity.
Thanks for correcting me.
Allow me to correct you again! :-)
Once an SMTP AUTH session is established, everthing else is MUTE!
SPF does
not apply.
SPF should augment the existing system by helping in filling in the holes
for Anonymous SMTP Transactions. An SMTP AUTH session is not anonymous.
The SPFC (SPF Council) should not take on issues that are already part of
the system to establish credentials. What you propose takes away from
backward compatibility, hence adds a greater barrier to adoption. In
addition, the SMTP AUTH concept is highly backend dependent.
My advice to SPFC - "Keep the eye on the prize."
I believe that you are talking about different ends of the process.
I will use my case as a specific example.
I use Pair Networks as my domain host. They provide SMTP services as part
of their domain hosting. Their SMTP server is relay.pair.com. Now they
have mechanisms in place to ensure than only their customers can send mail
from relay.pair.com, but they place no restrictions on what identities their
customers can use (yes, I have suggested that they do this differently in
the future).
So, in my SPF record, you will find ?a:relay.pair.com.
When you receive my message, you can tell it came from relay.pair.com.
There is no way the YOU can tell which of their 500,000 customers actually
sent the message. That's Pair's job (and strictly speaking outside the
scope of SPF).
I don't give relay.pair.com a pass because I don't trust those 500,000
customers (all but 4 of which I don't know) not to try and forge my domain.
What we are saying is that if the submitting SMTP server were to enforce
limits on what mail identities their customers were able to use, then these
shared servers could be safely given an SPF PASS.
It isn't part of SPF, but I believe it's definitely something SPF has an
interest in. If we make domain owners aware of the issue as they deploy SPF
records, I believe that they will create the market pressure for this added
layer of forgery protection. I don't care how the MTA operators do it, just
that they do.
Scott Kitterman