At 01:22 14/05/2009 Thursday, Sanford Whiteman wrote:
no other SPF checks are considered trusted if HELO/EHLO doesn't pass
RFC 4408 doesn't state that "no other SPF checks are considered
trusted if HELO/EHLO doesn't pass." Your assertion is instantly
falsified by testing w/the baked-to-order pySPF toolset on the
website.
i never meant to imply it was
An edge case in which a PASS on HELO (as opposed to NONE or any other
result on HELO) might be a constant prerequisite when sending to a
given server is if that server has the custom policy "if *any*
checkable part of a given envelope has a published SPF record, then
*all* checkable parts must have published SPF and PASS." Or, of
course, a policy that requires PASS on HELO for every connection,
period. Such policies may be interesting, but beyond RFC.
i wasn't talking about RFC compliance but simply Best practice
most scoring systems i've seen the internals of, mine included
{i'm only detailing the SPF related ones as the Sender-id and other ones are
irrelevant to this list}
positive trust score for FcRDNS checking out {most reject on fail, I negative
score}
{means ip is traceable to org but little else}
bigger trust score for FcRDNS+helo-spf-pass {none on no-spf} negative-points on
fail-spf
{means IP is running an MTA}
{all tend to do this much} mine offer an extra two currently
yet bigger trust score on FcRDNS+helo-spf-pass+{FcRDN not equal to but same
domain as HELO} no effect on fail
{means ip is an MTA and sending application is likely the MTA not another
malicious application {on the same machine or NAT'd via same gateway}}
yet bigger trust score on FcRDNS checking out+helo-spf-pass+{FcRDN not equal to
but same domain as HELO}+spf for FcRDNS being fail
{means ip is an MTA and sending application is likely the MTA
and admin is consciously blocking malicious application via his SPF record for
FcRDNS name}
{as all recent spam-bots will, if they find FcRDNS, use it in their HELO}
{mine does this just to promote the concept of differentiating MTA's from non
MTA's}
needless to say i also don't bother doing these extra bits of work till long
after the RBL's etc have been used for scoring/blocking}
these checks and many more are added to the spamassain scoring of a message for
end of DATA rejects
{also users are allowed to make {RCPT TO:} block decisions based on any
datapoint themselves if they want to use their address as a LARTing tool few
except the draconian ones do, that said one blocks all except when from and
connecting IP matches his own whitelists}
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: 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