spf-discuss
[Top] [All Lists]

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

2010-01-14 10:46:02
At 12:30 14/01/2010  Thursday, Alessandro Vesely wrote:
David MacQuigg wrote:
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 spfv1, 
I think we are stuck with "receiver policy" (especially since checking HELO 
is optional).  Should we specify a precedence for spfv3?
Make HELO check a MUST?  Or keep HELO optional, but give precedence to MFROM?

The HELO check should be mandatory, and should take precedence over the MFROM 
check.  There is no "forwarding problem" (or any other excuse for failure) 
with the HELO check.  Furthermore, all the "bells and whistles" in an SPF 
record should not apply to the HELO check.  It should be a simple Pass/Fail, 
with an immediate SMTP REJECT on Fail.

We had already talked with John Klensin about this subject and concluded that 
it is hardly practicable because of brain damaged clients out there who don't 
even know their IP address. John suggested to use a different verb, VHLO, for 
clients who wish to undergo such a severe scrutiny. A "pass" would then result 
in some sort of whitelisting. I've detailed the finish for this line of 
thought in http://tools.ietf.org/html/draft-vesely-vhlo

IMHO, in spfv3, we can drop the whole idea of HELO-checking, because 
backscattering has been substantially reduced in the mean time, while SPF 
records for host names have never flown.

I disagree on the spf for host names front, spf's largest utility with zero 
potential for false positives is in host domains that never legitimately 
transmit mail.

it prevents all forgery of receive only, and never used domain address', 
and through receiver side policies that favor full spf adopting domains, over 
domains only using spf for their sending domains and not limiting the forgery 
of non-sending domains, I believe strongly that more domains will move toward 
spf blacklisting their non sending hosts, and this move alone will force others 
to do likewise due to 'peer pressure' as their reputation in receivers eyes 
lowers due to others rising

separating helo and mfrom scope into two essentially separate records
would simplify this for implementors of spf as instead of kludges to allow helo 
only with macros/redirects {such as mine for bigsvr.alandoherty.net

as then we could simply have
v=spf3/mfrom -all
v=spf3/helo -all
on all non externally mailing hostnames/domains 
and 
v=spf3/mfrom -all
v=spf3/helo a -all
on all helo identity domains
and
v=spf3/helo -all
v=spf3/mfrom ..........all
on all domains used in sending envelopes 

vhlo or anything similar could not be used by anyone {no matter how well 
administered their servers} without a new MTA becoming available and it being 
widely adopted

spf /senderid/spf3 dkim csv and others succeed purely due to them being 
possible to implement externally to the mta's via milters librarys plugins {and 
then eventually offered natively in closed box mailservers}

for spf3 to implement scopes we just need to recommend that receivers do a helo 
pass {on the helo}
then a mfrom pass {on the mfrom}

as no one can force them they can always decide to not do the helo pass {if say 
the api available cannot for example}

additionally we just need to recommend all domains have both scopes defined for 
the spfv3 to be syntactically valid
and recommend defining an spfv3 for all used/unused hostnames also

if they don't bother adding an spfv3 to their helo domain, they will not suffer 
rejection,
any more than sending via an external ISP that dosn't use SPF at all. except in 
receiver side reputation
{this alone will make it worthwhile given time}

I know many domains still add both CSV & spf and ptr-of xxx.mxout.xxx.xxx for 
this reason, as it adds to your positive rep if seen and understood to be an 
attempt to distinguish your mta as well administered and not ratware on a 
trojaned server.

for this reason alone many + your reputation for adding spf for non-helo 
non-sender domains

if you helo as hhh.[xxx.]domain.tld have fqrds of yyy.[zzz.]domain.tld and helo 
passes spf and ptr fails that gets you maximum possible spf reputation points 
here
{having helo resolve to connecting ip, having a csv-pass, having dnswl.org 
record listing can add further of course but not as much in one protocol}

{as it shows your MTA is authorised to run on that host, and that you have made 
best efforts to block trojans/ratware on the same host/ip (as they can only 
easily determine their own ptr id) } 



-------------------------------------------
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