Does this mean reverse DNS was not setup?

  • Thread starter Thread starter denoxis
  • Start date Start date
D

denoxis

Hello,

I have a dedicated server for hosting purposes. It runs on Windows 2003
(but I don't think my question is Windows 2003-specific). Web apps from
this server sends notification emails to visitors. Some of the emails
bounce back because of (I guess) reverse DNS issue:

smtp;450 Client host rejected: cannot find your hostname,
[my.servers.ip.number]

Reporting-MTA: dns;MYSERVERNAME.MYISP.COM

As far I as understand it complains that my.servers.ip.number does not
resolve back to MYSERVERNAME.MYISP.COM even though other way around
works.

I tried the IP and it actually resolves to an ARPA address (which I
cannot specify as a FQDN in SMTP settings in IIS6 because it says it is
invalid.)

So, ARPA address resolves to my.servers.ip.number,
MYSERVERNAME.MYISP.COM resolves to my.servers.ip.number, but
my.servers.ip.number resolves back to ARPA address, NOT
MYSERVERNAME.MYISP.COM.

Does this mean reverse DNS was not setup?

TIA,
Deniz
 
denoxis said:
Hello,

I have a dedicated server for hosting purposes. It runs on Windows 2003
(but I don't think my question is Windows 2003-specific). Web apps from
this server sends notification emails to visitors. Some of the emails
bounce back because of (I guess) reverse DNS issue:

smtp;450 Client host rejected: cannot find your hostname,
[my.servers.ip.number]

Probably due to your not having the reverse PTR record OR
to your SMTP server not using that same name as the HELO
name of the SMTP server (software.)
Reporting-MTA: dns;MYSERVERNAME.MYISP.COM
As far I as understand it complains that my.servers.ip.number does not
resolve back to MYSERVERNAME.MYISP.COM even though other way around
works.

It must resolve to the name used in your SMTP server software
(for most people to trust you.)

That name doesn't have to be in any way related to your actual server
name (what you call it) nor to your email domain name.
I tried the IP and it actually resolves to an ARPA address (which I
cannot specify as a FQDN in SMTP settings in IIS6 because it says it is
invalid.)

What is it? What is your IP address? (We can check this for you...)
So, ARPA address resolves to my.servers.ip.number,
MYSERVERNAME.MYISP.COM resolves to my.servers.ip.number, but
my.servers.ip.number resolves back to ARPA address, NOT
MYSERVERNAME.MYISP.COM.

Does this mean reverse DNS was not setup?

Not if this command returns a name:

nslookup IP.Your.SMTP.Server
 
denoxis said:
I have a dedicated server for hosting purposes. It runs on Windows 2003
(but I don't think my question is Windows 2003-specific). Web apps from
this server sends notification emails to visitors. Some of the emails
bounce back because of (I guess) reverse DNS issue:
smtp;450 Client host rejected: cannot find your hostname,
[my.servers.ip.number]Probably due to your not having the reverse PTR record OR
to your SMTP server not using that same name as the HELO
name of the SMTP server (software.)

Thanks for the tip. I updated the email sender script so it updates the
HELO property to the FQDN that is specified in the
IIS6>SMTP>Delivery>Advanced. Otherwise it would use the computer name
with HELO by default.
(for most people to trust you.)

That name doesn't have to be in any way related to your actual server
name (what you call it) nor to your email domain name.

As a paranoid admin I am masking IP numbers and stuff. Some hacker out
there maybe looking for rookie admins like me who doesn't know what is
going on and gives info about the server (IP number, OS and other
software running on the server.) Thank you for your understanding. :)
nslookup IP.Your.SMTP.Server

Good, it does return a name. hostxx.xx.xx.xxx.maximumasp.com.

Thanks a lot Herb

Deniz
 
denoxis said:
I have a dedicated server for hosting purposes. It runs on Windows 2003
(but I don't think my question is Windows 2003-specific). Web apps from
this server sends notification emails to visitors. Some of the emails
bounce back because of (I guess) reverse DNS issue:
smtp;450 Client host rejected: cannot find your hostname,
[my.servers.ip.number]Probably due to your not having the reverse PTR
record OR
to your SMTP server not using that same name as the HELO
name of the SMTP server (software.)

Thanks for the tip. I updated the email sender script so it updates the
HELO property to the FQDN that is specified in the
IIS6>SMTP>Delivery>Advanced. Otherwise it would use the computer name
with HELO by default.

Good. Very typical default settings.
As a paranoid admin I am masking IP numbers and stuff. Some hacker out
there maybe looking for rookie admins like me who doesn't know what is
going on and gives info about the server (IP number, OS and other
software running on the server.) Thank you for your understanding. :)

They are looking for you (and others) anyway -- if you are depending on
"obscurity for security" you are going to be compromised.

If your IP is on the Internet then ANYWAY can request that already. You
are merely keeping me (or others) from helping you.
Good, it does return a name. hostxx.xx.xx.xxx.maximumasp.com.

That's the name that goes into SMTP HELO field.

Maybe you are putting the "." on the end and the (stupid) software doesn't
allow that (technically ANY DNS name should support a terminating DOT
but many don't -- even though it is NOT a "FQDN" until that dot is added.)
 
denoxis said:
I have a dedicated server for hosting purposes. It runs on Windows 2003
(but I don't think my question is Windows 2003-specific). Web apps from
this server sends notification emails to visitors. Some of the emails
bounce back because of (I guess) reverse DNS issue:
smtp;450 Client host rejected: cannot find your hostname,
[my.servers.ip.number]Probably due to your not having the reverse PTR record OR

to your SMTP server not using that same name as the HELO
name of the SMTP server (software.)


Thanks for the tip. I updated the email sender script so it updates the
HELO property to the FQDN that is specified in the
IIS6>SMTP>Delivery>Advanced. Otherwise it would use the computer name
with HELO by default.
Can you expand on "email sender script" updating HELO property? Are you
mailing out for more than one domain and changing the HELO accordingly?
What email server program are you using? If you've got mis-matched HELO
and/or rDNS you'll be blacklisted within a very short time as a spammer.
 
Can you expand on "email sender script" updating HELO property? Are you
mailing out for more than one domain and changing the HELO accordingly?
What email server program are you using? If you've got mis-matched HELO
and/or rDNS you'll be blacklisted within a very short time as a spammer.

Different ASP pages on different domains (web sites, I should say) use
the same Persist Email component to send notification (order
confirmation etc.).
All of them have the same HELO (DED516GBAU.maximumasp.com) which is
206.196.29.69
Until today that IP was resolving to an ARPA address. Now there is a
PTR record so the IP resolves back to DED516GBAU.maximumasp.com.
Even though I send emails from different web sites with different
"FROM" addresses, HOST is always set to DED516GBAU.maximumasp.com
along with HELO. Do you mean this cause a problem?

Deniz
 
denoxis said:
Different ASP pages on different domains (web sites, I should say) use
the same Persist Email component to send notification (order
confirmation etc.).
All of them have the same HELO (DED516GBAU.maximumasp.com) which is
206.196.29.69
Until today that IP was resolving to an ARPA address. Now there is a
PTR record so the IP resolves back to DED516GBAU.maximumasp.com.
Even though I send emails from different web sites with different
"FROM" addresses, HOST is always set to DED516GBAU.maximumasp.com
along with HELO. Do you mean this cause a problem?

Deniz
You should be aware that most email transmissions are 'tested' for dns
during the attempted delivery, and mail server programs routinely test
all domain names found in the email headers so you may want double-check
the dns for each domain name that will be passed in an email header.
Having the domain name that is declared in the HELO statement resolve
correctly now as you say is great as not not resolving is a common
reason for terminating the attempted email delivery. If you are not
experiencing problems with your email delivery then it appears you don't
have an issue. Have you considered SPF records? It's a simple text
record in the dns that declares an authorized list of email servers
permitted to handle email for the respective domain names, easily
included with your dns config. If you want to test your dns config with
respect to email transmission and other RFC guidelines, try
dnsstuff.com. Also, if you have a failover / backup email server then
the same config issues are going to apply.
 
Back
Top