AOL is already stating their right to refuse to accept messages that contain
no PTR record.
This is an actual log entry from a message sent TO an AOL e-mail server:
11:30 00:13 SMTP-(0600388E) Connect aol.com [205.188.158.121:25] (1)
11:30 00:13 SMTP-(0600388E) 220-rly-yi04.mx.aol.com ESMTP
mail_relay_in-yi4.1; Tue, 30 Nov 2004 01:13:01 -0500
11:30 00:13 SMTP-(0600388E) 220-America Online (AOL) and its affiliated
companies do not
11:30 00:13 SMTP-(0600388E) 220- authorize the use of its proprietary
computers and computer
11:30 00:13 SMTP-(0600388E) 220- networks to accept, transmit, or
distribute unsolicited bulk
11:30 00:13 SMTP-(0600388E) 220- e-mail sent from the internet.
Effective immediately: AOL
11:30 00:13 SMTP-(0600388E) 220- may no longer accept connections from
IP addresses which
11:30 00:13 SMTP-(0600388E) 220 have no reverse-DNS (PTR record)
assigned.
By AOL's rejection of e-mail without PTR records, they are setting a
precedent that can clearly be presented to ISPs who don't have PTR records -
their mail may be rejected by AOL, NETSCAPE and COMPUSERVE.
-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of Greg
Connor
Sent: Tuesday, November 30, 2004 17:51
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: RE: [spf-discuss] PTR problems
This topic has been discussed many times on this list, and is
definitely relevant. As long as there are those that would use reverse
lookup to verify email (SPF has so far side-stepped the issue for the
most part), the potential is there to run into problems like these.
The domain owner is probably not even aware of this problem, although
I have tried to bring it to their attention. Because the reverse
lookup process is a top down driven process, it is sometimes very
difficult to get the upstream ISP to resolve
On Mon, 29 Nov 2004, Mark wrote:
I do not subscribe to the idea that SPF should lax its checks because
someone's DNS might be broken. The only-ever solution to broken DNS is to
fix it. Pronto.
I agree with Mark. The folks who suffer from poor in-addr.arpa service
should
complain loudly and often to their service provider. They really should
have
proper in-addr.arpa service -- if not, they are paying good money for
internet
service and getting put on something other than the Internet.
However, that should not prevent others of us from using ptr: mechanism if
we
want to. If my ISP drops my in-addr.arpa service, and I'm relying on ptr:
alone, my mail may be rejected, or delayed, or whatever. That's the risk I
take with using ptr: in my record. (There is a similar problem with exists:
-- the DNS server must be up for that to work.) But let's not water down
SPF
because of it. Those folks who choose to use ptr: can assume the risk.
I don't think the original post in the thread mentioned that we should get
rid
of ptr:, only that there are "problems associated with it". It would
probably
be a good idea to mention this in a FAQ somewhere, so that people who use
ptr:
because it's convenient have been given fair warning.
--
Greg Connor
gconnor(_at_)nekodojo(_dot_)org
Everyone says that having power is a great responsibility. This is a lot
of bunk. Responsibility is when someone can blame you if something goes
wrong. When you have power you are surrounded by people whose job it is
to take the blame for your mistakes. If they're smart, that is.
-- Cerebus, "On Governing"
-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper! http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com