Email Security.cloud

The organisation I work for has changed the way we deliver mail so we now use our exchange server to deliver through our message security service, instead of sending through our ISP's smarthost - a change that is working very well for most of our needs.

We send out newsletters to organisations who subscribe to them but since changing our mail delivery system, we are getting lots of NDR's (non delivery reports)

One common NDR with a 4.4.7 (The message in the queue has expired. The sending server tried to relay or deliver the message, but the action was not completed before the message expiration time occurred.) where the header includes the following:

Received: from mailx.bemtaxx.messagelabs.com ([193.109.xxx.xxx]) by
 exfe2.theirexample.org.uk over TLS secured channel with Microsoft
 SMTPSVC(6.0.3790.3959);	 Thu, 5 Jan 2012 17:08:15 +0000
Return-Path: <adminsname@ourexample.org.uk>
Received: from [193.xxx.xxx.xxx:15511] by server-x.bemta-xx.messagelabs.com id xx/E2-xx84-DF8D50F4; Thu, 05 Jan 2012 17:08:13 +0000
X-Env-Sender: adminsname@ourexample.org.uk
X-Msg-Ref: server-x.tower-xx.messagelabs.com!1xxxxx195!72xxxx3!1
X-Originating-IP: [207.xxx.xxx.xxx]
X-SpamReason: No, hits=0.0 required=7.0 tests=Mail larger than max spam 
  size

I need to know whether this translates as " your email has too high a spam count  for message labs to deliver it"

or " The message has an attachment that is too large" or  "we aren't going to deliver this as we think its spam as it was sent BCC instead of TO a recipient"

Many thanks for any insight

I'm assuming the NDRs you are referring too are coming from MessageLabs rather than from exchange?  In which case can you clarify if those headers are from the NDR itself or from the message you are trying to send?  It would be helpful to see a complete set of the headers, and the body of the NDR.

Based on the assumption above and the information to date I am almost certain that the problem is not related to the message you are sending, and it's not MessageLabs refusing to deliver it.  The problem is that MessageLabs is unable to deliver it because the receiving server is unreachable or is temp-failing the message.  So after a period of time during which it re-attempts delivery periodically it has finally given up and returned the message to you.  If MessageLabs didn't like the message you would generally get an immediate hard error, rather than any kind of timeout.  Suggest you check that the addresses which are bouncing are still valid.

It's possible that your previous smarthost silently dropped the message in this case; many ISPs don't send NDRs any more in a lot of circumstances, because so much of undeliverable mail is spam and so many senders of spam are spoofed.

HTH.  If this doesn't sound right, please post the additional info.

Thanks for your reply, its useful to have someone else confirm that ISPs don't send NDRs in a lot of circumstances.  I suspect that where servers were sending them they were being blocked by greylisting at our ISP and that we simply never got the majority of NDRs - its unlikely servers would be configured to 'resend' ndrs that have been dropped at the first try.

Here's another sample header - from what you say I should assume that there is 'no such user'.

________________________________________

From: MAILER-DAEMON@messagelabs.com [MAILER-DAEMON@messagelabs.com]

Sent: 13 January 2012 12:03

To: W W

Subject: failure notice

This is the mail delivery agent at messagelabs.com.

I was not able to deliver your message to the following addresses.

<mm@someorg.com>:

212.xxx.xxx.xxx does not like recipient.

Remote host said: 550 mm@someorg.com... No such user

--- Below this line is a copy of the message.

Return-Path: <ww@our.org.uk>

X-Env-Sender: ww@our.org.uk

X-Msg-Ref: server-7.tower-17.messagelabs.com!1326456209!34821885!1

X-Originating-IP: [7x.3x.4x.1x]

X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor:

  VHJ1c3RlZCBJUDogNzguMzMuNDguMTUgPT4gMjY1NzEx\n

X-StarScan-Version: 6.4.3; banners=-,-,-

X-VirusChecked: Checked

Received: (qmail 8492 invoked from network); 13 Jan 2012 12:03:29 -0000

Received: from smtp5.enta.net (HELO smtp5.exxx.net) (78.xx.xx.xx)

  by server-7.tower-17.messagelabs.com with SMTP; 13 Jan 2012 12:03:29 -0000

Received: from SUPSER1 (remote.our.org.uk [x1.3x.xx.xx])

        by smtp5.enta.net (Postfix) with ESMTP id 2D148146AD54

        formm@someorg.com; Fri, 13 Jan 2012 12:03:38 +0000 (GMT)

Reply-To: 

From: "required" 

To: "M

Message-ID: <>

Date: Fri, 13 Jan 2012 12:02:51 +0000

Subject: The  January

MIME-Version: 1.0

Content-Type: multipart/alternative;