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