On Mon, Apr 04, 2011 at 12:49:07PM -0400, Bailey, Damian S. wrote:
> Our school district has been using a Postfix/Amavis/SpamAssassin config
> for over a year now with good results. Just recently, however, I've
> noticed that my mail filtering box has been hit by a spammer that uses a
> handful of email addresses to send mail to all legitimate senders in our
> domain. This caused my filter to queue up mail into the 1700+ range,
> effectively delaying mail delivery.
Perhaps you can re-tune the filter to reduce per-message latency, remote
DNS lookups in the filter, ... have a high cost under load.
> We already reject mail going to undeliverable recipients by querying
> LDAP via a perl script.
Can you elaborate on this? Do you mean that you build snapshot tables
from LDAP and use these to reject invalid recipients before mail is
queued?
> Granted, all the mail in question was dumped as spam, but it still
> caused mail to be delayed. Is there a way in Postfix that I can flag or
> alert if a certain sender is attempting to send more than X emails in a
> certain time?
A policy service should be able to do this. Look on the add-ons page:
http://www.postfix.org/addon.html#policy
This is most appropriate for authenticated submission users, but more
risky for the main SMTP port, as there may well be legitimate reasons
for a single sender to send mail to large number of users.
> For instance, say we have 500 employees with email accounts. If I have
> a single sender that sends to more than 200 of them, I would want to
> review it as a possible spamming attack.
If you only want to protect your filter capacity, you can count messages
instead of recipients, and return 421 when a sender reaches a message
rate limit. Alternatively, the policy service can put all mail from
that sender in the "hold" queue, but then you need a process whereby
such mail is reviewed and either released, or deleted.
In general, I don't recommend rate limits, they unnecessarily penalize
legitimate senders of email. It is better to improve spam filtering
with well chosen RBLs, postscreen, ...
--
Viktor.
