Member Avatar for troverman

We have an important business contact in China whom we have communicated with by email for years. As of the past few weeks, we cannot send an email to this business successfully. We get the message delayed and then subsequent failed to deliver 4.4.7 message. We are running exchange 2003, and can email anyone else without issue, including other contacts in foreign countries. Also, we can email the important Chinese contact with a gmail account, just not through our corporate exchange.

My conclusion is that "we can email everyone else with no problem from Exchange" and "gmail gets through" = we are being blocked by a spam filter.

Is this a fair conclusion or is there somethign else I can try? Various members of our company have tried emailing the China contact and its all the same NDR. Because of the time difference, we only communicate by email; however in a gmail message we asked them to check their spam filter and they claim they did and its all set.

  • 3 Contributors
  • 4 Replies
  • 346 Views
  • 1 Day Discussion Span
  • Latest Post Latest Post by troverman

Dani AI

Generated

Short answer: a 4.4.7 NDR means the message "timed out" while your server was trying to complete the SMTP conversation — the sending server retried until the message expiration time and then gave up. Because Gmail can reach the recipient but your Exchange 2003 cannot, this strongly points to either a receiving-side filter/throttle or an IP reputation/blacklist issue rather than a general Internet outage. (learn.microsoft.com)

Concrete steps to add to the suggestions already posted by and :

  • Save the entire NDR (the SMTP diagnostic line, the exact Diagnostic-Code text, Message-ID and UTC timestamp) and note the public IP your Exchange uses to send outbound mail.
  • Enable message tracking and SMTP/protocol logging on the Exchange 2003 server and search those logs for the SMTP transaction to the recipient’s MX — that will show the full remote-MTA reply (the real clue). Exchange 2003 message-tracking and SMTP protocol logging are described in Microsoft guidance; message-tracking defaults to the Exchsrvr\servername.log location and SMTP logs are under the system LogFiles path. (ftp.zx.net.nz)

Reputation and authentication checks:

  • Run an IP/domain blocklist lookup (start with Spamhaus) and follow the listed removal steps if you find a listing. If you are not listed, give the recipient’s mail admin the full NDR plus your sending IP and timestamps and ask them to check their inbound filter logs and whitelist your IP temporarily. (check.spamhaus.org)
  • Verify reverse DNS (PTR) and SPF are correct for the sending IP. Note: on-prem Exchange 2003 does not provide built-in DKIM signing, so for modern authentication either route outbound mail through a trusted smarthost/relay that signs mail or add a DKIM-capable gateway/agent. (learn.microsoft.com)

Operational mitigations while you investigate: throttle or pause bulk sends, clean the newsletter list to reduce bounces, and keep the exact NDR lines and log snippets when working with the recipient’s mail team — those items (full SMTP reply, sending IP, Message-ID, UTC time) are what they will need to diagnose or whitelist.

Recommended Answers

All 4 Replies

Member Avatar for hericles

I think you might have ended up on a email blacklist. Trying to locate which black list you are now on can be difficult. It will effect everyone using the same domain part of the email address (everything after the @) so other people in the company will have the same problem.
You can either find the blacklist and try to get taken off it (there are online tools for that) or wait for the trust level of email address to rise again. That may take some time.
Has your company engaged in any email campaigns later (even legit ones)? Thats how I got pegged a couple of months back.

Member Avatar for troverman

As for campaigns, we send out of monthly e-newsletter which goes to quite a few recipients. Nothing done commercially, though. I'll try to check out blacklists.

Member Avatar for rch1231

Hello,

Hericles is probably correct but if your mail is getting through to everyone else you send to, then it could be that they tightened their email servers security, or your mail server does not have a good route to theirs. He is also right that you should verify that there is nothing blocking your server like blacklists or email relay. I would do two things. First go a site like MXtoolbox:

http://mxtoolbox.com/diagnostic.aspx

and enter your domain to see if there are any issues with your server. It will check all blacklists and run some tests against your mail server then give you a report and make suggestions on how to correct issues it finds.

It may be that your email server can't get tohas them blocked or is unreachable for some reason. Run these commands from your exchange server as an administrator.

Find out what their MX (mail Exchange) records are set to:

dig -t MX <their domain name>

Like mine comes back with the following:

[root@lptp2 ~]# dig -t MX txlinux.com

; <<>> DiG 9.9.4-P2-RedHat-9.9.4-12.P2.fc20 <<>> -t MX txlinux.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34892
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;txlinux.com.                   IN    MX
ANSWER SECTION:                                                                                                              
txlinux.com.     3600    IN      MX    20    txlinux.com.

txlinux.com.     3600    IN      MX    10    txlinux.com.

Which says my mail server is txlinux.com.

next find out what the domain name resolves for you exchange server using nslookup:

nslookup <domainname>

Finally see if you can get to it either by name or IP address using ping and trace route (or even better WINMTR). WinMTR will show you the riute to their server and any laency or packet loss between the servers.

Hope this helps.

Member Avatar for troverman

Thanks rch - I'll try this in the morning tomorrow. It is strictly sending emails to this one customer; they can still send emails to us when they initiate the message.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.