On Sat, 13 Aug 2005, Seth Goodman wrote:
From: Frank Ellermann [mailto:nobody(_at_)xyzzy(_dot_)claranet(_dot_)de]
Sent: Saturday, August 13, 2005 9:17 AM
<...>
The serious trouble starts if From, Sender, and Return-Path
are all different. Or if From and Return-Path are different,
and there is no Sender. If you then pick whatever you like
and test it against v=spf1 you'd get wrong results. Often
it will _apparently_ work - you'd catch that PayPal phish -
but not generally, you'd delete legit mails together with
the phishing crap => NOT RECOMMENDED.
Now this is an interesting topic, as there is some difference between what
the RFC's permit and what is recognized as good practice. Sorry for the
long post, there are a lot of issues here.
First look at the return-path. The RFC's say this is the address that
bounces should go to, and there is no MUST that I can find that says it has
to have any relation to the actual sender (whom I will define as the party
who is submitting the message for injection into the Internet message
stream). This is obviously different from today's best commercial practice,
and, in fact, the operating assumption behind SPF. For SPF to work, we must
assume that the return-path contains the domain of the actual sender. The
sender can designate some other individual, role account or automated system
(as in mailing list VERP addresses) as the local-part, unless forbidden by
exists: mechanisms in the SPF record. The return-path domain is what SPF
checks, so this is an additional constraint not currently in the RFC's.
No. It is the *receiver* that designates some other domain to receive
his email and forward it on to another mailbox. If is the receivers
responsibility to take this into account if they want to reject email
based on SPF.
The only current practice where the sender initiates such behaviour is when
using a greeting card or political message web site that sends email on your
behalf - and this is not all that common. I would argue that such web sites
should use their own domain as the return path in such email, and the better
ones do. After all, the website generates the email, and the user has only
partial control of the content and formatting. Furthermore, such sites rarely
do any checking on the emails entered. I have often been tempted to have some
fun putting in, for instance, Kerry's email on a petition to support Bush's
court nominees.
SPF fail. ISP's with customers who have vanity domains with hosting
providers that don't support SMTP AUTH might then actually recommend that
these customers publish SPF records to prevent domain forgery while allowing
them to use their domain names from the local ISP. I think this is
something that has been overlooked as a use for SPF that will help tighten
down submission rights without a lot of overhead on the part of ISP's. Why
accept a submitted message that is going to generate an SPF fail at the
receiving end? The domain owner has already said this is a forgery, so it
should be rejected at submission.
Amen. Checking SPF for outgoing mail is an often overlooked aspect.
I confess, that I have yet to implement it, but even for a small
business email server (which doesn't have the situation you describe),
it serves to detect mistakes in published SPF records before the
message gets out of the company network.
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.