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.
The main breakage present in this scheme right now is that it is _uncommon_
for ISP's to restrict the return-path domain their users can claim. This
can be fixed by the sender setting up their SPF record to tolerate the
additional MTA's. This permissiveness on the part of ISP's has been a
necessary evil, as many hosting providers don't support SMTP AUTH and force
their customers to submit mail through their local ISP's smarthosts. The
user then has two choices: use the local ISP's domain name as return-path,
as in sethg(_at_)itty-bitty-ISP(_dot_)com instead of the domain they paid for,
or lobby
their ISP to allow them for use their own domain on outgoing mail, which
then allows any forgery to pass through. ISP's have to listen to their
customers, so the typical practice is for local ISP's to permit forgeries on
outgoing messages, as long as the customer goes through their smarthost.
How _could_ the local ISP's restrict submissions, at least somewhat, without
the impractical step of maintaining a database of which users have the right
to use which domains? SPF happens to be a great tool for that, even for
ISP's that don't publish their own SPF record or check SPF on incoming. If
a submitted outgoing message uses a return-path domain that _does_ have an
SPF record, the ISP can decide whether to accept or deny the submission
based on whether their outgoing MTA sending that message would result in an
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.
Next, look at the originator headers you mentioned, From:, Sender: and let
me add Resent-From: and Resent-Sender:. RFC822/2822 is/are pretty explicit
as to how and when to use these headers. Mailing lists are classified as
remailers and have to keep the From: and add their own address as Sender:.
Forwarders are not supposed to change any of the headers. That's pretty
easy. People using "redirect" or "bounce" forwarding keep the From: header
and add their own address as the Sender: header. If the message has already
been redirected by this mechanism and someone wants to redirect further,
they keep all the existing headers and add a Resent-From:. If there are
multiple addresses in Resent-From:, there needs to be a Resent-Sender: field
to indicate the actual sender doing the redirection.
This behavior is explicitly spelled out in the RFC's and has been for a lot
of years. Systems that do not comply with this are BROKEN. What kind of
brokenness do we actually see in the field and how serious would the
consequences be if we rejected based on their misuse of the originator
headers? Most mailing lists add their own address in the Sender: header, so
that is not a real problem. MS MUA's, which unfortunately are the
predominant ones on the planet, only support what I would call encapsulation
forwarding. In this style, it is treated as a new message with appropriate
headers for the new sender. The forwarded message is either in-line with
the body or as a MIME attachment, but the previous headers are not part of
the new message header. Thunderbird is similar to MS MUA's in this regard,
as I believe are Netscape and Mozilla Suite. Pine handles the "redirect"
style of forwarding properly, so it poses no problem. I don't know what
Eudora, Mutt or other MUA's do.
It appears that the great majority of MUA's are neither capable of having
multiple From: addresses nor adding a Sender: header for either "redirect"
forwarding or submission on behalf of someone else, so there is nothing to
break. One major MUA (Pine) does support "redirect" forwarding correctly
and I don't know about the others mentioned. It appears that MUA's probably
do not contribute significantly to these headers being misused.
Rather, it is probably a few sites that send greeting cards or offer to send
an article to a friend that may not be configured correctly. Since there
are not that many sites like this (compared to the total number of domains),
and they are BROKEN according to the RFC's anyway, I would argue that should
we eventually decide to apply the SPF record to the current sender in the
2822 headers, it would not be that hard to fix the few problems that would
result. Email authentication via SPF or any other mechanism really does
mean that submission rights ought to be more limited than they are today.
It is better to stop forgeries at the source than at the recipient, so
anything we can do to encourage this would really be _a good thing_.
--
Seth Goodman