issues with symantec-smtp-blocking

shanti

Verified User
Joined
Apr 8, 2009
Messages
94
Location
Wien / Vienna - Austria
Hi,

Our customers repeatedly have issues sending mails to domains being protected by symantec.cloud.

Albeit its always a temporary issue, its such an annoying behavior, giving our customers impressions of bad service.

we implemented monitoring for this behavior e.g.:

Code:
+2020-02-10 14:03:20 1j18ic-000xc-Nc H=edge2.omv.com [193.186.185.195]: SMTP error from remote mail server after initial connection: 554 5.7.1 You are not allowed to connect because your IP is blacklisted within Symantec Global Bad Senders. Please check here for more details: http://ipremoval.sms.symantec.com/lookup/

trying to get unlisted via the URl provided, always fails saying "That our ip does NOT have bad reputation at all".

Instead of rating the email , those mailgateways just drop any smtp-connection from our server. I am so angry about this. And it seems there is not much to be done on my side. Denying smtp-connections is IMHO such badass behaviour AAAARG.

consulting the symantec-forum , we are not the only ones affected by this, but symantect use to state that they cannot reproduce the case. Well, neither can we :-(

The symantect-blocklist seems to timeout before any action can be taken. So customers just see that their email cannot be sent.

Technically, i wonder if exim could handle this by some kind of outgoing-greylist, spooling affected emails and resend them 5,10,15 minutes later.

we are really in pain ;-(

thanks for any suggestions

-c-
 
Last edited:
Hello,

In most cases when receiving a 4xx error the sending mail server will attempt to retry delivery after a delay, and may repeatedly do so for up to a day or two depending on configuration before reporting to their user that the mail could not be delivered.

5xx errors will result in the SMTP connection being dropped, and the sending mail server will advise the user that their mail could not be delivered. No further attempts are taken.

See https://en.wikipedia.org/wiki/List_of_SMTP_server_return_codes

Do you have the same issue from other IPv4/IPv6 ?
 
it only happens on domains protected by this symantec-product. we normally have a clean score on spam-blocklists and actually smtp still only runs at ipv4 on our side.

the thread i mentioned is https://www.symantec.com/connect/forums/troubles-ip-reputation
both posters on this thread had the same experience where symantec-support was unable the give a solution.

i wonder how other isps handle this, or if they just pay symantec
 
it only happens on domains protected by this symantec-product. we normally have a clean score on spam-blocklists and actually smtp still only runs at ipv4 on our side.

the thread i mentioned is https://www.symantec.com/connect/forums/troubles-ip-reputation
both posters on this thread had the same experience where symantec-support was unable the give a solution.

i wonder how other isps handle this, or if they just pay symantec

IMO it started with a chinese-isp (chinanet.cn.net) who moved our X-ARF-report to spam-folder because they dont care . since they also use symantec services we think that was the reason we got caught by razor .. we since then disabled all X-ARF-reports. ( which cannot not be the final solution)
 
I found OutLook support in a similar situation, when emails from one of our servers were blocked by OutLook and their support tried to persuade us they don't block our IP. In order to solve the issue did the following:

1. added another IP on the server to send emails
2. started to use remote SMTP service for sending emails.

Another case we periodically face is that IP of one of our public DNS gets banned by spamblocker RBL. The most confusing part is that the DNS server runs only named/bind9, and sends emails only to our corporate email address. Thus I believe we suffer from possible SPAM from the same subnet we a part of.
 
Back
Top