Messaging Gateway

 View Only
  • 1.  Messagelabs delaying email

    Posted Sep 02, 2013 04:49 AM

    Hi Everyone,

    New to the forum and hope to be using the forum on a frequent basis. I have a quick question. A hosted client of ours has had a few emails recently that appear to have been stuck with messagelabs for over an hour. I have checked the internet headers on the mail and it leaves the senders domain, enters messagelabs domain and then moves into the recipients domain over an hour later. I didnt want to paste in the entire internet header details for security puropses... but below is the messagelabs part...

    Please could someone advise as to why this is happening. It seems to be from one particular sender.

     

    Received: from mail6.bemta3.messagelabs.com (mail6.bemta3.messagelabs.com

    [195.245.230.39])            (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))

                   (Client CN "mail6.bemta3.messagelabs.com", Issuer "VeriSign Class 3

    International Server CA - G3" (verified OK))         by *******.*******.co.uk

    (Postfix) with ESMTPS id B05D413685C  for <***@***.co.uk>; Fri, 30 Aug

    2013 17:16:06 +0100 (BST)

     

    Received: from [85.158.137.3:65064] by server-15.bemta-3.messagelabs.com id

    AC/3C-21409-645C0225; Fri, 30 Aug 2013 16:16:06 +0000

     

    Received: (qmail 4449 invoked from network); 30 Aug 2013 16:16:04 -0000

     

    Received: from mail1.bemta14.messagelabs.com (HELO

    mail1.bemta14.messagelabs.com) (193.109.254.105)  by

    server-2.tower-38.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30

    Aug 2013 16:16:04 -0000

     

    Received: from [193.109.254.67:61471] by server-1.bemta-14.messagelabs.com id

    EC/4C-22234-F9AB0225; Fri, 30 Aug 2013 15:30:39 +0000



  • 2.  RE: Messagelabs delaying email

    Broadcom Employee
    Posted Sep 03, 2013 08:05 AM

    Hi,

    It looks to me like this is just a difference in representation of time stamps.  MessageLabs / Symantec.cloud always uses UTC in time stamps, so the header they added was GMT+0:

    Received: from [85.158.137.3:65064] by server-15.bemta-3.messagelabs.com id AC/3C-21409-645C0225; Fri, 30 Aug 2013 16:16:06 +0000

    This header is added by MessageLabs.

     

    Your client's mail server is writing time stamps in local time, which here is BST (GMT + 1):

    Received: from mail6.bemta3.messagelabs.com (mail6.bemta3.messagelabs.com [195.245.230.39])
                (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
                (Client CN "mail6.bemta3.messagelabs.com", Issuer "VeriSign Class 3 International Server CA - G3" (verified OK))
             by *******.*******.co.uk (Postfix) with ESMTPS id B05D413685C  for <***@***.co.uk>; Fri, 30 Aug
    2013 17:16:06 +0100 (BST)

    I'm not sure where all the other headers are coming from that you have shown, but I don't think they are all from the same message are they?  If they are, then there is a at least one more MessageLabs header missing, which would help to make sense of the others.

     



  • 3.  RE: Messagelabs delaying email

    Posted Sep 04, 2013 06:26 AM

    Hello Bluebook,

    Many thanks for coming back to me. I am aware of the different timestamps relating to timezones.

    The headers are from the same message but I may have caused confusion as I have removed the header from when it left the senders domain and when it entered the recipients domain (for security purposes) I was hoping to just highlight the details when the message was sat with messagelabs...

    Even so, it appears to have hit messagelabs at 1530 +0000 and left message labs around 45 minutes later at 1716 +0100 

    My apologies, it was not with messagelabs for over an hour as initially stated but still, is anyone able to confirm why it took so long? Thanks.



  • 4.  RE: Messagelabs delaying email

    Broadcom Employee
    Posted Sep 06, 2013 07:13 PM

    Hi there,

    Without being able to see the first header when the message left the sender's domain I can't be 100% certain, but I'm almost sure that this particular message originated with another MessageLabs customer, who is configured on different infrastructure to your client.  This would also be consistent with your observation that the problem only affected one particular sender.  

    The first header you see (the one at 15:30) is the message being queued for delivery out of the sender's MessageLabs service.  There would be one before this showing it being received by MessageLbas from the sender.  The next header (Received: from mail1.bemta14.messagelabs.com) is the message arriving at your client's MessageLabs service, and you can see that from there it gets forwarded on very swiftly.  So it is a MessageLabs problem by the look of it, but on the sender's side, not your client's.  Unfortunately I don't have enough information to be able to tell you why this occurred.  It's possible you will be able to get more information through the Track and Trace feature of ClientNet, but since the delay occurs on the sender's side  I think that unlikely.  However, the sender would be able to do so if you are able to ask them.  Alternatively you could contact Support, who would be able to research the issue, but again since it is technically a problem with the sender's service rather than your client's, they may not be willing to do so unless the sender raises the ticket.

    Sorry I can't be more help, but hopefully this at least explains why it is only one sender that was experiencing the problem.