On Fri, 21 May 2004, Jim Lyon wrote:
The problem with this line of reasoning is that there are many small
businesses with ISPs that refuse to delegate the reverse lookup space.
That is not true. Almost all ISPs happily deligate reverse lookup if
you're buying business class service that requires more then 8 ip
addresses. The question is sometimes how "quickly" do the do it...
By using reverse IP lookup, the answer is under the control of the ISP,
not the small business.
I'm not recommending this be the only check, I recommend it as safety
check if EHLO does not pass (or if EHLO passes but they list whole world)
and so these "small businesses" would easily be able to override RDNS
records from their ISP if the ISP is not cooperative.
Aside from the fact that this will result in
wrong answers, it also represents a further power shift from end users
to ISPs, and is a bad idea for that reason.
End-users always have control, if you don't like your ISP, move on and
find another. As such economics would play a role with non-cooperative ISPs
To add a little concrete by way of an example, I own domain
wegelyon.org. My MTA operates at IP address 207.202.147.45. However, a
reverse IP lookup of this address yields
ip45.gte147.dsl-acs2.sea.iinet.com, which is not the same thing at all.
I'm assuming iinet.com knows you're running mail server on your dsl line
and their AUP allows for that, right? In that case, you'd ask them to add
a record that lets us know about it as well, but until they do you'd set
your system to use wegelyon.org in EHLO and add ip address 207.202.147.45
into EHLO acceptable ips list for that domain
Looking at something in the IN-ADDR space would get you IINet's opinion
of whether I have an MTA, not MY opinion of whether I have an MTA.
I note that its ISPs opinion about if they allow you to run your own MTA
anyway. Many large ISPs now redirect port 25 from their entire dsl or
cable pool and do not let you do direct connections and require you to use
their mail server. As such if you receive an ip from isp, its not entirely
under your control anyway.
But I note that I do not much like practice of capturing port 25 (and this
practice continues and is accelerating with more isps considering it as
way to stop zombie spam). I much rather like the idea of having ISP put
informational record and having end-user put such a record as well and
let the mail server decide based on this info.
William
-----Original Message-----
From: owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-mxcomp(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of
william(at)elan.net
Sent: Friday, May 21, 2004 3:25 AM
To: IETF MARID WG
Subject: [spf-discuss] PTR Domain validation idea
While some of you work on SPFID drafts for RFC822 From: header, I wanted
to run by others a different idea. Usually I advocated putting MARID
records into INADDR tree (as a resource to indicate if the ip should
be acting as SMTP client), the idea I have right now is to put MARID
records instead into domain of the PTR record for the ip.
This avoids problems you otherwise encounter with INADDR tree while
preserving
basicly same functionality. Additionally I propose this to be used in
conjunction with EHLO checking - if EHLO listed domain does not have
record indicating if it can act as SMTP client, then server can perform
same kind of lookup for domain it obtains by doing PTR query for the
connecting ip and it asks there if that ip can act as an smtp client.
This is pretty simple and should be effective against zombie computers
which in my view is the biggest problem and supports majority of spam
and that should be solved, the sooner the better.
Here is a practical example how this might work:
$ nslookup -querytype=PTR 216.151.192.4
4.192.151.216.in-addr.arpa name = wwwtelnet.elan.net.
$ nslookup -querytype=TXT wwwtelnet.elan.net
wwwtelnet.elan.net text = "v=spf1 -all"
$ nslookup -querytype=SRV _sa._smtp._tcp.wwwtelnet.elan.net
_sa._smtp._tcp.wwwtelnet.elan.net service = 0 0 0
2.0.0.127.IN-ADDR.ARPA.
P.S. For those who don't like PTR and INADDR tree in general, I note
that
AOL for one already requires that servers that connect to it have
valid PTR name. But valid name is not the same as valid smtp server
or the other way around.