[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:
> 
> List,
> 
> http://isc.incidents.org/diary.html?date=2004-02-16
> > 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
A.S.E.T., Inc.
Charleston, SC  USA
(843) 849-8214




==================================================
Filtered by: TRUSTEM.COM's Email Filtering Service
http://www.trustem.com/
No Spam. No Viruses. Just Good Clean Email.



More information about the list mailing list