shanti
Verified User
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.:
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-
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: