Jump to content


 


Register a free account to unlock additional features at BleepingComputer.com
Welcome to BleepingComputer, a free community where people like yourself come together to discuss and learn how to use their computers. Using the site is easy and fun. As a guest, you can browse and view the various discussions in the forums, but can not create a new topic or reply to an existing one unless you are logged in. Other benefits of registering an account are subscribing to topics and forums, creating a blog, and having no ads shown anywhere on the site.


Click here to Register a free account now! or read our Welcome Guide to learn how to use this site.

Photo

undeliverable email


  • Please log in to reply
14 replies to this topic

#1 BitMonk

BitMonk

  • Members
  • 30 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:Midwest, USA
  • Local time:12:09 AM

Posted 01 August 2014 - 03:05 PM

Been out on the net trying to learn how to decypher email error messages but really haven't found a good tutorial. Perhaps different email programs generate slightly different mesages? AND, I'm not so much expecting someone to solve this problem for me as I would like some guidence on the error message.
Here's just the first part. (Obviously I went thru and changed anything that referred to actual names, servers, IP addresses.)

Generating server: emailprotect.myorg.com
intendedrecipient@ABCU.edu
#< #4.0.0 X-Spam-&-Virus-Firewall; host hormel.ABCU.edu[recipient email server IP] said: 451 4.1.8 FAILED [xxx.xxx.xxx.xxx,PTR] see http://www.ABCU.edu/ir/emailreject.php?ip=xxx.xxx.xxx.xxx&code=DNS (in reply to RCPT TO command)> #SMTP#

I believe this never left our email server on premises as that is the generating server.
The code #4.0.0.0 means Other or undefined network or routing status and the
4.1.8 FAILED means no answer from host
The odd thing is it takes over 24 hours to get an undeliverable email notice though I've read that perhaps the server will try to resend it a certain number of times so perhaps the reason it takes so long?
tracert to the real recipient email server ip resolves to the correct name over 13 hops so that seems correct.
At this time I do not have administrative rights to the email server nor do I have access to the 3d party email protection software. (Ok, it's a well known company but didn't want to violate some policy somewhere.)
Am I on the right track? My supervisior is busier than a one armed paper hanger so it may be a while berfore I get to them.

Edited by BitMonk, 01 August 2014 - 03:10 PM.


BC AdBot (Login to Remove)

 


#2 sflatechguy

sflatechguy

  • BC Advisor
  • 2,226 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:01:09 AM

Posted 02 August 2014 - 06:13 PM

400 error messages are non-fatal -- usually, your server will try to send it again after a certain period. Normally, a 451 4.1.8 non-delivery receipt message means the domain of the server you are trying to send to can't be resolved -- there is a DNS issue somewhere that is not resolving their email server address, their mailserver is down, or you mistyped the email address.

 

Your server is showing up as the one generating the message because it was informed the email couldn't be delivered.

 

Go to https://www.whatsmydns.net/, type in the ABCU.edu domain name (I realize that's a placeholder, so type in the real one), in the dropdown menu, select MX record, and click Search. If it fails to resolve, the issue is on their end.

 

If you have your own DNS server on premise, make sure the static records are entered correctly, and that any external DNS servers you are using for name resolution are up and running.


Edited by sflatechguy, 02 August 2014 - 06:17 PM.


#3 BitMonk

BitMonk
  • Topic Starter

  • Members
  • 30 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:Midwest, USA
  • Local time:12:09 AM

Posted 02 August 2014 - 10:10 PM


Thanks so much for the reply! The original message is on my PC at work so I'll do as you instructed Monday. I'll post what I finally figure out.

Edited by BitMonk, 02 August 2014 - 10:11 PM.


#4 BitMonk

BitMonk
  • Topic Starter

  • Members
  • 30 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:Midwest, USA
  • Local time:12:09 AM

Posted 05 August 2014 - 09:29 AM

Ok, the link you gave is interesting. Being new in the IT field I appreciate proven "tools" like that.
Yesterday I got some results that that I didn't understand, had forgotten to use dropdown for MX records at first, etc, but I think it looked like OUR MX records weren't propagated. Today, both our domain's and theirs shows up all over the world map. Might try and resend.
Point is, THANKS for taking time and helping out. I'm further down the road.

#5 sflatechguy

sflatechguy

  • BC Advisor
  • 2,226 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:01:09 AM

Posted 05 August 2014 - 03:08 PM

That would also explain it. If you entered your MX records recently, it can take anywhere from a just few minutes to up to 72 hours for it to propagate, depending on who your DNS registrar is.



#6 x64

x64

  • Members
  • 352 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:London UK
  • Local time:06:09 AM

Posted 05 August 2014 - 03:58 PM

I presume that the error is in response to trying to send an email from your server to a third party.

 

In this case it appears that the third party is giving you a generic failure code, and a link to their website where they explain the kind of things that may cause their servers to reject email.

 

I'll have a punt at a diagnosis, but the error message in the OP is so redacted it is difficult  to draw conclusions from it, so I could be way off mark... It could be that the DNS around your server is not optimal.

 

A forward DNS lookup for your server should match the reverse lookup for that server,. Additionally the name returned in the SMTP banner should match that same name.

 

So let's say that your mail server is known to the outside world as "mail.company.com" and has IP address 111.121.131.141.

Then you should have a A record in the mycompany.com domain for "mail", resolving to 111.121.131.141. additionally the reverse lookup fit that IP address should resolve to that same host name.

 

So try

NSLOOKUP mail.mycompany.com.

you should get 111.121.131.141 back

Then try

NSLOOKUP -type=ptr  141.131.121.111.in-addr.arpa.

NOTE the parts of the IP address are deliberately reversed in that command.

If that does not resolve to "mail.company.com", you have a misconfiguration that will cause some systems to refuse email form your system. Your ISP probably controls the reverse lookup DNS zones for the IP addresses they lease to customers - so if you need to modify that- you will need to contact their support.

 

Thirdly - check the smtp banner name. From outside your network, telnet to port 25 on mail.mycompany.com

telnet mail.mycompany.com. 25

will do that. Check the banner that is returned. An example could be

220 mail.mycompany.com Microsoft ESMTP MAIL Service ready at Tue, 5 Aug 2014 21:51:13 +0100

 

The name after the 220 code should match the forward and reverse lookups. If it does not, refer to the documentation for your email server to make it match..

 

x64


Edited by x64, 05 August 2014 - 03:59 PM.


#7 BitMonk

BitMonk
  • Topic Starter

  • Members
  • 30 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:Midwest, USA
  • Local time:12:09 AM

Posted 07 August 2014 - 09:46 AM

Thanks X64 for the added information, I just now saw you posted so wanted to acknowledge that. I'll take time to fully digest what you said but the link in the error message I looked at yesterday did mention the reverse lookup on our end could be a problem. I know we have a DNS server/service for our Domain Controller.  Whether the reverse look up has been configured there I do not know nor do I know if that matters if our ISP also needs to configure theirs.

 

(Perhaps you all are thinking "this guy does IT and can't get into the servers or easily contact his supervisor..."  Let's just say it's a work in progress.)

 

I am seeing some odd situations which seem to point to some type of DNS issues. Here I replied to another poster

http://www.bleepingcomputer.com/forums/t/542626/certain-website-not-opening-on-certain-computers/

 

I'm an Associates Degree guy, not an engineer so it takes me a while to bring all the pieces together but I do find the network part (switching, routing, protocols) of all this VERY interesting. Anyway in the interest of brevity I'll conclude and go some more digging.

 

As always, your humble BitMonk.


Edited by BitMonk, 07 August 2014 - 09:47 AM.


#8 sflatechguy

sflatechguy

  • BC Advisor
  • 2,226 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:01:09 AM

Posted 07 August 2014 - 10:41 AM

If you just recently added the DNS zone records for your domain -- and it sounds like you have -- it's quite possible the other server tried to look up your MX records and couldn't find them. Again, depending on who your DNS registrar is, and how often your on-premise DNS files are shared with it, it can take up to 72 hours for those records to fully propagate.



#9 BitMonk

BitMonk
  • Topic Starter

  • Members
  • 30 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:Midwest, USA
  • Local time:12:09 AM

Posted 07 August 2014 - 03:08 PM

I'm not aware of any changes to our DNS here but we do have a contract person who may have done something.
I asked the staff member to try and resend the email yesterday, we'll see if that went thru this time. If not I WILL escalate this thru our contract guy. He will know contacts or he can remote in.
We don't have any internet facing services. Our website is hosted and I can't even get to my email from home. I think I am making too much out of our DNS being associated with our Domain. We covered that in our server class as well as the general concept of how it operates out on the internet. DNS is DNS.
Again thanks for the reply

#10 sflatechguy

sflatechguy

  • BC Advisor
  • 2,226 posts
  • OFFLINE
  •  
  • Gender:Male
  • Local time:01:09 AM

Posted 07 August 2014 - 03:36 PM

Hmm. That does sound like a DNS issue on your end. Is the company handling the web hosting handling the rest of your DNS records? Make sure the TTL values for your DNS zone records aren't set to something ridiculously long, like 24 hours -- set them to 15 minutes or less. Sounds like your DNS zone files may not be propagating in a timely fashion, or your nameserver is hard to reach for some reason.


Edited by sflatechguy, 07 August 2014 - 03:37 PM.


#11 x64

x64

  • Members
  • 352 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:London UK
  • Local time:06:09 AM

Posted 07 August 2014 - 03:37 PM

... I know we have a DNS server/service for our Domain Controller.  Whether the reverse look up has been configured there I do not know nor do I know if that matters if our ISP also needs to configure theirs.

....

To clarify - all of the DNS entries that I am talking about are almost certainly EXTERNAL to your network. The DNS service on your domain controller is almost certainly internal DNS only.

 

So the forward lookup (mail.company.com in my example above) will be in your companies domain as hosted by your ISP or whoever else you pay for the external domain name.

 

The reverse lookup ( 141.131.121.111.in-addr.arpa. in my example) will be with the ISP who provides your connectivity, as it is directly related to your mail servers IP address on the internet (The IP address will be from a block of IP addresses assigned to the ISP for allocation to their customers, so the ISP needs to control the reverse DNS).

 

x64



#12 BitMonk

BitMonk
  • Topic Starter

  • Members
  • 30 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:Midwest, USA
  • Local time:12:09 AM

Posted 08 August 2014 - 01:51 PM

I presume that the error is in response to trying to send an email from your server to a third party.

 

In this case it appears that the third party is giving you a generic failure code, and a link to their website where they explain the kind of things that may cause their servers to reject email.

I completely missed answering that, but yes, sending from our server to a third party, and I finally realized there was something on that page about what you have been saying about the reverse PTR.

Also, I think I have been too cryptic with my information but only 30 days on the job....
We are a small hospital/healthcare facility running a single domain and using Exchange on premise. Our website is hosted somewhere out of state which has very little user interaction short of "contact us".
I did what x64 said to do (at home, off of this network) with nslookup, understanding I would (and did) get a public address, not our internal private address however the reverse .in-addr.arpa. did not resolve. (I did it several time to make certain there were no typos.)
I was running out of time at home last and didn't get to do the telnet thing but I will.
This has been such a good exsercise for me to refresh and deepen my understanding.
BIG PICTURE. I've got an email to our contract guy about this as believe you two are correct about it being with our IPS. Either he or my boss lady will know whom to contact.

MANY THANKS for your interest in my situation, I am keeping track of all the tools and processes you showed me. I feel I have taken plenty of your time.
I tend to make things too complicated. I have had some rather amusingly simple fixes to PC or printer problems already.

Your humble BitMonk


Edited by BitMonk, 08 August 2014 - 01:53 PM.


#13 x64

x64

  • Members
  • 352 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:London UK
  • Local time:06:09 AM

Posted 08 August 2014 - 03:46 PM

Pleased to be of service!.

 

Just to go a little deeper down the rabbit hole... (and to help explain something - namely why it is your connectivity ISP is the one to contact to set up the reverse DNS)

 

reconsider the command to check the reverse lookup

NSLOOKUP -type=ptr  141.131.121.111.in-addr.arpa.

and recall I said that the parts of the IP address appear in reverse order (i.e. we are checking the reverse lookup for 111.121.131.141 in that command...

 

Try

NSLOOKUP -type=ns 131.121.111.in-addr.arpa.

(obviously replacing the parts of the IP address with your real IP address (again in reverse order - the three most significant elements)

This should resolve back to some name servers run by your employers connectivity ISP..... Why?...

 

The IP registry for your region (there are five globally) will have allocated some blocks of IP addresses to your ISP (let's say one of those blocks includes the 111.121.131.xxx addresses. The ISP will arrange to have those IP addresses routed towards them, and will also be delegated the rights to manage reverse DNS for those addresses. You see that

131.121.111.in-addr.arpa.

is just a domain name in the "in-addr.arpa." domain. No different really  subdomain.somecompany.com.

 

Also note at as we add more elements to the address

111.in-addr.arpa.

121.111.in-addr.arpa.

131.121.111.in-addr.arpa.

we are getting more specific in the IP addresses and the owner of them.

This scheme has the limitation as you cannot subdivide ownership of reverse dns to fewer than 256 addresses. Often an ISP will have assigned the IP addresses in the block of 256 addresses split between several customers. Hence they cannot delegate management of reverse dns further. Hence they have to run the reverse DNS themselves and set the individual entries in that 111.121.131 zone to the values that the customers to whom they have leased the individual addresses request.

 

x64

 

(I have made an assumption - that your IP address was delegated to your ISP as a number of 256 address blocks rather than a single allocation of 65536 addresses. My assumption is probably safe, unless your ISP is very large..in that case NSLOOKUP -type=ns 131.121.111.in-addr.arpa. might not work, but  NSLOOKUP -type=ns 121.111.in-addr.arpa. would )

 



#14 BitMonk

BitMonk
  • Topic Starter

  • Members
  • 30 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:Midwest, USA
  • Local time:12:09 AM

Posted 10 August 2014 - 10:48 PM

Dang, been busy all weekend and I finally got a chance to sit down and do the above. "121.111.in-addr.arpa." and "131.121.111.in-addr.arpa." did show those routed to our ISP, the primary name server being a subdomain as you said. I see what you are talking about.

BTW, both of the -type=ns produced the ISP again. "NSLOOKUP -type=ns 111.in-addr.arpa." produced 8 subdomains for arin.net. I guess those are the big boys.
I need to get good with nslookup.

Thanks for taking the extra time. All the way from across the pond, too!

#15 x64

x64

  • Members
  • 352 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:London UK
  • Local time:06:09 AM

Posted 11 August 2014 - 01:08 AM

Indeed, ARIN is one of the five the regional IP registries - the "American Registry for Internet numbers". They allocate IP addresses to all of the various ISPs in that area.

 

x64






2 user(s) are reading this topic

0 members, 2 guests, 0 anonymous users