On Wed, Feb 27, 2013 at 10:11 AM, francis picabia <fpica...@gmail.com>wrote:
> Hi, > > The number of phishing or otherwise compromised accounts is needing > an automation to manage it. Last night the spammers waited until > the evening and simultaneously used 3 compromised accounts to send > spam over secure smtp. A nagios alert on number of messages > in the queue was our only alarm, and in only a couple of hours > the reputation of the server and domain is damaged for awhile (both in and > out). > > I added smtpd_recipient_limit=20 to the options for secured SMTP. > The error it produced when tested (with Thunderbird) is confusing: > > The size of the message you are trying to send exceeds a temporary size > limit of the server. The message was not sent; try to reduce the message > size > or wait some time and try again. The server responded: 4.5.3 Error: too > many recipients. > > If the user patiently reads to the end, the last statement is the only > thing they > need to know. However, the previous statements are wrong and misleading. > How can this error be made better? > > Thanks for the answers everyone. Crystal clear the vagueness is all Thunderbird's. I had a set of cascading iptables rules to rate limit new connections, but they circumvented this as well. Based on the IP, there were 5 connections per minute and 15 connections per 5 minutes. If those were exceeded, iptables would block that IP for 20 minutes. Here is what they did: Over 390 unique IPs simultaneously sent email at a gradual rate using 3 sets of compromised credentials. I looked at one IP, and it connected 59 times over 2 hours, sending one recipient per email. If that is indicative, then 59 * 390 = 23128 email. It looks like we need something which limits based on the authenticating sender connection counts, not IP or recipient count.
