spf-discuss
[Top] [All Lists]

Re: [spf-discuss] Resolving MFROM/HELO conflicts

2010-01-13 18:58:15
At 22:39 13/01/2010  Wednesday, Stuart D. Gathman wrote:
At 18:00 13/01/2010  Wednesday, Stuart D. Gathman wrote:
Here is a little nit that wasn't addressed in RFC4408.  If HELO SPF says 
to reject, but SPF for MAIL FROM says Pass, which takes precedence?  For 

On Wed, 13 Jan 2010, alan wrote:
add manditory /scope

v=spf3/helo rest of record...
or
v=spf3/mfrom rest of record...
... additional useful discussion that misses the original issue

Your proposal doesn't change the fact that HELO and MFROM may give
opposing results.  The scope might be a good idea, but HELO != MFROM
domain in most cases anyway, so it is not an issue for this thread.

MacQuig suggests making HELO mandatory with precedence.  (MUST check HELO,
if result is anything other than Pass, overall SPF result is Fail.)

My suggestion was to make HELO optional with MFROM having precedence.

well heres the part of the {yes it was long} mail that stated my preference

"and it would be hoped that all spfv3 checking functions would always check helo
if fail thats it!
if pass or assumed pass due to no record then continue on to check the mfrom 
details"

my justification is if the owner of the HELO domain explicitly claims it is 
forged,
who cares if the ratware is within the ISP of the forged envelope-sender 
{as the envelope-senders often have to allow large sweeps of IP's due to not 
having direct control of which IPS their ISP might designate to outgoing mail 
service}


Here is one possible matrix:

               MFROM
HELO            None    Neutral Softfail Fail   PermErr TempErr  Pass
None            None    Neutral Softfail Fail   PermErr TempErr  ?
Neutral Fail    Fail    Fail    Fail    PermErr TempErr  ?
SoftFail        Fail    Fail    Fail    Fail    PermErr TempErr  ?
Fail            Fail    Fail    Fail    Fail    PermErr TempErr  ?
PermErr PermErr PermErr Softfail Fail   PermErr TempErr  ?
TempErr TempErr TempErr Softfail Fail   PermErr TempErr  ?
Pass            Neutral Neutral Softfail Fail   PermErr TempErr  ?

so to re-use your matrix i would suggest {if using scopes and not allowing ~all 
?all in helo scope}
                MFROM
                None    Neutral Softfail Fail   PermErr TempErr  pass
HELO
None            None    Neutral Softfail Fail   PermErr TempErr  pass
Fail            Fail    Fail    Fail     Fail   Fail    Fail     fail
PermErr PermErr PermErr PermErr Fail    PermErr TempErr  pass
TempErr TempErr TempErr TempErr Fail    TempErr TempErr  pass
Pass            Neutral Neutral Softfail Fail   PermErr TempErr  pass

but personally i would see no reason for 1 result for two entirely {logically} 
unrelated tests
I currently report to users MUA's HELO-SPF-PASS and HELO-SPF-NONE and reject at 
rcpt-to if HELO-SPF-FAIL {without ever looking-up the mail-from}
I only process the mail-from identity SPF if the HELO is already non-fail {i do 
not fail on neutral or softfail but in 3 years have never seen one {and i have 
a special logwatcher looking}}
this is reported to the user as a standard SPF result header {few users reject 
on mfrom-spf-fail due to badly setup spfs/forwarders/and invite spam {that they 
seem to want}

but with helo domain its fairly cut n dry it either is one of the outbound ip's 
of that server/cluster or it isn't

thats why i think separate the two results, even separate the utility/syntax 
for checking/reporting them.
thus if helo spf fails, receivers can mark the stream for later reject with out 
any more overhead 
{of looking up mail-froms mx's spf rhdnsbl etc}
but in the case of a known false negative result {say incompetent ISP}, the 
receiver can learn of it and whitlist this ip against helo spf checks

then later the mfrom spf checks are done
like now in spfv1 allow mfrom through macros and redirects to succeed/fail 
based on helo value 
{but if the spf record doesn't reference the helo value directly it dosn't 
effect the result of the mfrom-spf-check}

then {for those receivers who reject nothing} have a standard header reporting 
the HELO-spf status FAIL/PASS/NONE/PE/TE
and the mfrom-spf-status of FAIL/PASS/SOFTFAIL/NEUTRAL/NONE/PE/TE

but as never should the helo success/pass result be dependant on anything but 
its ip 
my server name doesn't become a forgery just because an unexpected 
envelope-sender appears on the email
conversely a forgery of my server name doesn't become legit because an 
envelope-senders SPF

-- 
             Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
   Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.


-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ 
[http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com



-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ 
[http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com