I’ve got a client who is complaining that some people are getting the email to him bounced back with #< #4.4.7 smtp;550 4.4.7 QUEUE.Expired; message expired> #SMTP#
After a little investigating I found that all of the bounced email he’s reporting are using Office 365 and that the Internet is full of these same reports. Most articles are blaming the email setup of the recipient. But I’m stump because I can find no log record of the bounced email and have nothing to go on.
Has anyone else ran across this or have any suggestions?
The bounce message alone doesn’t really say anything what went wrong during email delivery. It only says that the email bounced due to some “queue expiring”. You’d need to have your client tell you when precisely he tried to send email to you, so you can check your logs simultaneously, and also if they receive any errors in their email client right away. Without that info, it’s near impossible to say what’s wrong.
Yes of course, there are probably dozens of “possible reasons”. But without ANY further pointer, like at least knowing at what time a delivery attempt was made so you can check the logs, it’s going to be pure guesswork.
I’d say if your client can’t give you any more information than “something goes wrong, no idea what and when”, it’s not your problem. ANY user should be able to at least tell you WHEN they tried to send a mail, and what errors they received. If they can’t, it’s not your responsibility to guess for them.
I’ve tried to stress to my client, that it’s their clients email logs that would have more information, but that went nowhere, so I’m blindly looking an my end for possible causes.
One article suggested these items as a potential problem area.
The typical cause is due to an issue on the receiving end, and can be due to network issues, or exceeding recipient limit on the receiving system for example.
Possible limits set on the receiving server may include the following:
My client has given me some of the headers from the bounce mail, but nothing appears in the logs for the time stamp. It’s as if it never made it to my server.
I just wondered if I’m missing something and/or if anyone has gone through this before.
Received: from mail12-am1-R.bigfish.com (10.3.201.249) by
AM1EHSOBE020.bigfish.com (10.3.207.142) with Microsoft SMTP Server id
14.1.225.22; Tue, 19 Nov 2013 14:42:01 +0000
Received: from mail12-am1 (localhost [127.0.0.1]) by
mail12-am1-R.bigfish.com
No I haven’t had problems like that before really.
If you can reiterate what the exact problem is, we might do some testing. Like, what client did try to send/receive email from where to where, when exactly, and who got what bounce messages/errors. If you can reproduce / have access to the sending side, we could do delivery tests. That’s all I can offer really, without knowing further details.
Now that you see the bounce message – do you see any connection attempts in your email logs that correlate with that bounce message?
If not, that may indeed mean that the message isn’t getting to your server.
You may want to verify your DNS settings to make sure they appear correct… you could try going to a service such as intodns.com, and make sure it doesn’t discover any unusual issues.
I do see some references to other folks having that same issue, as you had mentioned… and in some of those cases, it sounds like the culprit were network issues. That’s a bit odd though, as normally mail servers will attempt to resend messages over a period of time. However, it may be worth verifying that your provider wasn’t experiencing network issues at those times.
That’s just it, I see no reference to these emails in the logs at all. I’m a frequent user of intodns and I see nothing wrong there. Plus this client gets a pretty high volume of email from other senders without issue.
Would the original send have logs of the exact reason for the expired queue?
The sending mail server would have the full logs and exact reason for the expired queue – it sounds like you may need to get them involved in order to sort out what’s going on.
ANY user should be able to at least tell you WHEN they tried to send a mail, and what errors they received. If they can’t, it’s not your responsibility to guess for them.