On Tue, 14 Jul 2009 10:53:19 -0400 (EDT) "Stuart D. Gathman"
<stuart(_at_)bmsi(_dot_)com> 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.
I think that makes sense. What's not clear to me is why anything needs to
be changed in the standard to accomodate this?
Best guess is probably a good topic for additional discussion and
documentation, but I think the decision to make SPF strictly opt-in and not
include it in the RFC was and is the right one.
Scott K
-------------------------------------------
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