Solved

Exchange 2010 - Non Delivery Reports - Reporting-MTA isn't the same as Received-From-MTA

Posted on 2013-01-24
10
1,296 Views
Last Modified: 2013-01-31
Getting NDR's from a few recipients on email we send out.  A typical one would be:

p3pismtp01-004.prod.phx3.secureserver.net gave this error:
#5.1.0 Address rejected.
A problem occurred during the delivery of this message to this e-mail address. Try sending this message again. If the problem continues, please contact your helpdesk.
.
.
.
Diagnostic information for administrators:
Generating server: APAMAIL.APAOffice.org
aperson@somedomain.com
p3pismtp01-004.prod.phx3.secureserver.net #550 #5.1.0 Address rejected. ##
Original message headers:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apa1224.org;
      s=DKIM; t=1358985252; h=From:Subject:Date:Message-ID:To:MIME-Version
      :Content-Type; bh=bxLfClczBDqfj1WjiV8pyOb4F9MqPeIvR9J9jqPL6LU=; b=nju2opf
      OutTCxhd25iaIIcYExRwP5fqBjkVIiYR041qZiiKyLGay57ZrxHUerIDFHVPUK4yCEiHvLCOX
      DDNlUIqxa2rNMzV6JpZej8eXdC14fnsRp/ErLe8xE0n0W3T/MOH/+2WeQ/vL2BSmrGXw6c2CR
      HW+hz5LAditSEucOXg=;
Received: from APAMAIL.APAOffice.org ([fe80::3802:b8c6:bcc:c647]) by
 apamail.APAOffice.org ([fe80::3802:b8c6:bcc:c647%11]) with mapi id
 14.01.0438.000; Wed, 23 Jan 2013 18:54:12 -0500
.
.
.
.
.
Reporting-MTA: dns;APAMAIL.APAOffice.org
Received-From-MTA: dns;apa1224.org
Arrival-Date: Wed, 23 Jan 2013 23:54:12 +0000

Final-Recipient: rfc822;someone@adomain.com
Action: failed
Status: 5.0.0
Diagnostic-Code: smtp;550 #5.1.0 Address rejected.
Remote-MTA: dns;p3pismtp01-004.prod.phx3.secureserver.net
X-Display-Name: Some One

------------------------------------
Both the "Generating Server" and the "Reporting-MTA" show APAMAIL.APAOffice.org which is the INTERNAL local domain name of the Exchange 2010 server.  The "Received-From-MTA" is apa1224.org which is our external domain name and where we have all our DNS SPF and DKIM, MX, A records setup.   I thinking that some receiving email servers are doing rDNS and getting tripped up on the APAMAIL.APAOffice.org internal domain name.    How can I setup Exchange 2010 to only use the External domain name which would be mail.apa1224.org?

APAOffice.org is registered as an external domain as well when we needed to get an SSL certificate that would would work with APAOffice.org for some internal uses.   But I don't have any DNS pointing related to APAMail.APAOffice.org setup in it and would like to not have to duplicate the DKIM stuff there as well.   A, MX, SPF records could be setup in external DNS, but the DIM might be a little tricker.

I think that all of this could be resolved if outbound email from us showed mail.apa1224.org rather than APAMail.APAOffice.org.   The Send connector does have mail.apa1224.org listed as the FQDN, but we are running all Exchange 2010 roles on one server and I've seen indications that the FQDN is ignored in that case.

Anyone have a way to get APAMail.APAOffice.org converted to mail.apa1224.org in all our outbound email headers?
0
Comment
Question by:pwashburn1224
  • 5
  • 5
10 Comments
 
LVL 63

Expert Comment

by:Simon Butler (Sembee)
Comment Utility
Don't get hung up on the FQDN on the NDR. There are only three FQDN's that you need to worry about:
1. Send Connector
2. MX record
3. PTR

Ideally all three should be the same.

If you have set the Send Connector correctly, then problem is most likely elsewhere. What is in the headers doesn't matter, and you cannot really (and nor should you try to) change that behaviour.

Remote servers are only interested in the address the email is coming from, they don't care what has happened before that.

Simon.
0
 

Author Comment

by:pwashburn1224
Comment Utility
Looking at the MX record for apa1224.org:
Non-authoritative answer:
apa1224.org     MX preference = 10, mail exchanger = mail.mailroute.net

mail.mailroute.net is our spam filtering service on incoming email to us.

Looking at the PTR record:
PTR Record Found! 208.9.199.37 resolves to mail.apa1224.org

So they are not the same.    How do I handle the situation then where I want all incoming email to go to the MX record location, but all outbound email is coming from mail.apa1224.org?    It's just the MX record that is problem.
0
 
LVL 63

Expert Comment

by:Simon Butler (Sembee)
Comment Utility
If your MX record is pointing somewhere else, then that is fine.
You just need to ensure that the PTR has a matching A record that resolves to the correct place.

So host.example.com resolves to 123.123.123.123 and the PTR on 123.123.123.123 is host.example.com.

The other option is to send email OUT via the spam filtering service. A lot of them prefer that as they learn what email you are sending.

Simon.
0
 

Author Comment

by:pwashburn1224
Comment Utility
Looks like the SMTP banner that my Exchange server was putting out on Port 25 might have been the problem.  Was showing the server name in the local domain instead of mail.apa1224.org.  

Went into the Exchange Management Shell and used this command to change it:

Set-ReceiveConnector –identity “ServerConnectorname” –Banner “220 banner text”

Now it answers telnet mail.apa1224.org 25 appropriately with:
220 mail.apa1224.org Service ready

That should help.
0
 
LVL 63

Expert Comment

by:Simon Butler (Sembee)
Comment Utility
Sorry, no that doesn't help.
That is the RECEIVE Connector, and is only involved in receiving INBOUND email. Has nothing to do with OUTBOUND email. Basically what I wrote in my first posting.

All that changing the receive connector does is pass the dumb tests on things like MX Toolbox.

Simon.
0
How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

 

Author Comment

by:pwashburn1224
Comment Utility
Okay, then how does the SMTP banner check work when a mail server tries to check the validity of our email then?

The email goes out from our server as from  someone@apa1224.org.    The public IP address is included as the originating IP.  Doing NSLookup on that address resolves to mail.apa1224.org.   The PTR record matches as well.  So validating with reverse DNS should work and be happy.   SPF records and DKIM signing are available for further validation and appear to be working.    

If the receiving email server tries to do a SMTP Banner check, it is my understanding that it tries a port 25 connection to our sever.  Doing that before my changed resulted in the internal domain name of the server being shown, not the public name of mail.apa1224.org.     Changing the receive connector took care of that problem.  Having the remote server trying to verify our banner would involve it opening a connection to our server and seeing the banner that is displayed.   That would seem like a "Receive Connection" to our Exchange server wouldn't it?

Now, if the receiving email server tried to do its validation by looking at the MX records for us, then that's a completely different creature as the MX records point to our spam filtering provider, not us.   And that is where if you want to send us mail, that's where you should send it.   But outbound email from us come directly from our Exchange server.    Certainly that would be a common situation these days, so I would think any validation by a receiving email server from email we send out would handle that.  

We use Exchange distribution lists extensively and the NDR's I get do seem to occur more often on those rather than on email between individual users.   We do lots of outbound email to these distribution lists.   I've just run our Exchange public IP address against the RBL and we aren't listed so that isn't the issue.
0
 
LVL 63

Expert Comment

by:Simon Butler (Sembee)
Comment Utility
The SMTP banner check is a complete waste of time. I ignore the results of that because the remote testing sites are unable to see how your server is announcing itself when sending email unless an email is delivered to their server.

I am not aware of anyone doing a remote banner check independant of how the server announces itself.

The communication would be

Your server connects to remote server.
The remote server says "I am mail.remote.com"
Your server says I am "mail.example.com"
The remote server does a lookup on your PTR (IP address) and DNS and effectively says "Yes you are" and allows you to send your email.

Distribution lists will trip more filters simply because you are sending to multiple recipients. If youa re sending to lots of external recipients (so you have Contacts) you might want to consider outsourcing the delivery of that email to an external provider, which will be more relaible and allow you to get reports etc on the email delivery.

Simon.
0
 

Author Comment

by:pwashburn1224
Comment Utility
Yup, lots of Contacts.   What extra things does an external provider have that gets things through more reliably?
0
 
LVL 63

Accepted Solution

by:
Simon Butler (Sembee) earned 500 total points
Comment Utility
The external provider will have all of the reporting channels that the major email providers require setup.

This is the AOL one for example:
http://postmaster.aol.com/Postmaster.FeedbackLoop.php

Most of the providers will have these (Hotmail, Yahoo etc) and by having those you have a higher chance of email delivery. They can also give you reporting etc.

Simon.
0
 

Author Closing Comment

by:pwashburn1224
Comment Utility
Thanks Simon.   I'll look through the feedback loop process at the major providers.
0

Featured Post

6 Surprising Benefits of Threat Intelligence

All sorts of threat intelligence is available on the web. Intelligence you can learn from, and use to anticipate and prepare for future attacks.

Join & Write a Comment

Disabling the Directory Sync Service Account in Office 365 will stop directory synchronization from working.
Scam emails are a huge burden for many businesses. Spotting one is not always easy. Follow our tips to identify if an email you receive is a scam.
In this video we show how to create a Distribution Group in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.: First we need to log into the Exchange Admin Center. Navigate to the Recipients >>…
The basic steps you have just learned will be implemented in this video. The basic steps are shown to configure an Exchange DAG in a live working Exchange Server Environment and manage the same (Exchange Server 2010 Software is used in a Windows Ser…

728 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

12 Experts available now in Live!

Get 1:1 Help Now