Announcement

Collapse
No announcement yet.

Email Delivery Weirdness

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Email Delivery Weirdness

    Hi all,

    Wondering if anyone could shed some light on the following if possible - We have a client who has all of their incoming emails scanned for spam or malware via Symantec Protect Cloud. The way it works is you set the MX records to the ones they tell you do and in the control panel of Symantec for the client you add the inbound route of the mail server so the IP address. Normally works well and it is working - Although I have noticed this client is getting spam emails that are going straight into the email account. But they aren't actually being scanned by Symantec, they seem to be getting delivered straight to the account somehow.

    For example here is part of the headers of an email that did get scanned:

    HTML Code:
    Received: from unknown (HELO mail6.bemta26.messagelabs.com) (85.158.142.41)
        by *server name here* with SMTP; 11 Oct 2019 17:34:44 +0100
    And here is part of a header of an email that did NOT get scanned:

    HTML Code:
    Received: from unknown (HELO mandiesees.com) (89.144.63.154)
        by *server name here* with SMTP; 11 Oct 2019 18:13:57 +0100
    Any one got any ideas how this can be happening? I feel like this might be something on the server. But I'm not too sure. Any help will be appreciated.

  • #2
    Hi Bertie

    I hope your well

    If I understand correctly, your siteworx client MX points to a different server.

    Therefore it is at the other server which is not scanning

    There is 1 other possible reason, and that is the email is been delivered to your IW server without using the mx record - say A record of the domain so bypassing messagelabs servers

    If that is the case, then route all email for domain using smart host and test as it might cause a loop. If so, I would have to think about it as it should be possible to whitelist I think the messagelabs cidr

    Many thanks

    John

    Comment


    • #3
      Originally posted by d2d4j View Post
      Hi Bertie

      I hope your well

      If I understand correctly, your siteworx client MX points to a different server.

      Therefore it is at the other server which is not scanning

      There is 1 other possible reason, and that is the email is been delivered to your IW server without using the mx record - say A record of the domain so bypassing messagelabs servers

      If that is the case, then route all email for domain using smart host and test as it might cause a loop. If so, I would have to think about it as it should be possible to whitelist I think the messagelabs cidr

      Many thanks

      John

      The domain has external MX records in place so: cluster8.eu.messagelabs.com and cluster8a.eu.messagelabs.com. It has been scanning incoming emails as I can see that taking place, it seems that some emails (mainly spam ones) are somehow bypassing those MX records where the filtering is and is being delivered straight to the email account. There is/was an A mail.yourdomain.com record which I have now deleted to see if it will help. I haven't come across this before as we have some other custs who have a similar setup too.

      Will have to see if the removal of the A record helps.
      Last edited by Bertie; 10-13-2019, 04:15 PM.

      Comment


      • #4
        They still get emails that is bypassing the MX record filtering somehow and I'm not quite sure how/why. This is the headers of the spam emails (they are all very similar in terms of content, what they are about etc):

        Received: (qmail 5462 invoked by uid 108); 14 Oct 2019 20:59:12 +0100 Received: by simscan 1.4.0 ppid: 5358, pid: 5420, t: 0.6619s scanners: clamav: 0.101.2/m:58/d:25601 Received: from unknown (HELO primecenterz.com) (185.244.27.29) by *ourservername* with SMTP; 14 Oct 2019 20:59:11 +0100 Received-SPF: pass (*ourservername*: SPF record at primecenterz.com designates 185.244.27.29 as permitted sender) DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=primecenterz.com; s=dkim; t=1571080891; bh=cunvk2puCTjsD8sUrsA4VHBN2t0=; h=From:Date:To:Message-ID:Subject; b=By60n44664qnyU5PKJ9ZF7JU5e7YeXqEdrKaP4X8ooskaHbm TYnSeqvIxp5kVes/+ kMco2XpArJzi7YnohHrtjkox9R2Z+EPxgQ5fLeXooIvt3Zyegm UBIPiPMa/Z7MrZNX DsqWt3Qwo8bU2z8ABhzVUoGEzsSSdoEhcsUYfBZo= From: "Overstock Wines" <russell@primecenterz.com> Date: Mon, 14 Oct 2019 15:21:31 -0400 MIME-Version: 1.0 List-Unsubscribe: <http://uebIV75VOKRFmyj.primecenterz.com/198800195986e368076970c01_bbcaa45d/3/> To: "chris@clientsdomain.co.uk" <chris@clientsdomain.co.uk> Message-ID: <fabAE2QK1283hhy.ociF749KJEQ8stw@primecenterz.co m> Subject: Inventory Low: Premium Wines Only $5.66 Each Content-type: multipart/alternative; boundary="---=_Part_0095_71M181C21.Y879FZ6";

        Comment


        • #5
          Hi Bertie

          Many thanks

          They could be using direct server ip or any mx record pointing to your server

          I believe Symantec advice to lock down port 25 to answer only to their ip addresses to stop a bypass but if not all clients use Symantec that is no good and would stop other users

          I will have to have a think as smart host may just cause a loop

          Many thanks

          John

          Comment

          Working...
          X