Yahoo Groups archive

Milter-greylist

Index last updated: 2026-04-28 23:32 UTC

Thread

ratelimit feature mx sync

ratelimit feature mx sync

2013-02-01 by Juan Carlos Sanchez

Hello:

I am using ratelimit feature to try to limit the amount of recipients a user may send (and this way trying to minimize spam sent through compromised accounts)

Our mail service is separated in two servers under a hardware balancer, and both servers are MX Sync'ed under milter-greylist config file.

But it looks like info about recipients sent by a user is not shared between servers, unless until the limit is reached in one of them.

I'd like to fix 500 recipients / day in both servers and apply blacklist in case the users sends more than 500 recipients adding both balanced servers
¿Is this possible? ¿maybe I'm doing sth. wrong?


A piece of my config (same in both servers):

-------------
peer xxx.xxx.xxx.xxx

list "testingip" addr { \
\
}

ratelimit "redrcpt" rcpt 500 / 1d key "%f%i"
racl blacklist list "testingip" ratelimit "redrcpt" msg "You have exceeded the number of messages per day limit"
--------------------


Thanks in advance.

Best regards.







-- 

------------------------------------------------------
Juan Carlos Sanchez Hernandez
Responsable de  Seguridad y Correo Electronico
Servicio de Planificacion Informatica y Comunicaciones
Universidad Politecnica de Madrid
Rectorado
Avda. Ramiro de Maeztu 7
28040 Madrid
------------------------------------------------------

Re: [milter-greylist] ratelimit feature mx sync

2013-02-01 by manu@...

Juan Carlos Sanchez <juancarlos.sanchez@...> wrote:

> I am using ratelimit feature to try to limit the amount of recipients a
> user may send (and this way trying to minimize spam sent through 
> compromised accounts)
> 
> Our mail service is separated in two servers under a hardware balancer,
> and both servers are MX Sync'ed under milter-greylist config file.
> 
> But it looks like info about recipients sent by a user is not shared 
> between servers, unless until the limit is reached in one of them.

Yes, I never implemented it because I never really hit a real problem
with the lack of MX ratelimit sync. Do you experience spammers that
cleverly distribute the load on your MX in order to evade ratelimit?

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

Re: [milter-greylist] ratelimit feature mx sync

2013-02-01 by JUAN CARLOS SANCHEZ HERNANDEZ

El 2013-02-01 20:15, manu@... escribi�:
>
>  Yes, I never implemented it because I never really hit a real 
> problem
>  with the lack of MX ratelimit sync. Do you experience spammers that
>  cleverly distribute the load on your MX in order to evade ratelimit?

Not. Really it is working since yesterday, so haven't still background 
enough, but the default politic in load balancer is to share the load 
between both servers, so around 50% of message goes to each servers, but 
is not perfect; and cannot be guaranteed for an individual user 
messages.

Ratelimit is implemented in our outgoing mail servers (for incoming 
mail we are using milter-greylist for some years with great results in 
another servers), so I'd like to say our users *exactly* how many 
recipients they can send messages each day.

Let's suppose a limit of 1000 is specified and publised in internal 
mail "Terms of use". In normal work, I can specify a ratelimit of 500 in 
each server and the global limit will be more or less accomplished (not 
perfectly, as the load balance is not). But if a server crashes or is 
put offline for update/upgrade, the limit will be 500, too far of the 
specified limit.

Hope I have explained well enough (not English native speaker; 
greatings from Spain)


