spf-discuss
[Top] [All Lists]

Re: Possible SPF machine-domain loophole???

2004-02-29 14:48:22
On Sun, Feb 29, 2004 at 03:39:41PM -0500, Theo Schlossnagle wrote:

                                                     There are 
sufficiently many legacy sending systems out there that use local 
labels in their EHLO args (like production_server) that blocking them 
would drop a lot of legitimate business mail.

Of course, checking a malformed HELO against SPF will result in
unknown, not in fail.  As such, only clear forgeries will be found.

I agree that this is spoofing... But I don't see how analysis of the 
EHLO argument will completely rectify the issue.  It only makes sure 
that _you_ won't add that spoofed info into the Received header you 
create.  However, it isn't _you_ we are worried about, it is the "bad 
guy" who sent the email.

This is nothing new.  With or without SPF checks on HELO, I can
only look at headers inserted by parties I trust. This is not going
to change. What may change, is that I get another reason NOT to trust
a host connecting to me.

With SPF I think I *can* check the HELO for SPF_FAIL. See the
part of this thread with subject "Design choice vs loophole".

Systems that choose to trust me (including but not limited to my own)
will be able to check the last Received-by header line.

In other words: loose nothing, gain a bit.

                          It is trivial and common for spammers to 
place bogus Received headers in an email before it every gets to 
your/my/final MX.  So, if I was malicious, I could put whatever ehlo 
argument or IP address in faked pre-existing received headers.

But you still would have to pass SPF to deliver the mail to me.

Failing SPF means I *won't* trust the headers.
Passing SPF does NOT mean I *will* trust the headers.
Failing SPF-on-HELO will mean I won't trust the headers.
Passing SPF-on-HELO does NOT mean I will trust the headers.

I think it is an imperfect fix as you can't stipulate the correctness 
of _all_ the Received headers.  While I am all for things that _mostly 
work_ (I am a very practical person), I think that SPF's purpose AS IS 
is both well defined and it meets the stated purpose without 
compromise.  It currently excludes EHLO domain name spoofing from it's 
charter.  As such, it doesn't try to tackle something it can't 
completely solved (not to say another technology couldn't solve it).  
If it was included, and solved the problem imperfectly, then it weakens 
the overall "correctness" of SPF.

This is where I'm not following you.  I see no one-to-one relationship
between checking HELO and checking received headers.

There is a relationship between HELO and SPF.  I think the following
quote from the draft is relevant here:

  `` When the envelope sender has no domain, a
     client MUST use the HELO domain instead.  If the HELO argument does
     not provide an FQDN, SPF processing terminates with "unknown".
  ''

SPF prefers "mail from" over "helo".  SPF does not ignore helo in all
cases.  This means after being able to communicate for a while, suddenly
you will reject a bounce from that domain because the HELO is wrong.

Example:

Suppose you are sending from an MTA that announces "HELO somefake.tld"
and somefake.tld would be rejected by SPF.  However, since you are
sending as "you(_at_)yourdomain(_dot_)tld" and yourdomain.tld passes SPF, there
is no visible problem.  Suddenly, there is a problem delivering to you.
A bounce is generated, using the null sender.  According to the draft, I
MUST assume "postmaster(_at_)somefake(_dot_)tld" as the responsible sender.
(BTW: this is a RECOMMENDED MUST ?!?)

All _seems_ well, until a problem occurs.  This is what I call imperfect.
Always checking HELO means such a problem is recognized early and will
be dealt with (whitelisting, or fixing the problem).

cheers,
Alex
-- 
begin  sig
http://www.googlism.com/index.htm?ism=alex+van+den+bogaerdt&type=1
This message was produced without any <iframe tags