cluster{x}a.eu.messagelabs.com deferred mail from users at our domain

I need a solution

Hello.

I am hoping someone from Symantec support could look into this problem.

When sending mail from our domain (bfpe.com) to customers whose MX records point to both

cluster3a.eu.messagelabs.com

and

cluster8a.eu.messagelabs.com

mail is being deferred with the following message:

dsn=4.0.0, stat=Deferred: 421 esmtp: protocol deviation

The source IP for bfpe.com’s mail relay (smtp.bfpe.com) is 208.79.82.226.

I have checked the IPs reputation on mxtoolbox.com and directly at http://ipremoval.sms.symantec.com/lookup/ and there’s nothing to see there.

Mail to MX records at us.messagelabs.com (cluster{1,4}.us.messagelabs.com) are delivering normally, but I see instances where mail to cluster1a.us.messagelabs.com is also deferred with the same “protocol deviation” error.

It does seem that the cluster{N}a (where in is an integer like 1,2,3…) records are always the backup MX records for the domain. Is there some reason why when we initially queued the messages, the primary MX was unreachable and forced the switch to the backup? And now because the messages are queued for the “backup” and the “primary” is available we are being rejected (using a lower priority MX when the higher priority MX is available is a SPAMmer trick — hence the “protocol deviation”?)

Can anyone shed a little more light on why in particular cluster{N}a.eu.messagelabs.com and cluster{N}a.us.messagelabs.com MX destinations are deferring (for days now) mail from our users?

Thanks for your insights.

0

Related:

Blocked IP address

I need a solution

Hi

my client (u-pol.com.au) is trying to email their parent company (u-pol.com) but their emails aren’t getting through the messagelabs filtering.

they are getting 421 service temporarily unavailable   when emailing out to this domain.

i checked this article https://support.symantec.com/en_US/article.TECH247121.html so i checked their DNS. their DNS resolves correctly and does the nslookup for the MX records correctly but when i do a telnet into the primary MX it won’t connect, but it will to the secondary MX record.

also a tracert doesn’t get to the primary MX.
my clients domain is mail.u-pol.com.au 210.9.24.118 and they are trying to email to @u-pol.com which has the MX records of cluster1.eu.messagelabs.com and cluster1a.eu.messagelabs.com

