Delay SMTP transaction for incoming spam - Bad idea
Last night a bunch of our servers updated to 11.52 and our SMTP monitoring went nuts. We then looked at the 11.52 release notes and found this: 11.52 Release Notes - Documentation - cPanel Documentation
While this new feature is 'interesting' why is it enabled by default and not in the new feature showcase?
The release notes also appear to be incorrect. Adding our monitoring servers to the Exim white-list does nothing. We ended up having to add them to "Trusted SMTP IP addresses".
We're going to give this a while, but my guess is that we'll end up disabling this feature. With this feature enabled we were getting a 20 second delay in SMTP and I don't think most SMTP servers will wait that long.
-
The release notes also appear to be incorrect. Adding our monitoring servers to the Exim white-list does nothing. We ended up having to add them to "Trusted SMTP IP addresses".
Hello :) Internal case DOC-6194 is open with our documentation team to address this documentation error. The "Trusted Mail Hosts" or "Skip SMTP Checks Host" lists are viable alternatives.With this feature enabled we were getting a 20 second delay in SMTP and I don't think most SMTP servers will wait that long.
Legitimate mailing systems do typically wait past the delay, but please feel free to let us know of any specific examples where this is not happening, or provide examples where this setting is causing problems for specific email clients. Thank you.0 -
@cPanelMichael Thank you for the documentation update, but that was not really the point. I though that the 'feature showcase' in WHM was to alert us to big changes and let us decide if we want to implement them. So far that has worked very well (in our opinion). This is a big change ( i.e. big warning box in the Wiki) so it should not have just been 'slammed' in with the 11.52 upgrade, we should have been able to decide if/when to implement this. 0 -
I'm pretty much with ffeingol on this. Shouldn't have been On by default. And i have mixed feelings about the feature. I know that usually spammers will drop the connection before 20s, but i feel that may be a couple super optimized legit servers, who won't wait 20 sec. Also, unlike blacklist or similar based techniques, this penalize everyone, even legit senders too ( who didn't sent mail yet to us ). I would rather see an IP senders core based delay ( ex senderscore.org ) which auto whitelists Ip's with scores over let say 70. Third : if most of the exim servers ( i guess a huge percentage of exim servers are cPanel servers ) will delay connection by 20 sec, then the spammers will switch to wait 20 sec . 0 -
Hi Eric, Thanks for your reply. I didn't see this included in the new feature showcase for some reason. I just checked again and it's definitely not there. This is massive change and I'm not only concerned about the fact I'm now going to have to undertake a massive configuration change for our monitoring services across our entire portfolio of cpanel boxes, but that not all mail servers are going to wait that long to connect. Big players like Google (GMail) don't delay sending of their ESMTP banner headers. Is this rudimentary feature really a good idea? It looks to me like it'll cause more problems than solve. Why would this feature be hidden away and then enabled by default? Surely this is one that would be best left to being off by default and then after your end users have tested in their labs, they can choose to turn on this antiquated anti-spam solution if they so desire? 0 -
Hello :) Historically, the "Feature Showcase" is not always utilized for every new feature, and the decision to enable this feature by default was based on feedback (and a general lack of complaints) from testers when version 11.52 was introduced to the "Edge" build tier. Feel free to subscribe to the Edge-Users mailing list if you want to add your feedback on these types of topics in the future: Edge-Users Info Page Could you verify any specific instances where this feature is affecting incoming email from providers such as Google? Thank you. 0 -
This is causing our datacenter big issues. Remote SMTP servers and/or SPAM filtering devices don't all have the same timeout values and we are getting a lot of reports of messages that never make it to destination because of that setting that you had enabled by default. This should seriously be re-considered. 0 -
Hi, I'm managing 1000+ cPanel and lots of clients contacted me today about not receiving mails, I think this feature is a great idea but should be DISABLED by default! 0 -
Very odd. In this thread cPanelMichael asked (twice) for specific instances where this feature is affecting incoming mail. I posted a response about not receiving Capital One credit card account alerts being sent via a very large email service provider, Epsilon / Bigfoot Interactive. This happened the day this update went live on my server. When I tracked it down and turned this feature off I started receiving my credit card account alerts again immediately. With Epsilon being a huge ESP that sends email for many large legitimate companies and this feature blocking the receipt of very important emails like credit card activity alerts I pointed out that this is a very strong reason why this feature should not be turned on by default. Now for some strange reason my post was moved from this thread where this feedback was asked for to a completely new thread of its own with no explanation. Having one thread to track this issue seems more appropriate than dividing it up. Its also useful for people to see in one thread that there are people who can provide specific examples of where this is causing problems. 0 -
Hello :) The additional thread is located at: Delay SMTP transaction A separate thread was required because it's a specific issue related to this feature that's addressable, as opposed to an overall concern with how the feature was enabled by default. Thank you. 0 -
Hello :) The additional thread is located at: Delay SMTP transaction A separate thread was required because it's a specific issue related to this feature that's addressable, as opposed to an overall concern with how the feature was enabled by default. Thank you.
Actually my issue is mainly with enabling it by default. Turning the feature off fixes my problem and I'm happy with it that way. The problem with enabling it by default is its extremely difficult to determine that his feature is causing the messages to be be blocked as the SMTP server name can be something seemingly unrelated to the sender when they use an ESP. Once I realized I wasn't receiving these emails I started out looking for the reject reason using "Mail Delivery Reports" for capitalone.com. Nothing there after the upgrade. No messages being rejected nothing. A look in the Exim logs comes up the same - no messages about capitalone.com after the upgrade. It as if Capital One never attempted to send the messages. So I opened an issue with Capital One as I assumed they were never sending them due to a problem on their end. I wasted a lot of time doing that and being told to put their email address in my address book, etc. all things that had nothing to do with the problem. Then I dug back through logs prior to the upgrade to find successfully received messages and saw the name of the SMTP server Capital One was using. Then I looked at current logs to find messages for that server and saw that the connection was being dropped. Even then, it wasn't clear what the problem was but I suspected maybe one of the spam rejection features but I saw nothing in the logs to indicate that. I ended up turning on and off Exim settings one by one to determine which setting was causing the problem. That's an extremely time consuming way to track down an email rejection problem from a legitimate sender. In short, the fact that, by the nature of the feature, you can't report on why a sending server dropped a connection and what domain it was trying to send the email for makes it a really bad feature to enable by default. Its something that an administrator should have to consciously turn on and monitor for problems.0 -
Ongoing issue where "new" options are turned on by default but server admins are presumed to have read the changelog and been able to decipher how those changes would affect their customers. Edge builds and the attendant changes should be better vetted before being passed on to Current and Release builds. Nothing new really just more of the same. 0
Please sign in to leave a comment.
Comments
11 comments