spfdiscuss at alandoherty
Jul 14, 2009, 8:32 AM
Post #3 of 7
(1574 views)
Permalink
|
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 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"; 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>
> 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
|
