Very weird email bounce problem

Haggisman · 10 Oct 2011 at 17:31

I've had a couple of calls today about some email problems from one of our customers, which have me completely stumped.

When they try to email someone in our domain, they get an NDR:

Error transferring to CLUSTER3OUT.EU.MESSAGELABS.COM ; SMTP Protocol Returned a Permanent Error 550 (#5.1.1)

Now, a 5.1.1 error means unresolved recipient, which should in theory be an obvious one, except for the following facts.

Other external customers can send emails to the same internal address with no problems. This would point to an issue with the customer's systems.

But, the same customer can still send emails to other external addresses (I got them to test sending to a gmail address which went through fine).

So this has got me puzzled!!

If anyone has any suggestions on things to check, I would be very grateful!

Thanks

tonym · 10 Oct 2011 at 18:46

Do they get the same error when they reply to an email sent from your firm?

It may be unrelated, but we had an issue on Friday at work where a number of emails that were sent to us vanished. When we checked the online portal, they were being bounced as spam. Symantec confirmed they had implemented an overly aggressive heuristic check and it had started bouncing emails that should have gotten through. They reset it back, but it could be worth you checking your online portal to see if you can spot the emails hitting their system

Haggisman · 10 Oct 2011 at 20:54

Yeah they do (this was how the problem was originally discovered).

I've checked in both Forefront and Exchange - nothing in either filter, I've also added both their domain, and the individual senders as trusted senders so they should bypass the spam filters completely, and they still get the same error.

edscdk · 10 Oct 2011 at 21:29

They get the ndr from your server or their server generates the ndr?

It sounds like you are saying they get an ndr back from your server which is very odd

If you can, telnet from their exchange server to your server and manually send a smtp message, helo, rcpt to, Mail from, see what the server says back to you and if it works.

Sound to me the delivery is being refused because it's getting tagged as spam by something, maybe their domain has been flagged as sending spam by one of the lists your spam filter uses..

Use an online checker to see if their domain has been tagged as a spammer,

Haggisman · 11 Oct 2011 at 09:41

They're not blacklisted according to network-tools.com.

I can't get onto their server to do anything unfortunately, but it looks like the NDR is from their server which is using messagelabs. I've just realised this is Symantec, so what tonym is saying may be something to do with it.

Just a bit strange that they can still email out to other domains and we can still receive from other domains!

NightShadow · 11 Oct 2011 at 14:05

Has the domain they are emailing expired? Could be chached MX records at some clients means it works for them but not for the ones who are up to date?

Haggisman · 11 Oct 2011 at 14:24

Nope, the domain is due to expire in December, but still current so far.

I managed to telnet into their exchange.

helo got no response

ehlo gives a response with a list of extensions

mail from: <sender address> gives a "sender ok" confirmation

rcpt to: <my address> gives error 550 5.7.1 unable to relay for <my address>

HungryHippos · 11 Oct 2011 at 16:26

We use MessageLabs for outbound SMTP at work (in fact on the same address, cluster3out.eu.messagelabs.com). It looks like the sender is trying to relay mail through this smart host from their exchange and then to you.

Assuming your MX records are fine and you are getting other emails in OK, then I would say the problem is with the senders end and MessageLabs.

We've had issues in the past where domains wound up in the ML system and this meant that anyone on our platform who tried to email them got back NDR's, don't recall if they were exactly the same NDR's though mind. Could be worth making sure that your domain isn't in the ML systems (as a customer of ML, the senders should be able to ask them that if you can't).

Also the sender should be able to track and trace in ML to see if the emails are even getting to ML, or are being dropped at the gateway? either way I suspect that this will need to be resolved with ML support if everything looks OK your end.

if you telnet onto cluster3.eu.messagelabs.com (Not! cluster3out) on port 25 you may be able to see if your domain is on that cluster, here is my transcript with some email names redacted so you can see the responses I got based on what I entered:

telnet cluster3.eu.messagelabs.com 25

helo localhost
250 server-11.tower-91.messagelabs.com
mail from: [email protected]
250 OK
rcpt to: [email protected]
250 OK
rcpt to: [email protected]
550-Invalid recipient <[email protected]>
550 (#5.1.1)
rcpt to: [email protected]
553-you are trying to use me [server-11.tower-91.messagelabs
553-.com] as a relay, but I have not been configured to let
553-you [78.147.186.122, host-78-147-186-122.as13285.net]
553-do this. Please visit www.messagelabs.com/support for
553-more details about this error message and instructions
553 to resolve this issue. (#5.7.1)

Look up the senders MX records and just confirm they are on cluster3 though. I got a 550 5.1.1. in the above telnet when entering a domain in the ML systems that was not a valid address.

smargh · 11 Oct 2011 at 19:56

I would look for the sender's mail server being buggy. I encountered one the other day which was only ever trying the backup MX and permanently ignoring the higher-priority main MX record. I think it did this because it only ever looked at the first MX record returned in DNS, ignoring subsequent returned records.

This caused bounces for only one sender to one destination domain, because the backup MX for the destination is only active when we flip over to DR. I've already recommended changing this practice.

That's an example of what I think it could be, anyway.

Alternatively, might there be a reverse DNS issue somewhere?

HungryHippos · 11 Oct 2011 at 20:43

Also, depending on the version of Exchange they are using etc (if indeed they are) they should be able to enabled Protocol Logging on the Send Connector for their outbound mail to verbose logging.

They can then check the protocol logs to check deeper into mail delivery issues to their smart host, though I suspect the erorrs will be much the same as the NDR you originally posted, or at least the portion we've seen.

Haggisman · 13 Oct 2011 at 11:10

So an update:

It appears we do have an account with Symantec - probably something my predecessor should have told me - but they can't see anything on their end, I forwarded them the NDR and apparently it's from our customer's mail server, so I guess that's a relief it's not our fault as I've been getting lots of grief about it

Just raised a call with customer's IT team who are going to look into it.

Thanks for all the suggestions - will update again as and when I hear anything