Email, DNS, and bad ISP tech support?

qsecofr

qsecofr

Hi,

Recently moved and switched ISP. With the move, email from my server is being rejected by other ISP's. Example:
http://postmaster.comcast.net/smtp-error-codes.php#554

I expect the error is due to Comcast performing a reverse DNS lookup on my static IP, and the hostname does not match that on the forward lookup. Please correct me if I'm wrong.. I host my own domain, using BIND-9.4. When I
Code: 
dig @my.own.net my.own.net A
dig @my.own.net -x ww.xx.yy.zz
dig @aa.bb.cc.dd my.own.net A
dig @aa.bb.cc.dd -x ww.xx.yy.zz
I get authoritative answers from my own name server. I get no error and a non-authoritative answer from my ISP's name server. But when I query my ISP's server for my IP address I get an NXDOMAIN error. Which leads me to believe the URL error is one of DNS and not strictly SMTP.

Trying to explain my error to tech support wasn't easy. They recommended I use port 587 and SSL-enable the channel. In the end I don't think either of us understood the other. Does my sendmail really talk to their mail server for every outgoing email I send? /var/log/maillog suggests not. But again, I could be displaying my ignorance.

At my previous address I vaguely recall asking the ISP to either release or point the IP address to my domain. But I don't remember how I may have worded it.

Is there is "standard" phrasing that ISP tech support people will instantly understand? And am I understanding the nature of my problem correctly?
 
Where it matters is how DNS looks to the machine receiving mail. Actual error messages might help. There are various sites that will show whether a particular address is on any of a number of IP-based blacklists.