can you please remove the block for the IP 210.9.24.118 ( i did do a lookup of this IP on http://ipremoval.sms.symantec.com/lookup/ but it’s not listed with a negative reputation

0

Related:

7022903: Multi-tenant SMTP redirection logic

Note: This page applies to systems updated to SMG after April 2018 update. Prior versions did not have the same architecture.

This page provides details of how the SMG SMTP interface manages connections between sender and recipient servers, with particular attention to how messages are handled when the sender and recipients exist within the same SMG environment.

For most situations, where email comes in, or goes out of an SMG system, the expected behavior of SMG being a middleman process between the relevant SMTP end points will occur. In these core cases messages will be defined as inbound or outbound as expected for the purpose of selecting policies to use for filtering.

The two situations identified in the diagram with red lines indicate unusual or mis-configured situations. In the case of external direction, this implies relay protection is not enabled if email is allowed. In the case of sender/recipient share OU, this should not be a configuration scenario, as it suggests an email server is sending its own mail with a loopback through SMG. Although both are possible and acceptable, having mail delivery in either of these situations should be well understood.

The specific case where multi-tenant logic overrides the regular flow of connectivity is where a message is sent between two domains hosted by an SMG system, where the two domains exist in separate OUs. In this situation, there are two separate sets of policies that need to be considered. For the sender, the outbound policy of their OU must be used. For the recipient, the inbound policy of their OU must be used. The implementation of this is performed through a loopback mechanism with SMTP.

When a loopback message is encountered, on the first hop, SMG treats the recipient as external for the purpose of direction and next-hop connectivity. The next-hop ignores the locally defined addresses and instead looks up the MX record of the target domain. It is useful to understand that when multiple MX records exist, this may cause the message to come back through a different SMG server than the one that has received the original connection. During this connection phase, the SMG server will detect that the next-hop system is an SMG server by the presence of the ESMTP EHLO keyword ‘X-SMGFLAGS’. If the loopback server responds as expected, the MAIL command is given the parameter ‘X-SMGReentrant=1’ to indicate to the next hop that the message being received must be treated as if it were coming from an unknown sender.

When the second hop SMG server receives a connection that indicates hat the sender is external, by way of the ‘X-SMGReentrant=1’ flag being present on the MAIL line, the sender is treated as unknown and the direction is defined accordingly based on the recipient address. The address should be to a known address within the system and be treated as inbound. If the sender is not internal, which would only occur by either MX misconfiguration or direct attempt to add the parameter, the message will be rejected as an attempted relay (presuming relay prevention is correctly configured).

The net result of this inter-OU handling process is that policies are process independently and in order by each OU. Rejection at either the sender or recipient OU will chain correctly via the SMTP protocol. Isolation of domains and OUs through the SMTP protocol also helps to locate issues where inter-OU mail flow occurs.

Related:

Releasing SPAM taking long time (10 minutes) in Messaging Gateway with Active Directory with Glocal Catalog

I need a solution

Releasing SPAM taking long time (10 minutes) in Messaging Gateway with Active Directory with Glocal Catalog

hello dear technicals,

i have Symantec Messaging Gateway (SMG) Virtual Appliance,

i added my domain through “Active Directory with Global Catalog

also i added my local-mail-delivery with IP-Entry (local-mail-delivery is not MX Record)

my mail server’s are Exchange DAG, 

i read every best practice, forum’s, KB’s, Admin Guide and more about SMG, Exchange, Active Drectory

my configurations are good and standard,

but when i want to releasing a spam, it take long time (10 ~ 15 minutes)

i checked every solutions, and also my configuration are good

please help me

0

Related:

Emails being Rejected / Delayed / Filtered by MessageLabs

I need a solution

Hi,

We are owning the domain alarmnet.com and users who have purchased Honeywell thermostats receive all kind of alerts, notifications, registration information as emails to their registered email IDs. The SMTP servers used to send emails are below.

198.140.154.31

204.141.56.152

204.141.56.6

198.140.154.32

The above SMTP servers are working fine and we are not facing any undelivered issues. We recently migrated our SMTP servers and now using the below SMTP servers.

199.62.84.36

199.62.84.67

While we were facing problems with our SMTP spool count, we surprised to find that all the emails which are not delivered or kept in spool for 2- 4 days are for MessageLabs (The domain’s MX records resolves to MessageLabs). I could see my new IPs 199.62.84.36 & 199.62.84.67 are not blacklisted anywhere including symantec nor they have bad reputation. I belive there is some black or filter from your side needs to be adjusted. Can you please check and help fix the issue. We suspect our customers are missing emails. 

Some of the messagelabs domains we send email:

ancilla.edu

wellsfargo.com

reyesholdings.com

csc.com

newmarketinc.com

hrgreen.com

daybreakventure.com

Please help. 

0

Related:

messagelabs.com Socket error 10060

I need a solution

Good Morning,
​We not be able to send messag to all email addres that use messagelabs.com.
​We are not in black list and our domain, hugotrumpy.it is correctly configured.
Please help us urgently.
​se below an exsample of the errors:

====================================================================

=  Greetings from the MDaemon mail system at htmail.hugotrumpy.it  = ====================================================================

The following message:

     Session-ID: 546330 (specific to this delivery attempt)

       Queue-ID: pd90000003330.msg

     Message-ID: 004b01d369a9$7096d900$51c48b00$@hugotrumpy.it

has not (as yet) been delivered to the following recipient(s):

despite one or more unsuccessful attempts to do so.

Delivery attempts will continue for up to 48 hours (2 days).  If delivery fails after that time you will be separately informed.

You do not need to resend the message!

The original message headers follow at the end of this report.  For information on DSN messages see http://www.altn.com/dsn/.

Please quote the Queue-ID, Session-ID, and Message-ID found above in any inquiries regarding this message.

========================

=  Session Transcript  =

========================

  Session 546330; child 0004

  Parsing message <xxxxxxxxxxxxxxxxxxpd50000693451.msg>

  *  From: gr.pandi@hugotrumpy.it

  *  To: hongkong@londonpandi.com

  *  Subject: GLORY HONGKONG

  *  Size (bytes): 9363

  *  Message-ID: <004b01d369a9$7096d900$51c48b00$@hugotrumpy.it>

  *  Route slip host: londonpandi.com

  *  Route slip port: 25

  Resolving MX record for londonpandi.com (DNS Server: 192.168.1.151)…

  *  P=010 S=000 D=londonpandi.com TTL=(60) MX=[cluster3.eu.messagelabs.com]

  *  P=020 S=001 D=londonpandi.com TTL=(60) MX=[cluster3a.eu.messagelabs.com]

  Attempting SMTP connection to cluster3.eu.messagelabs.com

  Resolving A record for cluster3.eu.messagelabs.com (DNS Server: 192.168.1.151)…

  *  D=cluster3.eu.messagelabs.com TTL=(5) A=[85.158.137.67]

  *  D=cluster3.eu.messagelabs.com TTL=(5) A=[85.158.137.83]

  *  D=cluster3.eu.messagelabs.com TTL=(5) A=[85.158.136.3]

  *  D=cluster3.eu.messagelabs.com TTL=(5) A=[85.158.139.3]

  *  D=cluster3.eu.messagelabs.com TTL=(5) A=[85.158.136.35]

  *  D=cluster3.eu.messagelabs.com TTL=(5) A=[194.106.220.35]

  *  D=cluster3.eu.messagelabs.com TTL=(5) A=[85.158.137.35]

  *  D=cluster3.eu.messagelabs.com TTL=(5) A=[194.106.220.51]

  Randomly picked 194.106.220.35 from list of possible hosts

  Attempting SMTP connection to 194.106.220.35:25

  Waiting for socket connection…

  *  Socket error 10060 – The connection timed out.

  *  194.106.220.35 added to connection failure cache for 5 minutes

  Attempting SMTP connection to cluster3a.eu.messagelabs.com

  Resolving A record for cluster3a.eu.messagelabs.com (DNS Server: 192.168.1.151)…

  *  D=cluster3a.eu.messagelabs.com TTL=(5) A=[85.158.139.103]

  Attempting SMTP connection to 85.158.139.103:25

  Waiting for socket connection…

  *  Socket error 10060 – The connection timed out.

  *  This message is 65 minutes old; it has 0 minutes left in this queue

  Remote queue lifetime exceeded; message placed in retry queue

========================

=    End Transcript    =

========================

0

Related:

MessageLabs mail flow rule

I need a solution

Hi,

Where in MessageLabs would a person find the settings to:

* Ignore an email domains DNS MX records

* Send directly to another destination such as Office 365 for a specific domain

Now, before everyone goes off their nu…I don’t actually want to do this. I’m not crazy, but I need to know where in MessageLabs I would do this so I can tell a 3rd party partner (that is crazy) where to remove this setting (which they refuse to acknowledge they have configured).

Thank you.

0

Related:

Using Messagelabs for outgoing only

I need a solution

Hi, a bit of an unusual query. Are we able to setup Messagelabs to route mail out only?

I know we would lose a lot of the functionality, but we would like a spare outgoing gateway. So our MX records still stay the same, and Messagelabs doesnt handle any of that, we just use it for certain outgoing traffic.

Thanks,

Nathan

0

Related: