Hello.

I am Matsumoto, the mail administrator.
I work for a Japanese company.

I can't mail to "messagelabs.com". I would like you to investigate.

--------
From(SMTP Server):
52.197.128.153

--------
To:
*.us.messagelabs.com

--------
Error example:

1.Delay long.
 cluster4.us.messagelabs.com[216.82.242.33]:25, delay=3628, delays=3625/0.02/2/0.36, dsn=2.0.0, status=sent

2.Service Temporarily Unavailable.
 cluster4a.us.messagelabs.com[216.82.251.230]:25, delay=72, delays=0.02/0/69/2.8, dsn=4.0.0, status=deferred (host cluster4a.us.messagelabs.com[216.82.251.230] said: 421 Service Temporarily Unavailable ...

From cluster4 to cluster4a?

There was no problem at this site.

http://ipremoval.sms.symantec.com/lookup/

I think that it is probably blocked.
Or, the evaluation of IP may be dropped.

We have several Linux servers on ultiple domains that are not able to send email to messagelab managed domains.  It is starting to cause real issues and I am not able to work out the cause.  Just looking for some assistance.  We are not getting any rejection reason other than "connection timed out". Example of source IP's

49.255.32.194
 

My organisation seems to also be suffering from blocked emails to/from out clients that use MessageLabs.

Our URL is 44communications.co.uk, a domain owned via LCN, run through GSuite (213.239.210.144) 

Our IT support (liaising with Google tech support) suggests the following issue:

"What is happening is the server with the IP address of 194.114.62.76 (Our Client) is rejecting our server's attempts to deliver the messages you send out to them.

I do believe this is due to the fact, that our server library is missing from their SPF record. The SPF itself is an email authentication protocol that allows the owner of a domain to specify which mail servers they use to send mail from that domain. By not having the "include:_spf.google.com" part in theirs, which contains all the IP addresses we use they might be blocking us, due to their local server settings."

Is this an issue you can resolve for us directly? As this is something that is business critical to us now, and is not isolated to just one client.

Best wishes,

Alan

I have a new mail server that as everything needed to be not rejected due to policy 7.7 by messagelabs.com servers.

I has FcRDNS, not an open relay, SPF records published, on a static IP properly, etc.

It is not on the spamhaus policy block list or any other block list from spamhaus.

The reputation check from syamantec shows no bad reputation either.

Yet cluster6.us.messagelabs.com still blocks it by policy.

Can someone from symantec support please look to see if any blocking for my mail server can be removed?  

The IP in question is: 104.130.28.30

Here is a log snippet from policy 7.7 blocking:

D6C22120477: host cluster6.us.messagelabs.com[216.82.249.212] refused to talk to me: 501 Connection rejected by policy [7.7] 21916, please visit www.messagelabs.com/support for more details about this error message.
May 17 11:03:15 postfix/smtp[18456]: D6C22120477: host cluster6.us.messagelabs.com[216.82.242.46] refused to talk to me: 501 Connection rejected by policy [7.7] 9606, please visit www.messagelabs.com/support for more details about this error message.
May 17 11:03:15 postfix/smtp[18456]: D6C22120477: host cluster6.us.messagelabs.com[216.82.251.38] refused to talk to me: 501 Connection rejected by policy [7.7] 16310, please visit www.messagelabs.com/support for more details about this error message.
May 17 11:03:15 postfix/smtp[18456]: D6C22120477: host cluster6.us.messagelabs.com[216.82.241.100] refused to talk to me: 501 Connection rejected by policy [7.7] 22003, please visit www.messagelabs.com/support for more details about this error message.
May 17 11:03:30 postfix/smtp[18456]: D6C22120477: to=<pemalkowski@ra.rockwell.com>, relay=cluster6.us.messagelabs.com[216.82.242.36]:25, delay=16, delays=0.15/0.01/15/0, dsn=4.0.0, status=deferred (host cluster6.us.messagelabs.com[216.82.242.36] refused to talk to me: 501 Connection rejected by policy [7.7] 9416, please visit www.messagelabs.com/support for more details about this error message.)

Thank you.

Dear support,

We are an e-mail marketing company from the Netherlands and since last week we find that all our e-mails our customers send are being blocked by a large e-mail service provider. We have reached out to this e-mail service provider in the Netherlands (kpn.com, telfort.nl, kpnmail.nl) and they tolds us that our e-mails where being blocked because our application domain is blocked by Symantec.

The application domain is: app.enormail.eu. It is used for registering unsubscribes, openrates and link clicks.

They have changed some rules in their spamfilters but the problems are unfortenately not solved. We still get massive amounts of bounces back from the these domains and hope someone here could give us some guidance or assistance.
 

Thank you in advance,

Wijnand van der Weij
Team Enormail 

Over the last few days we have been getting a serious amount of message delaye responses after emailing clients who are behind the message labs email filter.

I have tried countless times to email support emails to investigate but no response. Our business is being severely imapcted due to this and I need someone to point me in the right direction or put me in touch with someone who can. 

Do not ask me to contact a client to contact messagelabs/symantec support on our behalf. It's unfeasable and not going to happen.

Please please please can someone assist?

Thanks.

Hi,

Just started using PBE and have setup a mail to go to the pull portal but every time I get this.

I have also not been given the URL for the portal.  Is this something i should have recevied?  Is there someting that needs configuring on the portal that is causing the error?

Thanks

Ian...

We are sending messages to a messagelabs managed domain (relay=cluster3.eu.messagelabs.com).

Our IP (195.201.21.207) is marked as "The IP address you submitted, 195.201.21.207, does not have a negative reputation and therefore cannot be submitted for investigation." at the IP investigation query.

We do not receive any kind of blocking message, they look as delivered at our logs, and do not appear at the clients inbox (nor spam folder).

What can I do to have my emails delivered to my customers?

Regards,

David.

Hi,

We are having troubles with out outgoing emails to some customers using the messagelabs / symantec system.

Below is an example of the error

The following message to was undeliverable.
The reason for the problem:
5.3.0 - Other mail system problem 553-'Message filtered. Refer to the Troubleshooting page at\nhttp://www.symanteccloud.com/troubleshooting for more\ninformation. (#5.7.1)'

My Email Address Sender is lee.rosales@dxc.com

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

Two issues relating to the same message labs user...

1. We have a client who sends automated mail TO a message labs user, which never arrives, but if they manually send the same email, from the same email address it turns up.

The automated email ges a 250 sent from their mail server to a smtp relay service; this smtp relay service also gets a 250 sent from messagelabs, then the mail just vanishes (according to the intended recipient it never arrived).

Exchange > SpamTitan > SMTP Relay > MessageLabs

2. A different client is expecting email from the same user as #1, and I can see the email hit SpamTitan on our side and then it just fails to proceed... the log just reads..

Jun  4 00:46:19 sentry postfix/smtpd[XXXXX]: NOQUEUE: filter: RCPT from mail1.bemta12.messagelabs.com[216.82.251.1]: <mail1.bemta12.messagelabs.com[216.82.251.1]>: Client host triggers FILTER smtp-amavis:[127.0.0.1]:10021; from=<XXXXX@XXXXX> to=<XXXXX@XXXXX> proto=ESMTP helo=<mail1.bemta12.messagelabs.com>
Jun  4 00:46:19 sentry postgrey[576]: action=pass, reason=client whitelist, client_name=mail1.bemta12.messagelabs.com, client_address=216.82.251.1, sender=XXXXX@XXXX, recipient=XXXXX@XXXXX

Rather than the expected..

May 31 16:16:49 sentry postfix/smtpd[XXXXX]: NOQUEUE: filter: RCPT from mail1.bemta8.messagelabs.com[216.82.243.208]: <mail1.bemta8.messagelabs.com[216.82.243.208]>: Client host triggers FILTER smtp-amavis:[127.0.0.1]:10021; from=<XXXXX@XXXXX> to=<XXXXX@XXXXX> proto=ESMTP helo=<mail1.bemta8.messagelabs.com>
May 31 16:16:49 sentry postgrey[576]: action=pass, reason=client whitelist, client_name=mail1.bemta8.messagelabs.com, client_address=XXX.XXX.XXX.XXX, sender=XXXXX@XXXXX, recipient=XXXXX@XXXXX
May 31 16:17:44 sentry amavis[XXXXX]: (XXXXX) Passed CLEAN {RelayedInbound,Quarantined}, [216.82.243.208]:58830 [203.20.196.14] <XXXXX@XXXXX> -> <XXXXX@XXXXX>, quarantine: Q/clean-QQoKuYED7CJa, Queue-ID: 6B8FE4AD18A, Message-ID: <XXXXX@XXXXX>, mail_id: QQoKuYED7CJa, Hits: 2.345, size: 656110, queued_as: E05FA4AD1B0, Tests: [BAYES_00=-1.9,DKIM_SIGNED=0.1,DKIM_VALID=-0.1,DKIM_VALID_AU=-0.1,HTML_MESSAGE=0.001,IGNORE_BAYES_00=1.9,KAM_NW=2.75,PYZOR_CHECK=1.392,RCVD_IN_MSPIKE_H2=-1.697,SPF_HELO_PASS=-0.001], dkim_sd=messagelabs:XXXXX, 6324 ms
May 31 16:17:44 sentry amavis[XXXXX]: (XXXXX) Passed CLEAN, <XXXXX@XXXXX> -> <monica@XXXXX>, Hits: 2.345, tag=-999, tag2=5, kill=5, queued_as: E05FA4AD1B0, L/Y/0/0
May 31 16:17:46 sentry postfix/smtp[77470]: E05FA4AD1B0: to=<XXXXX@XXXXX>, relay=XXX.XXX.XXX.XXX[XXX.XXX.XXX.XXX]:25, delay=1.7, delays=0.04/0/0.14/1.5, dsn=2.6.0, status=sent (250 2.6.0 <XXXXX@XXXXX> [InternalId=XXXXX] Queued mail for delivery)

MessageLabs > SpamTitan > Exchange (not since May 31)

The MX records for the MessageLabs user are:

cluster5.us.messagelabs.com

cluster5a.us.messagelabs.com

Any ideas?

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.

We have recently had emails to clients using Symantec Cloud being blocked.

The clients don't understand why similar emails that got through last week are now being rejected 5(53 message filtered) by their system.

We've checked with Microsoft/MX tools  who confirm we aren't on any blacklists or having an issues with our servers and it must be an issue with Symantec as it's affecting so many users.

We are about to escalate this with every client so they get an answer from their IT department/Symantec

I thought posting on here might resolve the issue directly without trying the above which would certainly have a reputational impact to Symantec

I would appreciate a PM to help resolve this (Is it an IP/Hyperlinks/Content issue?)

Looking forward to hearing from you soon

Richard

Hi All

Im trying to fix a problem a client have ,  we cannot receive emails from one domain and it started some days ago..before it was working.

I can find this on Symantec cloud spam log :  Response: 454 4.7.5 [internal] verify error:num=21:unable to verify the first certificate:depth=0:/CN=xxxxxxx

Server = exchange 2013  Version 15.0 ‎(Build 1263.5)

We can send to them 

No changes has been made to the server in 3m , 

Can the problem be on the senders side ?

Thanks

Niklas 

Hi Team,

Starting this month I cannot send e-mails to addresses hosted on eu.messagelabs.com.

Our e-mail server have IP address 194.105.4.6 (mail.smart.com.ro).

My customers tried to sent e-mails from different domains to differrent domains hosted on eu.messagelabs.com (carmeuse.ro, sews-e.com, vodafone.com).

The status is: lost connection with cluster5.eu.messagelabs.com[46.226.52.103] while performing the EHLO handshake.

There wasn’t any spam sent from our server. There wasn’t any security incident in the last months.

We already checked also your reputation service at the following addresss and reported that our IP is clean:

http://ipremoval.sms.symantec.com/lookup/

Please, can you assist me to solve this problem?

Hello, we cannot send emails to any of your customers located on cluster3.eu.messagelabs.com.  Messages queue at our side with the error: lost connection with cluster3.eu.messagelabs.com[46.226.53.54] while performing the EHLO handshake.

I have checked the RBL lists and we appear to be clear for spam activity. Would you please investigate why this would be the case?

Thank you.

Hello, we can not receive emails sended via messagelabs.com.

In some cases we lost about 10% of email flow in some cases it is about 100%

For example today we got NDR from one of out customer who use messagelabs.com and can not send to us:

Delivery has failed to these recipients or groups:

_our_email_

The server has tried to deliver this message, without success, and has stopped trying. Please try sending this message again. If the problem continues, contact your helpdesk.

Diagnostic information for administrators:

Generating server: server-6.bemta.az-a.eu-central-1.aws.symcld.net

_our_email_

Remote Server returned '< #5.4.7 smtp; 554 5.4.7 [internal] exceeded max time without delivery>'

Original message headers:

Return-Path: _customer_email_

Received: from [85.158.142.98] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits))

by server-6.bemta.az-a.eu-central-1.aws.symcld.net id 77/68-03534-A10CE0B5; Wed, 30 May 2018 15:15:38 +0000

We did not see any traffic from this ip 85.158.142.98

But we can see traffic from:

85.158.142.117

85.158.142.116

85.158.142.125

85.158.142.4

85.158.142.121

I already send email request with real domain names to investigation@review.symantec.com

Pls provide solution to us!

Hi All,

I have recently been tasked with emails reroute challenge to Exchange Online via MessageLabs. The current change needs to be made for a Hybrid Environment with either EXO and On-Prem Mailboxes (there is still a migration ongoing). The reason why the customer wants to make this change is that the new managed domains -- tenant.onmicrosoft.com and tenant.mail.onmicrosoft.com both have internet-routable MX records. So when we synchronise mail-enable users and migrate them, they get stamped with a tenant address. Moreover, since you can also deliver emails to the new stamped tenant address, this is a high-security risk. Further, this as per business requirement is not acceptable as emails with the tenant address *onmicrosoft.com are not being analysed with the Symantec.Cloud protector (As their main SMTP address via MessageLabs) which is seating in front of Exchange Online Protection.

We tried to make the below change but it has miserably failed:

#From Exchange Online Powershell

[array]$TenantDomains = (Get-AcceptedDomain).Name

