[DShield] SPF is fundamentally flawed
Jon R. Kibler
Jon.Kibler at aset.com
Fri Feb 20 20:26:46 GMT 2004
Erik van Straten wrote:
> > SPF is an attention getting and growing effort to fight "email address
> > forgery and makes it easier to identify spams, worms, and viruses".
> Major SPF problems:
> (1) Breaks email forwarding
> (2) In NO WAY prevents spoofing of the -usually visible- From: header
> (3) Does NOT prevent spoofing of the USER in -invisible- Return-Path
> (4) Fails completely when Return-Path: <>
I have been thinking about SPF on and off for a couple of years.
To me, it seems very convoluted for so little gain. I have come
to the conclusion that a better approach would be to create a new
type of DNS resource record that specified what domains were
legitimately handled by a given MTA. This schema would eliminate
bogus mail sources (open proxies, spamware, etc.) but require
EVERY legitimate MTA to have the required RRs to work.
What I have in mind would be a simple variation on a PTR record.
Let's call it a MO (mail out) record for the lack of a better
name. This record would specify all the domains that an MTA at
this IP address would handle.
For example (pretend 10.x.x.x is a routable address space):
; zone file for 5.10.in-addr.arpa.
@ IN SOA ...
; NS records go here
; mail out records
25.50 IN MO one.com.
25.50 IN MO two.com.
25.50 IN MO three.com.
100.50 IN MO golf.sprt.com.
100.50 IN MO bbal.sprt.com.
77.200 IN MO .
; ... etc.
Now, if some foreign MTA receives a connection from 10.5.50.25,
it knows that the sender must belong to the domains one.com,
two.com, or three.com, or be a bounce (<>). If the connection
is from 10.5.50.100, the sender's domain can be either one of
the subdomains golf.sprt.com or bbal.sprt.com.
In both of these cases, greater levels of qualification would
match the given RRs. For example, a connection from 10.5.50.25
would also be allowed to send mail from user.one.com and
news.one.com -- or any greater level of qualification. Likewise,
a connection from golf.sprt.com could have mail sent from
hiltonhead.golf.sprt.com but not from socer.sprt.com.
Keeping this same logic, then a connection that originates from
10.5.200.77 would be allowed to send email from any given sender
address, easily handling the problems with roaming users, cafes,
etc. (The world matches "."!)
Likewise, if a foreign MTA receives a connection from any 10.5/16
address without a MO record, the connection would be refused. This
would eliminate spamware MTAs on hijacked computers, but would not
do anything to correct the problem where hijacked computers are
routing mail through their legitimate MTA -- which is a growing
problem. (Some spammers are even smart enough (GASP! SHOCK!) to forge
the correct sending domain!) As I indicated in another posting,
the hijacking of legitimate MTAs can be controlled by SMTP AUTH
and STARTTLS deployment -- so that is an entirely separate issue.
Seems like this is more straight forward, easier to implement (once
BIND was changed to support it), and probably more flexible than SPF
appears to be.
Yes, it does not prevent forgery of email headers, but the information
from the MO records would make it easier to validate headers -- which
would be up to each MTA to accomplish in its own rule sets. For example,
with sendmail, using sendmail rules, you could validate a header against
MO data in 3 or 4 rules. Also, you would not have to add milter processes
and other hacks required by SPF -- everything could easily be
accomplished within the framework of sendmail's rules.
Also, regarding the issue of forged From: headers, any MTA that does
not add an X-Envelope-Sender: header is, IMHO, derelict in its duties.
Who well, my $0.02 worth.
Jon R. Kibler
Chief Technical Officer
Charleston, SC USA
Filtered by: TRUSTEM.COM's Email Filtering Service
No Spam. No Viruses. Just Good Clean Email.
More information about the list