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