>
>  --
>  Emmanuel Dreyfus
>  http://hcpnet.free.fr/pubz [1]
>  manu@...
>
> 
>
> Links:
> ------
> [1] http://hcpnet.free.fr/pubz
> [2]
> 
> http://groups.yahoo.com/group/milter-greylist/post;_ylc=X3oDMTJxY2I2MGFhBF9TAzk3MzU5NzE0BGdycElkAzEyNzYzNTQ2BGdycHNwSWQDMTcwNzI4MTk0MgRtc2dJZAM2MDY5BHNlYwNmdHIEc2xrA3JwbHkEc3RpbWUDMTM1OTc0NTY0OQ--?act=reply&messageNum=6069
> [3]
> 
> http://groups.yahoo.com/group/milter-greylist/post;_ylc=X3oDMTJmYmF2ZnNmBF9TAzk3MzU5NzE0BGdycElkAzEyNzYzNTQ2BGdycHNwSWQDMTcwNzI4MTk0MgRzZWMDZnRyBHNsawNudHBjBHN0aW1lAzEzNTk3NDU2NDk-
> [4]
> 
> http://groups.yahoo.com/group/milter-greylist/message/6068;_ylc=X3oDMTM1cW1nOWgzBF9TAzk3MzU5NzE0BGdycElkAzEyNzYzNTQ2BGdycHNwSWQDMTcwNzI4MTk0MgRtc2dJZAM2MDY5BHNlYwNmdHIEc2xrA3Z0cGMEc3RpbWUDMTM1OTc0NTY0OQR0cGNJZAM2MDY4
> [5]
> 
> http://groups.yahoo.com/group/milter-greylist/members;_ylc=X3oDMTJndjNuZXVpBF9TAzk3MzU5NzE0BGdycElkAzEyNzYzNTQ2BGdycHNwSWQDMTcwNzI4MTk0MgRzZWMDdnRsBHNsawN2bWJycwRzdGltZQMxMzU5NzQ1NjQ5?o=6
> [6]
> 
> http://groups.yahoo.com/group/milter-greylist;_ylc=X3oDMTJmczhhbmRzBF9TAzk3MzU5NzE0BGdycElkAzEyNzYzNTQ2BGdycHNwSWQDMTcwNzI4MTk0MgRzZWMDdnRsBHNsawN2Z2hwBHN0aW1lAzEzNTk3NDU2NDk-
> [7]
> 
> http://groups.yahoo.com/;_ylc=X3oDMTJlMHBmZjlyBF9TAzk3MzU5NzE0BGdycElkAzEyNzYzNTQ2BGdycHNwSWQDMTcwNzI4MTk0MgRzZWMDZnRyBHNsawNnZnAEc3RpbWUDMTM1OTc0NTY0OQ--
> [8] http://docs.yahoo.com/info/terms/

-- 
JUAN CARLOS SANCHEZ HERNANDEZ
Universidad Politecnica de Madrid

Re: [milter-greylist] ratelimit feature mx sync

2013-02-02 by manu@...

JUAN CARLOS SANCHEZ HERNANDEZ <juancarlos.sanchez@...> wrote:

> Let's suppose a limit of 1000 is specified and publised in internal 
> mail "Terms of use". In normal work, I can specify a ratelimit of 500 in
> each server and the global limit will be more or less accomplished (not
> perfectly, as the load balance is not). But if a server crashes or is
> put offline for update/upgrade, the limit will be 500, too far of the
> specified limit.

Right, so this is more a billing problem than a spam problem. 

I'll take patch for the feature you request, but I am not going to
implement it on my own.At least not until I hit a spam problem :-)

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

Re: [milter-greylist] ratelimit feature mx sync

2013-02-02 by JUAN CARLOS SANCHEZ HERNANDEZ

El 2013-02-02 03:04, manu@... escribi�:
> JUAN CARLOS SANCHEZ HERNANDEZ juancarlos.sanchez@...> wrote:
>
>  > Let's suppose a limit of 1000 is specified and publised in 
> internal
>  > mail "Terms of use". In normal work, I can specify a ratelimit of 
> 500 in
>  > each server and the global limit will be more or less accomplished 
> (not
>  > perfectly, as the load balance is not). But if a server crashes or 
> is
>  > put offline for update/upgrade, the limit will be 500, too far of 
> the
>  > specified limit.
>
>  Right, so this is more a billing problem than a spam problem.
>
>  I'll take patch for the feature you request, but I am not going to
>  implement it on my own.At least not until I hit a spam problem :-)
>

Thanks for your reply.

Well, it may look like a billing problem, but I have come to this 
because of a spam problem. Never had though to have to put a limit to 
recipients but in last 2 months we have had a lot of user accounts 
compromised (people replying to forged "out of quota" messages and stuff 
like that) that have been used to send a lot of spam. And as the source 
IP of spam has usually been located in other countries,  have used 
ratelimit combined with geoip to impose ratelimit to messages whose 
sender IP is located in another country (no limit by now for users in my 
country) and webmail users.

Best Regards.

Re: [milter-greylist] ratelimit feature mx sync

2013-02-03 by manu@...

JUAN CARLOS SANCHEZ HERNANDEZ <juancarlos.sanchez@...> wrote:

> Well, it may look like a billing problem, but I have come to this 
> because of a spam problem. Never had though to have to put a limit to
> recipients but in last 2 months we have had a lot of user accounts 
> compromised (people replying to forged "out of quota" messages and stuff
> like that) that have been used to send a lot of spam. 

This is for this exact situation I implemented ratelimit, but the lack
of MX sync is not a problem, since spammers are quite rough for now when
hijacking accounts: they send 150k message per hour, and therefore even
a high limit catch them.

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.