spf-discuss
[Top] [All Lists]

Re: [spf-discuss] Proposed helo mechanism example

2009-07-14 11:33:05
you i think are missing the point the way this would be archived properly

if you wanted to go the mad route of defining legit sending ip's via their helo 
is

"v=spf1 include:%{h4r}.smtp.example.com -all"

and ensure the spf for each xx.smtp.example.com is
"v=spf1 A -all"


thus it will pass if helo=one of yours and connecting ip is pointed to by that 
helo's A

but as we are all trying to tell you if you have more than 1 mail host you are 
very unlikely to only send from the one domain

this way at least any envelope-domain could list the servers in question ie

example1.com and example2.com  and example.com are yours
you could still use
 "v=spf1 include:%{h4r}.smtp.example.com -all" in all three to allow to be sent 
from xx.smtp.example.com if validated


as i have repeatedly mentioned this will not get you round anyones checking for 
valid ptr {as its unconnected to spf}
{as far as the spf ptr: method i have yet to see any clue full organisations 
choose to use it}
as SPF is about limiting {as much as humanly possible, the ip's which will pass 
to only those needing it}



At 15:53 14/07/2009  Tuesday, Stuart D. Gathman wrote:
On Tue, 14 Jul 2009, alan wrote:

the helo is validated by testing the for an spf for
postmaster(_at_)smtp-out(_dot_)example(_dot_)com thats what SPF recommends 
already

That validates the HELO SPF *identity*.  I am not talking about that.
If one wants to use the HELO name as a substitute PTR name as I proposed
(for validating the MAIL FROM identity), it is "validated" the same as a 
DNS PTR record.

Apart from those missing the point, the main argument against the
proposal is that it isn't needed because the MTAs could be authorized 
(for MAIL FROM - we are not talking about the HELO identity) by
a list of IP4 or A mechanisms.  The very senders (like me) who might want
to use HELO as a PTR, are going to have few MTAs - certainly less than 100 in
fact.  Any more, and they will have 256 IP blocks and have no trouble setting
PTR records.  In fact, more than 32 IPs, and there will probably be
enough money flowing to the ISP, that they will be more likely to 
respond to PTR requests, or provide an automated interface.

So the worst case is 100 MTAs in a /25 block - which should probably
be listed with an IP4:1.2.3.4/25.  But, for those missing the point,
an example might help:  

A small email admin has 12 MTAs on 4 /29 networks in 4 cities.  He doesn't want
to have a big SPF record listing them individually.  He doesn't want to have
two dummy A records with 6 Ips each.  They aren't the same as the incoming
MXes.   His ISP is the local cable monopoly in 4 cities, and getting their DNS
flunkies to update the PTR records in a timely and accurate manner is not
feasible.  So, he establishes a naming convention: m1.smtp.example.com to
m12.smtp.example.com and uses those for HELO on the 12 MTAs.  He then creates
an SPFv3 record as

example.com     IN SPF "v=spf3.14 helo:smtp.example.com -all"

This authorizes example.com mail from the MTAs in all four cities.

When checking that SPF record, receivers lookup the A or AAAA RR for the HELO
name, and if there is an IP matching the connect IP, it is "validated",
otherwise (i.e. the HELO is syntactically invalid or there is no A or AAAA
RR) the HELO fails to match.  If the HELO name is valid, the HELO mechanism
matches if the name ends with the same labels as the argument - analogous
to the PTR mechanism.

I use helo:%{d} now for bestguess.  Those talking about "admin relationships"
are completely missing the point.  I couldn't care less about admin
relationships among spammers.  When I get an email with a best guess
SPF pass like this:

2009Jul14 10:32:47 [5519] Received-SPF: None (mail.bmsi.com: 64.16.195.145 is 
neither permitted nor denied by domain of headvillage.com) 
client-ip=64.16.195.145; 
envelope-from="DoggieBathroom(_at_)headvillage(_dot_)com"; 
helo=ssl.headvillage.com; receiver=mail.bmsi.com; mechanism=a/24; 
x-bestguess=pass; x-helo-spf=pass; identity=mailfrom

I can hit the blacklist button for headvillage.com without any qualms.

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



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