New-OutboundConnector -Name 'Reroute to MessageLabs' -IsTransportRuleScoped $true -UseMXRecord $false -SmartHosts 'cluster1.eu.messagelabs.com','cluster1a.eu.messagelabs.com'

New-TransportRule -Name 'Reroute to MessageLabs' -RecipientDomainIs $TenantDomains -RouteMessageOutboundConnector 'MessageLabs Connector' -ExceptIfHeaderContainsMessageHeader 'X-MS-Exchange-Organization-AuthAs' -ExceptIfHeaderContainsWords 'Internal' -ExceptIfHeaderMatchesMessageHeader 'X-RoutedThroughOnPremises' -ExceptIfHeaderMatchesPatterns 'Yes' -StopRuleProcessing $true -Priority 0

#From Exchange Management Shell on-premise

New-TransportRule -SetHeaderName 'X-RoutedThroughOnPremises' -SetHeaderValue 'Yes' -Name 'Routed Through OnPremises' -StopRuleProcessing:$false -Mode 'Enforce' -Comments 'Set X-RoutedThroughOnPremises header to Yes on all messages' -RuleErrorAction 'Ignore' -SenderAddressLocation 'Header' -Priority 0

We have analysed the message headers flow and noticed this behaviours, emails are being delivered with the following flow:

