Andrew McGill wrote:
> On Tuesday 21 October 2008 10:44:30 Graeme Fowler wrote:
>> Wow, what a lot of ratelimit questions we suddenly have :)
>>
>> On Tue, 2008-10-21 at 09:54 +0200, Andrew McGill wrote:
>>> I know that exim can control the incoming rate quite easily, but we would
>>> like to rate limit the *outgoing* RCPT TO: rate per authentication source
>>> when processing the queue, without limiting the incoming mail rate.
>> You need something like this in the global settings:
>>
>> acl_not_smtp = acl_check_notsmtp
>>
>>
>> ...and then something like this:
>>
>> acl_check_notsmtp:
>>
>> # You need a way to identify the sending user
>> # This is NOT the "MAIL FROM" necessarily, nor the From:
>> # If using Horde/IMP you should have a Received line of the form
>> # Received: from host.domain (host.domain [1.2.3.4])
>> # by your_mail_server (IMP) with HTTP
>> # for <sending_user@localhost>; Tue, 21 Oct 2008 09:36:46 +0100
>> # From this you can glean the originating user
>>
>> ...snip other bits of the ACL...
>>
>> ## Stick the user in $acl_m0
>> warn set acl_m0 = ${if match{$h_Received:}\
>> {\N.+<([^>@]+)@localhost>;\N}\
>> {$1}\
>> {}\
>> }
>>
>> ## At this point $acl_m0 contains the sending username
>> warn ratelimit = 200 / 1d / leaky / user-$acl_m0
>> control = freeze
>> log_message = Frozen by ACL - exceeded ratelimit - \
>> $sender_rate/$sender_rate_period (User:$acl_m0)
>>
>> accept
>>
>>
>> [Thanks to Mike Cardwell, also of this parish, for most of that]
>>
>> Note that snippet isn't counting RCPTs, because in the not_smtp phase
>> there are no RCPT TO commands - it's not SMTP, see? It's counting
>> messages but it should give you a base to work from.
> Thanks Graeme - this does look hopeful - although some of the people we are
> trying to not to frustrate turn out to be hardened spammers, who won't be shy
> to send 1 mail to 10000 recipients. We'll need a few more measures that
> this.
>
> I guess exim can't really do outgoing rate throttling then :(
>
> &:-)
>
Well ... Exim won't slink in, lick your nether parts, and VOLUNTEER to
do complex ratelimiting..
... But if you'll take the time to tell it what you want, it can
ratelimit as well as any.
As to the 'other measures'. Life - and rulesets - can be made a good
deal simpler if you insure that Exim is not even asked to handle
'non-smtp' traffic on the server running the MTA.
That because if 'non-smtp' traffic can 'exist' to be presented to Exim,
it can just as easily *bypass* exim - eg by running its own outbound
smtp daemon on a non-privileged port.
So:
- No 'shell' accounts, except your sysadmins. All others 'virtual'
- No scripts that can send by invoking a binary. Webishness goes on some
other box. Or at least in a jail or VDM and separate IP.
- An MLM (if you use one) that communicates via a restricted smtp
session, not by stuffing the queue or calling the Exim binary.
- Same again for a Webmail interface. No shell accounts save the
'runner' = no 'non-smtp' session capability.
Once you have those, and all Exim's traffic *must* come in as smtp (and
AUTH'ed if users), you have the whole toolset, not just ratelimiting.
You may then:
- limit connections from a given IP
- limit number of recipients per message (and by user if you chose)
- apply 'delay' and 'defer' creatively, so as to be invisible to a user
sending to ten recipients, hardly noticed at fifty, but deadly to one
sending to a thousand. Or those who have been caught misbehaving.
- optionally scan MLM and user outbound traffic for WinCrobes or spam.
- apply a whole nation of white/grey/black lists and/or conditionals to
decide what is to be done, with which, when, and to whom.
The limitations are not in Exim. They're between an admin's ears.
YMMV,
Bill
