Rspamd et ratelimit

Support Debian
#1

Hello,

Je souhaite mettre en place un ratelimit pour mes utilisateurs, en utilisant le module ratelimit offert par Rspamd.

Alors, j’ai plus ou moins accouché de cette conf, mais je ne suis pas sûre de tout bien comprendre. En anglais, les commentaires originaux et en français, ce que j’ai moi appliqué, avec les effets que cela semble avoir :

rates {
  # Limite pour tous les mails par recipient (3 par minute)
  to = "3 / 1m";
  # Limite pour tous les mails depuis une même ip (5 par minute)
  to_ip = "5 / 1m";
  # Limit for all mail per one source ip and from address (rate 2 per minute)
#  to_ip_from = "2 / 1m";
  # Limit for all bounce mail (rate 2 per hour)
#  bounce_to = "2 / 1h";
  # Limit for bounce mail per one source ip (rate 1 per hour)
#  bounce_to_ip = "1 / 1h";
  # Utilisateurs exterieurs ne peuvent envoyer +4 mails / minute pour un destinataire hébergé chez moi
  user = "4 / 1m";
}

# On fait sauter cette limite si les destinataires sont en copie
whitelisted_rcpts = "postmaster,mailer-daemon";
max_rcpt = 5;

Alors ça marche plus ou moins, avec des effets pas forcément bien maîtrisés…

Par exemple lorsque j’envoi plus de 3 mails par minute depuis l’extérieur depuis une même adresse, vers une adresse que j’héberge, les mails au delà des 3 dans la même minute passent en soft reject. Et ils sont visiblement réexpédiés plus tard (mais là aussi, je ne sais pas quel mécanisme gère la réexpédition : est-ce MON postfix, où est-ce le serveur d’envoi distant qui refait un essai ?).

Bref, pourriez-vous m’aider à comprendre ces différentes options parce-que la doc officielle, là pour le coup, j’ai du mal de la saisir. On y parle de limit, mais limit de quoi ? Mails envoyés/reçus ? Patates ? carottes ? Je cite le passage intéressant d’ailleurs :

  • bounce_to : limit bounces per recipient
  • bounce_to_ip : limit bounces per recipient per ip
  • to : limit per recipient
  • to_ip : limit per pair of recipient and sender’s IP address
  • to_ip_from : limit per triplet: recipient, sender’s envelope from and sender’s IP
  • user : limit per authenticated user (useful for outbound limits)

Mon objectif est simple :

Je veux qu’un utilisateur ne puisse pas envoyer plus de 3 mails par minute à n’importe qui. Sauf dans le cas où le mail envoyé dépasse les 4 utilisateurs en copie.

Ce qui vient de l’extérieur, je m’en fiche, postscreen + rspamd feront déjà le boulot, après si les mails sont légitimes, mon serveur fera le boulot.

/edit : visiblement, ce que je veux faire passe simplement par la clause user. Mais j’aimerais quand même bien comprendre le sens des autres clauses.

#2

Réponse de moi à moi, puisqu’un de mes users vient de se faire pirater sa boîte, ce qui m’a valu un blacklistage temporaire sur le RBL de Barracuda. Voilà ce que c’est que de remettre un problème à « plus tard »…

Donc j’ai repris le sujet et suis parti de zéro en jetant aussi un oeil ici : https://www.onooks.com/understanding-rspamd-ratelimit/

Si on reprend sa conf :

rates {
spambombing_limit = {
selector = ‹ user.lower ›;
bucket = [
{
burst = 30;
rate = « 30 / 1min »;
}]
}
}

Dans les logs, notre copain rspamd nous dit ceci :

lua; ratelimit.lua:786: enabled ratelimit: spambombing_limit [30 msgs burst, 0.5 msgs/sec rate]

Au final c’est assez simple : Si un utilisateur envoie plus de 30 mails, il déclenche le ratelimit qui va lui refuser un rate au delà d’un envoie de plus de 30 mails par minutes. Il s’agira d’un soft reject renvoyé par son client mail.

De cette façon, si un user se retrouve vérolé, ce mécanisme vous empêchera de vous retrouver trop rapidement blacklisté un peu partout.

Attention, cette conf est vraiment basique, elle mérite sans doute un peu de tuning (je pense à des whitelist).

#3
  • bounce_to : limit bounces per recipient => Limite de rebond par destinatire
  • bounce_to_ip : limit bounces per recipient per ip => limite de rebond par destinataire et par ip
  • to : limit per recipient = > limite par destinataire
  • to_ip : limit per pair of recipient and sender’s IP address => limite par paire d’IP de destinataire/emetteur
  • to_ip_from : limit per triplet: recipient, sender’s envelope from and sender’s IP => limite par triplet IP destinataire/IP de l’enveloppe emetteur/IP de l’emetteur
  • user : limit per authenticated user (useful for outbound limits) => limite par utilisateur authentifié
1 J'aime
#4

Il faudrait que j’arrive à différencier celui qui envoie 30 mails différents en une minute de celui qui envoie un mail à 30 personnes en copie, en une minute.

C’est là le problème de ma conf, car je n’arrive pas à faire la différence entre les deux, elle est pourtant capitale.

Car autant un envoi à 30 personnes en copie, c’est tout à fait normal. Autant, l’envoi de 30 mails (différents ou non d’ailleurs) à une personne à chaque fois là, en une minute, là c’est tout de suite suspect.

Une idée ? Paracerque même en traduisant, j’avoue ne pas y voir plus clair. Il faudrait des exemples concrets avec la doc.

#5

A priori, 30 mails à des destinataires différents, l’expéditeur va s’authentifier 30 fois.
Pour un mail à 30 personnes, l’expéditeur ne s’authentifie qu’une seule fois. Donc ce serait user

#6

Attention bounce ne signifie pas rebond dans ce contexte mais plutôt notification de rejet.

Quand tu envoies un courriel à machin@example.com et que cette adresse n’existe pas , le serveur example.com va envoyer une notification de rejet (bounce) à l’adresse trouvée dans le Return-path.

Je ne connais pas cette partie de la doc de Rspamd mais je comprends bounce_to comme une possibilité de limiter le nombre de notification de rejet envoyées à un destinataire. Mais je peux me tromper…

#7

Je me demande si je ne vais pas demander directement une explication avec exemples au développeur. Cette feature me parait tellement puissante qu’il serait dommage de ne pas pouvoir en profiter comme il faut.

#8

Non.
Lorsqu’un utilisateur s’authentifie il le reste pendant un certain temps. Heureusement il n’a pas besoin de s’authentifier à nouveau à chaque courriel envoyé ou consulté. Le client peut même rester connecté indéfiniment tant qu’il envoie des requêtes au serveur.

Sauf erreur de ma part, cela ne fait aucune différence. Le MTA va de toute façon envoyer 30 courriels à différents destinataires. Pour Postfix c’est le démon cleanup qui va interpréter les TO, CC et BCC pour finalement envoyer 30 messages différents vers la file d’attente. Et a priori les milters, donc rspamd, traitent les courriels après cleanup.