External > Symantec ATP > Exchange Online Protection (EOP) > Exchange Online > Exchange Online Mailbox

In my understanding, Microsoft doesn't support this scenario. We cannot reroute *onmicrosoft.com stamped emails to Symantec.Cloud as they are just filtered via EOP or AETP.  The option here would only be that Symantec ATP seats in front of Exchange On-Premises to allow it to reroute the emails to Exchange Online. Is this behaviour correct? Do we need to change the design of the Hybrid configuration to make this working with the above requirements?

Also, we were thinking to add the following edited X-BrightMail Tracker with the following Header Line ^\S+$ as shown below to the transport rule to force emails to go through MessageLabs:

ExceptIfHeaderMatchesMessageHeader 'X-BrightMail-Tracker' -ExceptIfHeaderMatchesPatterns @('^\S+$')

We have not been able to try this yet, but to my knowledge, this won't work as email headers in email security.Cloud cannot be changed or used again. Is this correct?

I removed the certificate on my email server and turned off the TLS feature because of some cost issue.

Then .Cloud started to send outbound message without encryption.

.Cloud never tries TLS even if 3rd party mail servers (ex: gmail.com) explicitely allow TLS if you send outbound messages without TLS.

Here is a figure which explains the situation.

Here is some additional information:

20180502_FAILED.eml -> TLS test result after I turned off TLS on my server (TLS failed)

20180502_SUCCESSFUL.eml -> TLS test result after I turned on TLS on my server (TLS succeeded)

Hello,

We have multiple external parties who complain about delays in emails. The common factor seems to be messagelabs in the path between

See the headers below

Hop	Delay	From	By	With	Time (UTC)	Blacklist
1	*	ANMLMBX1002.asp.local	ANMLHT2001.asp.local	mapi	6/7/2018 12:51:18 PM
2	0 seconds	ANMLHT2001.asp.local 10.254.233.2	keys.hierinloggen.nl		6/7/2018 12:51:18 PM
3	0 seconds	keys.hierinloggen.nl 194.151.85.27	smtp.hierinloggen.nl	ESMTP	6/7/2018 12:51:18 PM
4	5 hour	smtp.hierinloggen.nl 194.151.85.22	server-20.tower-222.messagelabs.com	DHE-RSA-AES256-SHA256 encrypted SMTP	6/7/2018 5:24:04 PM
5	0 seconds	network			6/7/2018 5:24:04 PM
6	1 Second	using 85.158.142.97	server-5.bemta.az-a.eu-central-1.aws.symcld.net	cipher DHE-RSA-AES256-GCM-SHA384 (256 bits))	6/7/2018 5:24:05 PM
7	0 seconds	mail6.bemta26.messagelabs.com 85.158.142.45	triton22.abnamro.nl	ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384	6/7/2018 5:24:05 PM
8	0 seconds	triton22.inet.nl.abnamro.com 10.121.46.226	aaamsr104.abnamro.com	ESMTP	6/7/2018 5:24:05 PM
9	1 Second	aaamsr104.abnamro.com 10.21.177.18	aaamsr003.abnamro.com	ESMTP	6/7/2018 5:24:06 PM