• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 482
  • Last Modified:

Help me understand (and fix) why Sender ID filtering blocks some emails and not others.

We manage multiple Exchange '10 and '13 servers for various clients.  These are all small (50 users or less) sites, each with a single Exchange server.  A problem that's been cropping up recently is that some servers have problems emailing other servers, and the NDRs indicate:

mail.domain.com #550 5.7.1 Sender ID (PRA) Not Permitted ##

It's clearly Sender ID filtering that's blocking the emails.  Further down in the NDR, I see the following:

Received: from localservername.localdomain.local ([192.168.1.1]) by
 localservername.localdomain.local ([192.168.1.1]) with mapi id
 14.02.0387.000; Wed, 13 Aug 2014 08:05:49 -0500

It appears that the sending server is reporting its local FQDN and IP address, rather than its internet FQDN and IP address.  

Each of the clients have the following internet domain control panel DNS settings:
MX - mail.domain.com
SPF - v=spf1 a mx -all

The especially odd thing is that this is sporadic.  For example, if user@domain1.com sends 5 emails to user@domain2.com, one or two of them might be NDRed and the rest might go through.   The emails that go through indicate:

Received: from mail.domain.com ([public IP address]) by
 mail.domain.com ([public IP address]) with mapi id
 14.02.0387.000; Wed, 13 Aug 2014 08:05:49 -0500

Apparently, the sending mail server SOMETIMES reports its internet FQDN and IP address, and other times it reports its internal FQDN and IP address.  

(What is additionally frustrating is that Sender ID filtering isn't catching obvious fakes--for example, user1@domain.com might receive spam from user1@domain.com, when the email tags indicate that the email came from a server IP address that's clearly not associated with that domain in the SPF record.  That, however is a side issue--legitimate emails being blocked as spam is much worse than a few extra spam making it past the filter.)

This problem seems to have arisen over the past few weeks or so, but searching Google for "mail.domain.com #550 5.7.1 Sender ID (PRA) Not Permitted ##" and limiting it to the last year hasn't turned up anything helpful.  

My primary question is either why Exchange is sometimes reporting its internal FQDN and IP address, or why Sender ID sometimes NDRs emails from a particular server, but other times will allow them with no problems?  And, more importantly, how to fix that?

Secondary is why does Sender ID sometimes allow emails that should blatantly fail?
0
SINC_dmack
Asked:
SINC_dmack
  • 7
  • 3
  • 2
2 Solutions
 
LeeDerbyshireCommented:
Not sure I have an answer. It depends on whether when you say

"Apparently, the sending mail server SOMETIMES reports its internet FQDN and IP address, and other times it reports its internal FQDN and IP address.  "

you are talking about more than one server doing this, or all of them. The reason I ask is that the name a server responds with is configured at the send connector. There is an input field that asks "Specify the FQDN this connector will provide in response to HELO or EHLO". If it's blank, the server will just respond with it's internal DNS name.

If you are saying that some servers respond with 'localservername.localdomain.local', while others respond with 'mail.domain.com', then you need to check the configuration of all the send connectors.

If you are saying that any single server is randomly responding with either value, then I've no idea what's happening.
0
 
Svet PaperovIT ManagerCommented:
A missing PRT record for the sending host could cause this kind of NDR errors.

PRT DNS records a generally handled by the last ISP because he owns the public IP addresses.

However, if you are using a smart host for filtering the outgoing mail, like Microsoft Exchange Online Protection for example, configuring such PRT it not necessary  – it’s handled by the last sending host.
0
 
SINC_dmackAuthor Commented:
Both of the servers that were occasionally being blocked by Sender ID filtering had multiple send connectors, and in both cases, at least one send connector had the server's local FQDN as the "respond to EHLO".  I've since removed all of the send connectors except one, and ensured that the sole send connector had the internet FQDN instead of the local FQDN.  I'm going to give it a few days of testing to confirm that this has resolved the issue, but it seems reasonably likely that the send connector misconfiguration was the issue.  Thanks for the suggestion, Lee.
0
Free recovery tool for Microsoft Active Directory

Veeam Explorer for Microsoft Active Directory provides fast and reliable object-level recovery for Active Directory from a single-pass, agentless backup or storage snapshot — without the need to restore an entire virtual machine or use third-party tools.

 
SINC_dmackAuthor Commented:
Svet, could you elaborate about your comments regarding PTR records?  (I assume you meant PTR, not PRT.)  As far as I know, PTR records are primarily used for reverse DNS, and in this case the ISP for each server has a reverse DNS entry that resolves to mail.domain.com.
0
 
SINC_dmackAuthor Commented:
Apparently removing the extra send connectors didn't help--one of the clients just received the following NDR:

Generating server: client'slocalserver.domain.local
user@otherdomain.com
mail.otherdomain.com #550 5.7.1 Sender ID (PRA) Not Permitted ##

Received: from client'slocalserver.domain.local ([192.168.111.254]) by
 client'slocalserver.domain.local ([192.168.111.254]) with mapi id
 14.02.0387.000; Thu, 21 Aug 2014 10:52:59 -0500

The sending server is still reporting its local name and its local IP address when attempting to send to the recipient.
0
 
SINC_dmackAuthor Commented:
I just had it happen again--this time the email was from a totally different server to a totally different server.  Same error syntax as my post above this one.
0
 
SINC_dmackAuthor Commented:
I think I may have fixed it.  On the server that NDRed today (my second post up from this one), last night I had gone to:
Exchange Management Console -> Organization Configuration -> Hub Transport -> Send Connectors -> Properties of Send Connector ->Network tab, and I had unchecked "use the external DNS lookup settings on the transport server".  
Apparently that setting affects the send AND receive connectors, because with it unchecked, I started getting the NDRs as listed above, with the receiving mail server reporting that the sending mail server was server.localdomain.local, not mail.domain.com.  

I rechecked that box on the server that NDRed today, and now emails are delivered as expected, and the mail tag reports that the emails were sent from mail.domain.com via the public IP address.  I've logged into the other servers that were giving the error and they all had that box unchecked, so I've checked it on them as well.  I'll follow up and confirm if the problem is truly fixed.

I am unclear as to why this setting, on a send connector for the sending server, affects how the receiving server perceives the incoming emails.  Perhaps when the sending server sends and looks to external DNS, it resolves as the external host name and IP address and appends those to the outgoing email.  It seems counter-intuitive, but my empirical results suggest that's what's happening.
0
 
LeeDerbyshireCommented:
I have no idea at all why that checkbox should have an effect on the receive connector. The sending server should just announce it's name regardless.

You might do some telnet tests. That way you can be 100% sure what name you supply with the HELO, and you can see if it gets accepted, or changed and rejected.
0
 
Svet PaperovIT ManagerCommented:
That means you have a misconfigured local DNS server. Configuring a split DNS (as in the case where the internal name space is different from the external one, like .local vs .com) could be tricky. Using External DNS Lookups helps in such cases. However, this should not have effect on the Receive connector.
0
 
SINC_dmackAuthor Commented:
Hi Lee, when I run an SMTP test using mxtoolbox.com, the server replies with the following header:
220 mail.domain.com Microsoft ESMTP MAIL Service ready at Thu, 28 Aug 2014 16:15:22 -0500
I've run this test a half dozen times over the last few weeks and it's returned the same result every time.  Is that sufficient to prove that the server is reporting its name properly, or did you have some other tests in mind?

Hi Svet, yes, we have split DNS configured.  Do you have any recommendation as to what you think is misconfigured?  The DNS configuration on the two problematic servers is the same as we've used at many other clients which are not experiencing this issue--a .local for internal and a .com for external.
0
 
LeeDerbyshireCommented:
I think that's a sufficient test. I can't imagine that it would respond with a variety of names. What I was specifically referring to was a telnet test, i.e. from the command prompt

telnet yourserver.domain.com 25

and see how it replies. You'd need to install the telnet component these days - i don't think it's there on a standard windows install. But the results should be the same.
0
 
SINC_dmackAuthor Commented:
Unchecking "use the external DNS lookup settings on the transport server" appears to have fixed the problem.  Lee's suggestions about testing the mail server's response were things I'd already tried but may be helpful to other users who are having similar problems.
0

Featured Post

Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

  • 7
  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now