Re: Trouble with MaxSameIpSource

[Matti Aarnio <mea@nic.funet.fi>]

On Wed, Jul 02, 2003 at 01:55:33PM +0400, Eugene Crosser wrote:
> Hello Matti and guys,
> 
> I have some trouble here.  To make our "spam inhibitor" tool efficient,
> I have to set MaxSameIpSource to 1 (or low number).  Now, we have a
> neighbour server that sends to us (quite legitimately) rather high
> traffic.  Plus, this server is apparently unable to do "session reuse".

A qmail ?  Basic design says: send every recipient of every message in
its own SMTP connection..

> First, they used multiple parallel connections, but they got growing
> backlog of deferred messages.  Then they configured their server to only
> open one connection to us.  But as they do not have session reuse, this
> revealed an buglet in Zmailer: after a session ends, the next one from
> the same IP address *still* hits MaxSameIpSource limit for a few seconds
> more, probably because the previous smtpserver process is busy with some
> logging/cleanup.  So, our neghbour still cannot send us messages fast
> enough.
> 
> I am planning to move SameIpSource handling completely into our "spam
> inhibitor", to make it cluster-wide (and set Zmailer's limit to a large
> number), but we cannot do it fast enough.
> 
> On the other hand, it seems only appropriate if Zmailer's
> MaxSameIpSource feature would be per-IPrange-controllable.  I wonder if
> it could be possible to, e.g, combine MaxSameIpSource feature with
> policy's "rejectnet" key, so that the current "rejectnet +" is
> equivalent to newly introduced "maxconnect 0", while "[0.0.0.0]/0
> maxconnect 100" is equivalent to the current default.
> 
> Given that sameipcount is actually checked inside the child, this sould
> not be too hard.  What do you think?  Or maybe some other good advice
> for me?

There is already code to do "policyinsizelimit()" (see  smtpcmds.c,
and  policytest.c), which is very much alike what you want.
You want to add some variable (default value of zero: not set) into
'struct policystate', introduce new attribute, and process it in
IP-address lookups storing received value into that state variable.

I would keep server wide global limits (at some higher levels) that
can then supply safe fallback limits.  They are intended for preventing
several run-away "denial-of-service" kind of overload situations, not
quite what you are looking for.

> Eugene
-- 
/Matti Aarnio	<mea@nic.funet.fi>
-
To unsubscribe from this list: send the line "unsubscribe zmailer" in
the body of a message to majordomo@nic.funet.fi