announcement about adding
Sender Policy Framework (SPF) capabilities
to the machine hosting the linux-kernel mailing list (lkml) has sparked a
The first step, it seems, is to add an SPF record for
vger.kernel.org and later this summer to enable SPF checking on incoming
email. Both steps are controversial and the majority of posters seem to
be against the change, but Matti Aarnio, one of the postmasters
for vger, plans to go ahead with the changes.
SPF is a technique that allows a domain to specify which hosts are allowed
to send email that have an envelope sender (i.e. SMTP MAIL FROM) using that
domain. A domain administrator adds a TXT record to the DNS entry for
the domain that describes all hosts allowed to send mail. This allows
receiving Mail Transfer Agents (MTAs) to look up the SPF record and
determine whether the domain
in the envelope has been forged -- at least in theory.
Unfortunately, there are a number of problems with this scheme, most having
to do with email forwarding. Consider the case where a user has a yahoo.com
email account that they are forwarding to their ISP. When yahoo forwards
email that it receives, it uses the original envelope sender, but that domain
has almost certainly not listed yahoo.com as an authorized sender. The
same issue occurs if a user is trying to use their yahoo.com email as
the sender, but are required to use their ISP's SMTP server. In that case,
Yahoo will rightly not have the ISP listed as a legitimate sender for
The SPF folks have suggested
solutions for these
problems, but many of them require fundamental changes in how MTAs operate.
The Sender Rewriting Scheme
in particular breaks longstanding email tradition by having forwarding
MTAs change the envelope sender as they forward email. Opponents of SPF
not only argue that changing this tradition is a bad idea, but also that it
is very unlikely to be widely implemented any time soon. Additionally,
Mail User Agents (MUAs) would need to learn about SRS encoding in order to
parse sender addresses for filtering email at the user end.
SPF does provide a way to definitively determine that an email is
an authorized host, but failing the SPF check does not in any way imply that
the email is invalid, as the mail could have been forwarded by a non-SRS
The main benefit for domains that publish SPF
records may be a reduction in the blowback from a 'joe job' (a spammer
uses a victim domain as the sender on a large amount of spam, some of which
bounces, leaving the victim to deal with all the bounce messages).
point out that
because of the forwarding problems, publishing an SPF record for your
domain essentially asks other MTAs to mark perfectly valid mail as suspicious
at best and forged at worst. Worse yet, some mail administrators are
configuring their MTAs to reject mail that fails SPF checking.
For the lkml, the immediate impact will be minimal, but still annoying to
some. People who have subscribed using addresses that are forwarded to
SPF-checking ISPs may no longer receive emails from the list. Some list
archiving software may also be affected. Once SPF checking is enabled, some
users may find their mail getting rejected depending on how strictly
the SPF policy is enforced. Expect another hue and cry on the lkml when
and if that happens.
to post comments)