If
Code: 
define(`SMART_HOST', `example.com')
is in your hostname.mc, sendmail(8) will send all outgoing email through the defined smarthost, usually the ISP. Many ISPs require dynamic addresses to send mail that way.
 
Trying to explain my error to tech support wasn't easy. They recommended I use port 587 and SSL-enable the channel. In the end I don't think either of us understood the other. Does my sendmail really talk to their mail server for every outgoing email I send? /var/log/maillog suggests not. But again, I could be displaying my ignorance.
Click to expand...

Are you on a business plan? Because tech support for this sort of thing is why business plans cost more. Also, if you aren't on a business plan, the IP range allocated to you may have been listed as specifically not to be allowed to send email. If you can supply SMTP headers for the bounce messages I can investigate further.

There are many reasons email may be blocked, but if you are on a non-static IP without a reverse DNS record on a non-business plan with the ISP, there will likely be quite a few things to fix.
 
In fact I do purchase a business service plan, and purchase a static IP in addition.

The hostname.mc reads
Code: 
grep 'SMART' /etc/mail/motive.mc
dnl define(`SMART_HOST', `your.isp.mail.server')
And the sendmail config hadn't changed since mid-2010, all the while operational.

I did suspect I needed SPF records in my DNS, and added them the other day - after having experienced errors like the below and to no avail. And I did check the validity using openspf.org tools.

At first I was a bit leery of what tech support was telling me. The first question was "which version of Outlook am I running?" And I wasn't quite sure I was communicating the nature of my issue effectively. But before I argue with them I want to inform myself better.

The body of the bounced message contains:
Code: 
   ----- Transcript of session follows -----
... while talking to mx3.comcast.net.:
<<< 554 imta11.westchester.pa.mail.comcast.net comcast ww.xx.yy.zz Comcast requires that all mail servers
 must have a PTR record with a valid Reverse DNS entry. Currently your mail server does not fill that requirement.
 For more information, refer to: http://postmaster.comcast.net/smtp-error-codes.php#554
... while talking to mx2.comcast.net.:
<<< 554 imta11.emeryville.ca.mail.comcast.net comcast ww.xx.yy.zz Comcast requires that all mail servers must have
 a PTR record with a valid Reverse DNS entry. Currently your mail server does not fill that requirement. For more
 information, refer to: http://postmaster.comcast.net/smtp-error-codes.php#554
<recipient@comcast.net>... Deferred
Warning: message still undelivered after 4 hours
Will keep trying until message is 5 days old

If email headers will help I can post. If unedited headers are required, I'd prefer messaging individually rather than posting on forum. I'm paranoid.
 
Code: 
Comcast requires that all mail servers must have a PTR record with a valid Reverse DNS entry.
Click to expand...

There's your problem. Your forward and reverse DNS don't match, and comcast are doing a check to make sure they do. You will need to contact your ISP, and get them to add a reverse DNS entry (PTR record) for your IP address to match what you have in your forward DNS, i.e., if your mail server calls itself "mail.foo.com", then you need to get your ISP to:
  • add a PTR record for your IP to resolve to "mail.foo.com" under reverse lookup. You can't do this, it is done by the netblock owner.
  • allow relay through their mail server for you. This may be via SMTP auth, getting them to add your IP to relay-domains, etc.
This is a fairly common anti-spam measure - to prevent customers of the ISP setting themselves up a spam-server. Without intervention by the ISP to add/maintain a PTR record for them, their email is dropped.
 
Thanks.

I kind of thought that may be the real issue. Glad to get some confirmation.

Next time I call back, I hope to get a different rep. It might help. Though, the pessimist may say "be careful what you wish for". They also handle my phone, and have been bungling my long distance charges for the last 3 months. Calls that ought to have been $0.15 were billed at almost $4 per min. We may have turned the corner on that issue, and with some good fortune it won't take quite as long to knock out this DNS issue.
 
qsecofr said:
Thanks.

I kinda thought that may be the real issue. Glad to get some confirmation.

Next time I call back, I hope to get a different rep. It might help. Though, the pessimist may say "be careful what you wish for". They also handle my phone, and have been bungling my long distance charges for the last 3 months. Calls that ought to have been $0.15 were billed at almost $4 per min. We may have turned the corner on that issue, and with some good fortune it won't take quite as long to knock out this DNS issue.
Click to expand...

It very much helps if you can give them specifics to work with, so they can log a job with the appropriate help desk level.

I've worked on the other end of ISP support, and they have enough to do without troubleshooting problems in devices/equipment they didn't supply and don't support on the end users premises.

A specific request like "please add me a PTR record for IP address xxx.xxx.xxx.xxx to resolve to mail.foobar.com" is likely to get a much better response, assuming it is a service they offer. They should do if you're on a business plan though.
 
throAU said:
There's your problem. Your forward and reverse DNS don't match, and comcast are doing a check to make sure they do. You will need to contact your ISP, and get them to add a reverse DNS entry (PTR record) for your IP address to match what you have in your forward DNS.
Click to expand...

Hold it, that's not what's usually required, it's actually the other way around most of the time: your IP address connects to an SMTP server, which does a PTR lookup and gets a result. It then does an A record lookup of the result and requires the IP address to match the one that's connecting to them. SMTP servers do not care about a PTR record matching your A record, they care about an A record matching a PTR record. Subtle, but important difference.

An example, as seen from the SMTP server at the other side:

  • Receives connection from IP "123.123.123.123"
  • Performs a PTR record lookup for IP "123.123.123.123"
  • Two scenarios:
    1. Receives answer: NXDOMAIN (No PTR record) - REJECT or ACCEPT WITH WARNING
    2. Receives answer: IP "123.123.123.123" has PTR record "123.some.network.isp.com"
  • Performs an A record lookup for host "123.some.network.isp.com"
  • Three scenarios:
    1. Receives the answer: host "123.some.network.isp.com" has A record "123.123.123.123" - OK
    2. Receives the answer "123.some.network.isp.com" has A record "234.234.234.234" - REJECT or ACCEPT WITH WARNING
    3. Receives the answer "123.some.network.isp.com" has NXDOMAIN (no A record) - REJECT or ACCEPT WITH WARNING

It depends on the ISP how strict they are, some will reject any email if not all criteria check out, others will be more lenient. But this is basically how it works, and it doesn't matter whether your own domain record says that your own server is called "mail.user.com". The only thing is that your IP address has a PTR record, and that the PTR record points back to the IP address.

In this case, assuming that your ISP administers the reverse DNS records for your IP address (they usually do): ask them for a proper PTR record, with a matching A record that points back to the IP address, e.g.

123.123.123.123 -> PTR -> 123.some.network.isp.com -> A -> 123.123.123.123
 
Addition: if OP has decided to give his public IP address an A record under his own domain, like "mail.myowndomain.xyz", he can also try to persuade the ISP to give his IP address the PTR record "mail.myowndomain.xyz". Especially business-class static IP addresses can usually get a specific PTR record when the client asks for it. Consumer-class IP addresses, even the pricier static ones, usually have generic PTR pool records. But even these should have matching A records at the very least. If IP addresses have no PTR record at all it's usually a sign of a sloppy ISP.
 
Thanks. That's exactly what I did. This forum gave me the confidence to pursue it as a DNS error, rather than an MTA or MUA error as originally suggested by tech support. I was able to better explain the second time around, too. It's gratifying to know I was on the right track from the start.

As is the case with tech support oftentimes, the suggested course of action would've led to a dead end. When I explained it better, the second person to whom I spoke immediately understood what I wanted. But, he suggested I email the "hostmaster" group. Naturally the email bounced because my PTR record didn't match the A record. I used my day-job email account to get through. And they turned it around in a day! Fixed. Joy!
 
You must log in or register to reply here.
Back
Top