[Services] AT&T rPTR DNS Record Issues

[Services] AT&T rPTR DNS Record Issues
Links: home · search · speed test · login · more ·

Links: Reply New Topic
Forums » AT&T » AT&T Southeast » [Services] AT&T rPTR DNS Record Issues

anon @ 24th Oct 01:49PM:
[Services] AT&T rPTR DNS Record Issues

OK, so here's the deal. Some of you may know that AT&T MIS is not providing Reverse DNS Pointer records to their customers with static IPs unless they turn over ragistrar and hosting control of customer owned domains over to AT&T. Because of this, customers hosting their own email servers unfortunately cannot abide with normal antispam practices by providing a rPTR DNS record pointing back to their mail server. (This of course leads to a lot of "false positives" on customer sent email to other places.) Right now, AT&T MIS is hiding behind a loosely worded and weak "company policy" which basically dictates "we are too lazy to keep our DNS servers clean, so we decided just not to offer PTR records to our customers reguardless of us being the ONLY ISP in the country and maybe even the world to do this".

So, I ask everyone here....

Is AT&T MIS breaking Net Neutrality by doing this. In my viewpoint, they are. They are holding PTR records hostage until you turn over registrar and hosting control of your domain to them or until you leave them as an ISP.

Who else believes the FCC should investigate AT&T for their practices?
reply

graysonf @ 24th Oct 03:06PM:
Re: [Services] AT&T rPTR DNS Record Issues

Just take your business elsewhere.
reply

jlp09550 @ 24th Oct 03:17PM:
Re: [Services] AT&T rPTR DNS Record Issues

said by graysonf :

Just take your business elsewhere.

Agreed.
reply

NetFixer @ 24th Oct 04:37PM:
Re: [Services] AT&T rPTR DNS Record Issues

As others have said, if AT&T's PTR record policy is not suitable for your needs, take your business elsewhere.

If for some reason beyond your control (but you still control your in-house email server) you must remain with AT&T as your ISP, then you might want to consider using mail.bellsouth.net as a smarthost for your outbound email. Doing that and creating an SPF record similar to "v=spf1 a include:fmailhost.isp.att.net include:mail.bellsouth.net ~all" might alleviate your bounced/rejected email problem.

Here are a couple of emails I just sent using the above method to a Windows Live email address and a Comcast email address. I chose those two providers as examples because in the past both have refused to accept email from my domains even when I had a valid PTR record and an SPF record. Since I started using the ISP's email server as a smarthost (I have used AT&T, Covad, Comcast and Compuserve at various times), I have not had any sent email bounced as spam.

Email sent to a Windows Live email address:

From - Sat Oct 24 18:28:42 2009X-Account-Key: account4X-UIDL: F1589EFD-C0F4-11DE-A434-002264C17D50X-Mozilla-Status: 0000X-Mozilla-Status2: 00000000X-Mozilla-Keys:                                                                                 X-Message-Delivery: Vj0xLjE7dXM9MDtsPTA7YT0xO0Q9MTtTQ0w9Mg==X-Message-Status: n:0X-SID-PRA: My Name <myname@dcs-net.net>X-Message-Info: JGTYoYF78jH6fwBPqEbRmz76igjYLqCOue6pzlyH7vNHtWYsffaNTLeJCvMhqrEDn9oINa2B84XaeppHEN 0WGZVsg9nJFbAoReceived: from fmailhost04.isp.att.net ([204.127.217.104]) by snt0-mc4-f11.Snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 24 Oct 2009 16:28:37 -0700Received: from webhost.dcs-net (adsl-074-170-163-101.sip.bna.bellsouth.net[74.170.163.101])          by isp.att.net (frfwmhc04) with ESMTP          id <20091024232837H0400idi6re>; Sat, 24 Oct 2009 23:28:37 +0000X-Originating-IP: [74.170.163.101]Received: from [192.168.10.100] (rws-wks.dcs-net [192.168.10.100])by webhost.dcs-net (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id n9ONSaFL015397for <my_name@msn.com>; Sat, 24 Oct 2009 18:28:36 -0500Message-ID: <4AE38D92.1020007@dcs-net.net>Date: Sat, 24 Oct 2009 18:28:18 -0500From: My Name <myname@dcs-net.net>Reply-To: myname@dcs-net.netOrganization: DCS EnterprisesUser-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23) Gecko/20090825 SeaMonkey/1.1.18MIME-Version: 1.0To: My Name <my_name@msn.com>Subject: Test MessageContent-Type: text/plain; charset=ISO-8859-1; format=flowedContent-Transfer-Encoding: 7bitReturn-Path: myname@dcs-net.netX-OriginalArrivalTime: 24 Oct 2009 23:28:37.0777 (UTC) FILETIME=[B6729010:01CA5501] This is just a test message sent to a Microsoft email account.

Email sent to a Comcast email address:

From - Sat Oct 24 18:28:35 2009X-Account-Key: account12X-UIDL: 5940.rHGWOINXkqBwJ5L5qeCjtMKqHeQ=X-Mozilla-Status: 0000X-Mozilla-Status2: 00000000X-Mozilla-Keys:                                                                                 Return-Path: myname@dcs-net.netReceived: from imta36.westchester.pa.mail.comcast.net (LHLO imta36.westchester.pa.mail.comcast.net) (76.96.58.251) by sz0151.ev.mail.comcast.net with LMTP; Sat, 24 Oct 2009 23:27:35 +0000 (UTC)Received: from fmailhost05.isp.att.net ([207.115.11.55])by imta36.westchester.pa.mail.comcast.net with comcastid wnTY1c01W1BFT3j0cnTbLU; Sat, 24 Oct 2009 23:27:35 +0000X-CAA-SPAM: N00000X-Authority-Analysis: v=1.0 c=1 a=OTLaxrTT0iEA:10 a=-MdkRRnrcs8A:10 a=yDE68GKXXmaHa7T5nOcFOQ==:17 a=TGKN-jQO9cihd_YND3MA:9 a=WIPP1h7C6pQuqzKAygugvGnPtKoA:4Received: from webhost.dcs-net (adsl-074-170-163-101.sip.bna.bellsouth.net[74.170.163.101])          by isp.att.net (frfwmhc05) with ESMTP          id <20091024232733H05005mjvhe>; Sat, 24 Oct 2009 23:27:33 +0000X-Originating-IP: [74.170.163.101]Received: from [192.168.10.100] (rws-wks.dcs-net [192.168.10.100])by webhost.dcs-net (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id n9ONRWjF015394for <myname@comcast.net>; Sat, 24 Oct 2009 18:27:32 -0500Message-ID: <4AE38D52.7090107@dcs-net.net>Date: Sat, 24 Oct 2009 18:27:14 -0500From: My Name <myname@dcs-net.net>Reply-To: myname@dcs-net.netOrganization: DCS EnterprisesUser-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.23) Gecko/20090825 SeaMonkey/1.1.18MIME-Version: 1.0To: My Name <myname@comcast.net>Subject: Test MessageContent-Type: text/plain; charset=ISO-8859-1; format=flowedContent-Transfer-Encoding: 7bit This is just a test message to a Comcast email address.

--
History does not long entrust the care of freedom to the weak or the timid.
-- Dwight D. Eisenhower
The tree of liberty must be refreshed from time to time with the blood of patriots and tyrants.
-- Thomas Jefferson

reply

anon @ 26th Oct 11:00PM:
Re: [Services] AT&T rPTR DNS Record Issues

Sometimes another ISP is not an option (depends on location) and using a smarthost isn't always an option either due to certain reasons.

I think an FCC complain is in their very near future. They shouldn't be allowed to have such non-standard practices.
reply

NetFixer @ 26th Oct 11:37PM:
Re: [Services] AT&T rPTR DNS Record Issues

said by not :

I think an FCC complain is in their very near future. They shouldn't be allowed to have such non-standard practices.

Have fun complaining. I think you will find that complaining about the current AT&T PTR record policy to the FCC will provide plenty of entertainment for the FCC official receiving the complaint since I can't think of any FCC regulation that covers that.

Even complaining to IANA or ARIN is not likely to do anything productive since I think their position would be that the IP address block in question is assigned to AT&T, and how they administer it is entirely their prerogative. Do a whois query (a whois query, not a DNS query) on the IP address block to see if it is registered to your company or to AT&T. If AT&T has actually officially reassigned that IP address block to your company, then perhaps IANA or ARIN might intervene on your behalf and force AT&T to give you full control of DNS for that entire IP block
--
History does not long entrust the care of freedom to the weak or the timid.
-- Dwight D. Eisenhower
The tree of liberty must be refreshed from time to time with the blood of patriots and tyrants.
-- Thomas Jefferson
reply

graysonf @ 27th Oct 11:01AM:
Re: [Services] AT&T rPTR DNS Record Issues

SWIPing a netblock doesn't push PTR administration responsibilities or privileges onto the netblock user. It's still with the outfit that originally took the block from ARIN.
reply

NetFixer @ 27th Oct 03:24PM:
Re: [Services] AT&T rPTR DNS Record Issues

said by graysonf :

SWIPing a netblock doesn't push PTR administration responsibilities or privileges onto the netblock user. It's still with the outfit that originally took the block from ARIN.

Thanks for the update. I could not remember for sure if the rDNS/PTR responsibility got passed on by the SWIP process or not and I was too lazy to search ARIN for the answer (I figured that the OP's attorney could/should do that before filing a complaint with ARIN).
--
History does not long entrust the care of freedom to the weak or the timid.
-- Dwight D. Eisenhower
The tree of liberty must be refreshed from time to time with the blood of patriots and tyrants.
-- Thomas Jefferson
reply