SMG doesn’t use higher preference MX routes?

I do not need a solution (just sharing information)

We have a compliance rule which routes matching messages to a domain name using MX records that we have defined in our DNS.  There are two MXes with preference 10 and one MX with preference 100.

During our most recent DR test, when both MX 10s were unavailable, the matching emails were just queueing up, Not willing to go to the MX 100 route.  I even started a TCPDUMP session which detected zero attempts to connect to the MX 100 target host.

Lowered the MX to 50.   Nothing.

Lowered the MX to 10, to match the other two – bingo, the emails flowed out to that target host.

So what’s going on there?  Is SMG’s routing logic broken?

0

Related:

Being throttled by Messagelabs Server

I need a solution

Hi Support

cluster5.eu.messagelabs.com throttling our mail servers.

We had issues on our mail queues and once we resolved it, a lot of mails were sent in the queues. Subsequently we are now being throttled. I have mailed, called Symantec Support to no avail. Please assist us urgently.

Date Received: 2019/03/25 13:56:19

Expiration Time: 2019/03/27 13:56:19

Last Error: 421 Service Temporarily Unavailable

196.214.76.171 External MX record mail.4cgroup.co.za

196.22.223.200 External MX record mail1.4cgroup.co.za

209.203.1.2 External MX record mail2.4cgroup.co.za

Kind Regards

Leo

0

Related:

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: