Mass mail prevention
This is a two in one feature request. Let me paint you a picture.
Currently we are able to limit the number of emails sent by each domain via WHM -> Tweak Settings -> Mail section.
While this option is great, it's not entirely finished it seems. Once a domain goes over the specified allowed limits, they receive an email saying:Domain XXXXX has exceeded the max emails per hour (125/100 (125%))
allowed. Message discarded.
While this is great in preventing the original spam message reaching it's recipient, it generates such an email for each email the user is trying to send.
So for example lets say we have the hourly emails limited to 100 and a user who uses Joomla! or Wordpress gets hacked, (very common occurrence) and then tries to send out 1000 emails within an hour, the first 100 will go through and the other 900 won't. That's good but WHM will still generate 900 emails saying that the domain exceeded the max emails per hour allowed which clogs our mailservers. This might not be a problem when running 1 or two servers, but if you have, lets say 100 servers with 1000 users on each of them it causes all sorts of issues.
Now here is the actual feature requests:
1) Please add a feature to disable the "Domain XXXXX has exceeded the max emails per hour (125/100 (125%)) allowed. Message discarded." from being sent. Or even better - it should send out ONE such email per domain, but not one email for each email they try to send out.
2) Please add a feature to automatically suspend users which send out mass mail. This would be extremely helpful when dealing with customers who spam not because they are evil :) but because they get hacked. We don't want them sending out emails, but we don't want to terminate their accounts either.If you need any further information or details on this request, please feel free to email me any time at leviatan13@gmail.com
I like this idea 
cPanel, WebHost Manager and WHM are registered trademarks of cPanel, L.L.C. for providing its computer software that facilitates the management and configuration of Internet web servers.
This feature request needs further input and discussion from customers. It is a dangerous precedent to set, in my opinion, with producing silent failures -- especially with regard to email. Email is usually one of the most consuming topics in relation to customer support, and suddenly going silent with regard to mail errors is a scary practice to start.
There is also the logistics behind this in the sense that it is not entirely feasible in a sane way. The feature does not explicitly indicate to Exim "generate an error email". It simply causes a 500 level response (fatal error) which, as with any other 500 level response, causes Exim to generate a bounceback. To not generate a bounceback, something similar to the "blackhole" feature would have to be implemented which would trick the sender into thinking their mail was actually successfully sent. This would further compound confusion where users are seeing their mail "sent" when Exim is actually silently discarding them.
I cannot think of a sane way in which to accomplish this, and silently failing mail as a concept is something I think might scare many system administrators (myself included).
Still, I'd like to hear further feedback and discussion on this from server owners. Unless a sane method of accomplishing this can even be thought up, it's unlikely this will be further considered. If an account is inducing performance problems with a server, the recommended solution is to temporarily suspend it until such time that those issues can be worked out with the user.
This feature request needs further input and discussion from customers. It is a dangerous precedent to set, in my opinion, with producing silent failures -- especially with regard to email. Email is usually one of the most consuming topics in relation to customer support, and suddenly going silent with regard to mail errors is a scary practice to start.
There is also the logistics behind this in the sense that it is not entirely feasible in a sane way. The feature does not explicitly indicate to Exim "generate an error email". It simply causes a 500 level response (fatal error) which, as with any other 500 level response, causes Exim to generate a bounceback. To not generate a bounceback, something similar to the "blackhole" feature would have to be implemented which would trick the sender into thinking their mail was actually successfully sent. This would further compound confusion where users are seeing their mail "sent" when Exim is actually silently discarding them.
I cannot think of a sane way in which to accomplish this, and silently failing mail as a concept is something I think might scare many system administrators (myself included).
Still, I'd like to hear further feedback and discussion on this from server owners. Unless a sane method of accomplishing this can even be thought up, it's unlikely this will be further considered. If an account is inducing performance problems with a server, the recommended solution is to temporarily suspend it until such time that those issues can be worked out with the user.
This feature request needs further input and discussion from customers. It is a dangerous precedent to set, in my opinion, with producing silent failures -- especially with regard to email. Email is usually one of the most consuming topics in relation to customer support, and suddenly going silent with regard to mail errors is a scary practice to start.
There is also the logistics behind this in the sense that it is not entirely feasible in a sane way. The feature does not explicitly indicate to Exim "generate an error email". It simply causes a 500 level response (fatal error) which, as with any other 500 level response, causes Exim to generate a bounceback. To not generate a bounceback, something similar to the "blackhole" feature would have to be implemented which would trick the sender into thinking their mail was actually successfully sent. This would further compound confusion where users are seeing their mail "sent" when Exim is actually silently discarding them.
I cannot think of a sane way in which to accomplish this, and silently failing mail as a concept is something I think might scare many system administrators (myself included).
Still, I'd like to hear further feedback and discussion on this from server owners. Unless a sane method of accomplishing this can even be thought up, it's unlikely this will be further considered. If an account is inducing performance problems with a server, the recommended solution is to temporarily suspend it until such time that those issues can be worked out with the user.
This feature request needs further input and discussion from customers. It is a dangerous precedent to set, in my opinion, with producing silent failures -- especially with regard to email. Email is usually one of the most consuming topics in relation to customer support, and suddenly going silent with regard to mail errors is a scary practice to start.
There is also the logistics behind this in the sense that it is not entirely feasible in a sane way. The feature does not explicitly indicate to Exim "generate an error email". It simply causes a 500 level response (fatal error) which, as with any other 500 level response, causes Exim to generate a bounceback. To not generate a bounceback, something similar to the "blackhole" feature would have to be implemented which would trick the sender into thinking their mail was actually successfully sent. This would further compound confusion where users are seeing their mail "sent" when Exim is actually silently discarding them.
I cannot think of a sane way in which to accomplish this, and silently failing mail as a concept is something I think might scare many system administrators (myself included).
Still, I'd like to hear further feedback and discussion on this from server owners. Unless a sane method of accomplishing this can even be thought up, it's unlikely this will be further considered. If an account is inducing performance problems with a server, the recommended solution is to temporarily suspend it until such time that those issues can be worked out with the user.
While I understand that not notifying the user that their mail was not sent out could be a bad thing, but sending out a bounce-back message for each and every email is not the best solution either due to the fact that the bounce-back messages clog up the mailservers just as bad as the spam emails themselves.
I believe the optimal solution to this would be to provide the server administrator to choose if they want to send those bounce-back messages or not. Or even better - send a bounce-back message with the first failed email message, but not with the other ones. This way the user would be notified that his email failed and that all future emails will fail as well for a specified amount of time.Basically the whole point of this feature request was to give the the server administrator the choice of how they want to handle their spammers, because currently the options are truly minimal.
While I understand that not notifying the user that their mail was not sent out could be a bad thing, but sending out a bounce-back message for each and every email is not the best solution either due to the fact that the bounce-back messages clog up the mailservers just as bad as the spam emails themselves.
I believe the optimal solution to this would be to provide the server administrator to choose if they want to send those bounce-back messages or not. Or even better - send a bounce-back message with the first failed email message, but not with the other ones. This way the user would be notified that his email failed and that all future emails will fail as well for a specified amount of time.Basically the whole point of this feature request was to give the the server administrator the choice of how they want to handle their spammers, because currently the options are truly minimal.
I agree with this comment, and it's desperately needed!! We need to be able to protect our sever MTA rating, by SHUTTING DOWN any email address on our dedicated server (and sending the root owner and the client an email warning) that exceeds the threshold we set, not just delay delivery. If a person sends more than 500 emails in an hour, they are a spammer. I want their email DISABLED until they come to me and ask to have it opened up again.
I agree with this comment, and it's desperately needed!! We need to be able to protect our sever MTA rating, by SHUTTING DOWN any email address on our dedicated server (and sending the root owner and the client an email warning) that exceeds the threshold we set, not just delay delivery. If a person sends more than 500 emails in an hour, they are a spammer. I want their email DISABLED until they come to me and ask to have it opened up again.
Needed!
Needed!
i'm not sure that just the number of emails alone qualifys a sender as a spammer. Non spammers try to send newsletters to their customers, I suppose it just depends on host policies.
for the e-mail reports, what about a setting to only send one every x minutes containing a list of non delivered e-mails instead of sending 500 per minutes for example, limiting the ddos effect a bit.
i'm not sure that just the number of emails alone qualifys a sender as a spammer. Non spammers try to send newsletters to their customers, I suppose it just depends on host policies.
for the e-mail reports, what about a setting to only send one every x minutes containing a list of non delivered e-mails instead of sending 500 per minutes for example, limiting the ddos effect a bit.
Well, CPanel BrianO you asked for server owner feedback, but here's some user feedback:
Gary Savelli> "If a person sends more than 500 emails in an hour, they are a spammer."
Absolutely not! You may not like it if you have a low-end server that can't handle the load or are catering only to grannies (and even then, see my last example). Here are several examples covering the spectrum just from my own personal experience:
- United Airlines sends me an email every week by my choice, and they send it probably to a few million people. OK, that's an extreme example and they have numerous dedicated servers no doubt. So how about ...
- A small restaurant (such as one I partially own) has an opt-in mailing list of about 5000 (the restaurant capacity is just 25), to whom we send emails every 2 months or so. We can space it out to 500/hour if we absolutely had to, but we'd certainly be looking for a different ISP or hosting provider that was not so limiting, particularly if they started accusing us of being spammers. Getting 4500 bounce email messages from our email service provider would definitely be "goodbye forever," not to mention the irony of the justification that this was done to "prevent overload of their servers."
- For my parents 50th wedding anniversary, we sent an announcement to over 1000 people (family, friends, business associates). Not a big deal to space that out over 2-3 hours if we knew about it in advance but certainly having it rejected after 500 and getting 500+ email bounce messages (not to mention having the account disabled and so forth) would be highly unfriendly.
Clearly some limits are necessary for the $5/month type accounts, but policies based on the mentality reflected in blanket statements like, "If a person sends more than 500 emails in an hour, they are a spammer," will just lead to user frustration and dissatisfaction and come back to bite the service provider through attrition and time spend in customer support with frustrated users.
On the CPanel side, I will leave it to others to propose specific solutions since I don't know enough about the underlying mechanisms being discussed, but it has to be made easy for the server owner to provide greater flexibility in how their limits are defined, and more graceful failure in case they are exceeded.
Well, CPanel BrianO you asked for server owner feedback, but here's some user feedback:
Gary Savelli> "If a person sends more than 500 emails in an hour, they are a spammer."
Absolutely not! You may not like it if you have a low-end server that can't handle the load or are catering only to grannies (and even then, see my last example). Here are several examples covering the spectrum just from my own personal experience:
- United Airlines sends me an email every week by my choice, and they send it probably to a few million people. OK, that's an extreme example and they have numerous dedicated servers no doubt. So how about ...
- A small restaurant (such as one I partially own) has an opt-in mailing list of about 5000 (the restaurant capacity is just 25), to whom we send emails every 2 months or so. We can space it out to 500/hour if we absolutely had to, but we'd certainly be looking for a different ISP or hosting provider that was not so limiting, particularly if they started accusing us of being spammers. Getting 4500 bounce email messages from our email service provider would definitely be "goodbye forever," not to mention the irony of the justification that this was done to "prevent overload of their servers."
- For my parents 50th wedding anniversary, we sent an announcement to over 1000 people (family, friends, business associates). Not a big deal to space that out over 2-3 hours if we knew about it in advance but certainly having it rejected after 500 and getting 500+ email bounce messages (not to mention having the account disabled and so forth) would be highly unfriendly.
Clearly some limits are necessary for the $5/month type accounts, but policies based on the mentality reflected in blanket statements like, "If a person sends more than 500 emails in an hour, they are a spammer," will just lead to user frustration and dissatisfaction and come back to bite the service provider through attrition and time spend in customer support with frustrated users.
On the CPanel side, I will leave it to others to propose specific solutions since I don't know enough about the underlying mechanisms being discussed, but it has to be made easy for the server owner to provide greater flexibility in how their limits are defined, and more graceful failure in case they are exceeded.
I think a solution that would allow the suspension of an account a good option, I also think counting email bounce backs rather than emails sent would also be a better way of regulating spam and identifying spam users.
For example if I send 500 emails and greater than 10% of them fail (50 emails) then temporarily disable the sending of emails for that account and then if it maxes out for another hour and again has a high bounce back rate, suspend the account.
Something else that should be considered is an GUI in WHM/cPanel to help identify where spam is being sent from at a file level and a utility to quickly delete/rename those files those files rather than having to use CLI to run a script similar to this:
What another good feature could be is have that similar GUI tool available to cPanel users for their account, and when their account gets flagged as a spammer they can use it as a self help tool to try and resolve the issue before the admin has to become involved. To make this work have a config option that allows one to set how a possible spammer is identified.
I think a solution that would allow the suspension of an account a good option, I also think counting email bounce backs rather than emails sent would also be a better way of regulating spam and identifying spam users.
For example if I send 500 emails and greater than 10% of them fail (50 emails) then temporarily disable the sending of emails for that account and then if it maxes out for another hour and again has a high bounce back rate, suspend the account.
Something else that should be considered is an GUI in WHM/cPanel to help identify where spam is being sent from at a file level and a utility to quickly delete/rename those files those files rather than having to use CLI to run a script similar to this:
What another good feature could be is have that similar GUI tool available to cPanel users for their account, and when their account gets flagged as a spammer they can use it as a self help tool to try and resolve the issue before the admin has to become involved. To make this work have a config option that allows one to set how a possible spammer is identified.
Having these options would be great for someone like me that has a few hundred domains and the associated emails to contend with. The over 500 messages per hour is my first indication that a customers password or computer has been compromised.
If you are using this for your personal webpage(s) then turn it off. If you are running a small business you probably will never outrun the 500 emails per hour if you use one of the mailing list programs. They normally include an Emails Per Hour feature.
Our customers (all small businesses) have been told that these accounts are not for mass mailings. They use Mail Chimp or Constant Contact for their weekly or monthly updates to their customers. This way the people receiving the emails knows it is legitimate and they have a way of turning off the emails if they do not want to be contacted with the promotions anymore. AND they are never reported to a spam blocking program that points back to our email server. That keeps all our customers off the spam block lists.
This is the parameter that I was looking for in this topic area as I just ran into the problem this week and I am still trying to get us off Cisco’s Senderbase.org. Apparently if the IP gets into their database it takes about 5 days to be removed. All for one customer who’s password was hacked and I didn't know until about it until Monday when other customers started calling saying they were having email problems.
Summery: Automatically stopping or turning off an email account would be a nice feature but at the very least it should be in the notification manager that if someone does go above the 500 email limit (or what ever it is set for) the system will notify me (email) and I can call to see if it is a legitimate mass mailing or if their account has been compromised.
Having these options would be great for someone like me that has a few hundred domains and the associated emails to contend with. The over 500 messages per hour is my first indication that a customers password or computer has been compromised.
If you are using this for your personal webpage(s) then turn it off. If you are running a small business you probably will never outrun the 500 emails per hour if you use one of the mailing list programs. They normally include an Emails Per Hour feature.
Our customers (all small businesses) have been told that these accounts are not for mass mailings. They use Mail Chimp or Constant Contact for their weekly or monthly updates to their customers. This way the people receiving the emails knows it is legitimate and they have a way of turning off the emails if they do not want to be contacted with the promotions anymore. AND they are never reported to a spam blocking program that points back to our email server. That keeps all our customers off the spam block lists.
This is the parameter that I was looking for in this topic area as I just ran into the problem this week and I am still trying to get us off Cisco’s Senderbase.org. Apparently if the IP gets into their database it takes about 5 days to be removed. All for one customer who’s password was hacked and I didn't know until about it until Monday when other customers started calling saying they were having email problems.
Summery: Automatically stopping or turning off an email account would be a nice feature but at the very least it should be in the notification manager that if someone does go above the 500 email limit (or what ever it is set for) the system will notify me (email) and I can call to see if it is a legitimate mass mailing or if their account has been compromised.
Replies have been locked on this page!