spf-discuss
[Top] [All Lists]

Re: using HELO instead of MAIL FROM with SPF

2003-10-01 09:56:40

wayne writes:
In <20030930023137(_dot_)EF34416FC7(_at_)jmason(_dot_)org> 
jm(_at_)jmason(_dot_)org (Justin Mason) writes:

How viable is this -- using the HELO domain instead of the MAIL FROM
to use in the SPF check?

I'm running into trouble with getting reliable MAIL FROM data from message
headers, unless the MTA has been modified to add it specifically (many
don't do this by default, including sendmail).

"Return-Path" in particular is proving unreliable quite often. :(

Is finding a valid SMTP MAIL FROM address in the headers something
that will remain constant for a particular site, or will it depend on
the email that has been received?

It's site-specific.

Basically, in most current MTAs, the MAIL FROM address may be added
to the headers -- but as a standalone header, like Return-Path
or X-Envelope-From.   This header may be removed, replaced, or
left alone by later relays.

SpamAssassin can run in a variety of situations -- not just on the
external relay.  It can also be run on an internal machine (several
"trusted" relays in), or even behind a fetchmail hop.

Since we have no guarantee that a particular X-Envelope-From/Return-Path
header corresponds to the *most recent* Received line -- we have
difficulty performing SPF checks reliably; we could wind up checking
a MAIL FROM from one of the internal hops, against the IP of the
external machine.

This results in SPF failures -- which means very bad accuracy in my
testing :(

It might be best if you skipped the SPF checks if you can't reliably
determine the SMTP MAIL FROM address.  Or, give it a lower score
unless you can determine that it is accurate.

Well, it looks like we'll have to ask installers to modify sendmail.cf
(or similar) to add a new header.

Using "Return-Path" seems to be massively inaccurate in many situations,
e.g. upstream site adds header, but later relay does not remove it; or
fetchmail guesses the wrong value (using From: instead) when resending to
SMTP and adds a new Return-Path that way.  (yes, use of
fetchmail-to-local-sendmail seems to add a new Return-Path, unsurprising
when you think about it.)

I'm thinking of 2 options:

  1. ask sites to modify sendmail.cf/whatever to add MAIL FROM to their
  Received headers.  easy in sendmail, not sure about other MTAs

  2. ask sites to modify sendmail.cf/whatever to add a new header at their
  relays, containing the entire IP/HELO/MAIL FROM/RCPT TO set;
  X-SMTP-Envelope-Data: or similar.

I think I prefer 1, since for most modern MTAs the Received line contains
the IP/HELO/RCPT data anyway, and the semantics of having multiple
Received lines in most-to-least-recent order is well-defined.

What we can do is fall back to checking HELO strings as a lower-scored
not-quite-real-SPF backup, though.   The HELO data is always present and
correct in almost all Received lines (from UNIX MTAs at least).

--j.

-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your 
subscription, 
please go to 
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡


<Prev in Thread] Current Thread [Next in Thread>