ietf-mxcomp
[Top] [All Lists]

Re: Why we should choose the RFC2821 MAIL FROM/HELO identities

2004-03-24 16:23:03

Well, actually, the administrative burden imposed by SPF is much higher,
for mobile users and users who employ third-party services (like
greeting card and kiosks).

I do not believe that the burden imposed by SPF is much higher than
DomainKeys, but that is based on a very fuzzy idea of how DomainKeys
would have to work.  As far as I can tell, there are some subtle
details that cause DomainKeys to be either almost useless or to require
massive changes in the email infrastructure.

I agree here -- SPF as it's currently specified only checks SMTP-level
fields, not headers -- it's easy enough to rewrite any third-party
service to use their own domain as the sending domain in the MAIL FROM.
Their numbers are far fewer than end-users, so requiring software
changes there is probably the smallest breakage.

SPF also codifies what's rapidly becoming a best practice: rejecting
mail that claims to come from one place (domain) when in fact it is
coming from an unrelated (and unauthorized) place (specified with a map
in the domain). Already, many ISPs reject mail claiming to be from a
user in their domain if it does not carry with it some local
authorization (whether source IP address, specific HELO, out-of-band
authorization protocol data or in-band data such as SMTP AUTH).
Rejecting such mail makes tracking of abuse much simpler, allows much
better policy enforcement and by making even a weak verification of the
MAIL FROM, it makes it a much more trustworthy piece of information.

Directing bounces is the most difficult part of such an exchange, since
SMTP specifies that the MAIL FROM is also the place where bounces should
go to, leaving no application protocol level source of identity data.
The only solution is to have the originating system relay bounces to the
appropriate destination as a separate transaction, instead of
short-circuiting and going straight to the unverifiable sender address.

In essence, by validating MAIL FROM, it allows semantics such as 

  if MAIL FROM != RFC2822-From, then display as "From:
  <greetingcards(_at_)example(_dot_)com> on behalf of 
<joe(_at_)example(_dot_)org>"

Which I consider very useful. At the moment, the
<greetingcards(_at_)example(_dot_)com> is totally useless, because I have no
indication that it is legitimate or forged simply to coerce me into
thinking the mail is valid.

The main reason I prefer validating MAIL FROM instead of header fields
is that it maintains some semblance of layering: RFC2821 specifically
tries to avoid relying on RFC{2,}822 semantics too much:

  When RFC 822 format [7, 32] is being used, the mail data include the
  memo header items such as Date, Subject, To, Cc, From.  Server SMTP
  systems SHOULD NOT reject messages based on perceived defects in the
  RFC 822 or MIME [12] message header or message body.  In particular,
  they MUST NOT reject messages in which the numbers of Resent-fields do
  not match or Resent-to appears without Resent-from and/or Resent-
  date.

That hands-off approach lets future mail formats interoperate fairly
well. "Received:" headers must be prepended, allowing easy removal, as
is SPF's proposed "Received-SPF:" header. It's also lightweight: the
usual SPF record's query bandwidth is near the minimum used in a single
SMTP session to transmit a message with no data. With DNS caching, a
mail delivery system should see no more than a few percent increase in
bandwidth in even the pathological case.

SPF-like proposals also scale well -- in addition to the proven
scalability of DNS, ability to specify netblocks as designated senders
(even the wide open 0.0.0.0/0 or ::/0) allows domains enough flexibility
to do most authorization schemes, and the "exists:" mechanism in SPF
allows dynamic authorization for mobile senders -- and by design, that
service could be contracted out to a third party if a domain doesn't
wish to run its own dynamic authorization server, simply by referencing
a DNS-based list maintained elsewhere.

I hope this comes off clearly.

With regards to all,
    Aredridel.