On 9/12/2013 9:45 PM, Jorgen Lundman wrote: > > Hello all, > > Talking about the customer outgoing SMTP servers, where customers > connect and are forced to SMTPAuth before they can send mail out to the > Internet. We use LDAP for SMTPAuth verification. > > Occasionally, a customer account is compromised, and used for sending > large volumes of spam. > > We have a system in place that detects this, and immediately sets the > LDAP "accountStatus" to "disabled". > > However, quite often the 3rd party involved uses software that can use > pipelining, and simply keeps sending mail, even though the SMTPAuth > account has been stopped.
It's not pipelining that enables this. It's the fact that, IIRC, Postfix smtpd allows a client to keep sending messages over an open connection for up to 300s by default. > Naturally, we can simply restart Postfix, thereby dropping all > connections and forcing SMTPAuth again. But this is rather undesirable, > and unattractive. Yes, obviously. > Are there other solutions to consider? The quickest and most thorough way to thwart this is to identify the ID of the smtpd process handling the connection, and kill it. I can't tell you how, but maybe Wietse or Viktor can. You might also try, in your working detection script, adding the hijacked account address to an access(5) table and using check_sender_access to reject subsequent submissions until smtpd times out. This would obviously also require an automated process to remove the entry from the access table once the password has been changed and the account re-enabled. There may already exist a policy daemon that might give most of what you seek. Check out postfwd: http://postfwd.org/ At the least it offers per sender rate limiting. You may be able to inject your disabled account address in real time and set the rate to 0. > Can we add something similar to the "smtpd_client_restrictions" or > "smtpd_recipient_restrictions", and adding a new rule-entry which would > simply confirm that the "SMTPAuth LDAP 'user' used way back, is still > accountStatus=enabled" ? > > Or, can we set a maximum limit on number of pipelining emails allowed, > say, 50, that at least we still have the spammers get cut off, but > retain the efficiency of pipelining. > > Should we simply disable pipelining on the SMTP clusters? Customers > "probably" are not negatively affected by this setting. Again, pipelining isn't your problem. It simply allows smtp commands to be grouped together instead of issued serially, but this works only per message, not across a large set of messages. See: http://tools.ietf.org/html/rfc2920#section-3.1 What you seem to be asking for here is a way to limit total messages per session. I'm unable to locate such a restriction. The best I think you can do is limit message rate, which can be done with Postfix, or with postfwd. -- Stan
