Bonjour faux rhum,
J'ai un serveur dont le rôle est (entre autres) d'intercepter les connexions SMTP sortantes des utilisateurs, et qui fait tourner un Postfix pour ensuite relayer les mails vers leur destination.
Le but est de permettre à ces utilisateurs d'envoyer des mail, mais d'appliquer un filtrage anti-spam pour éviter que l'adresse IP se trouve blacklistée.
Il y a déjà des limites configurées dans Postfix pour restreindre le nombre de mails et de destinataires pour une période de temps donnée. Cependant, ces limites (que je ne peux pas abaisser, sinon elles bloqueront le trafic légitime) font que tous les processus spamd (spamassassin) sont parfois utilisés et les messages en trop passent à travers les mailles du filet.
Une idée de restriction à laquelle j'ai pensé est de limiter pour une adresse IP donnée le nombre d'adresse mail source qu'elle peut utiliser (un client légitime n'utilisera jamais plus de 2 adresses mail sources différentes). Cela aurait pour effet de soulager l'utilisation des processus spamd.
J'ai bien cherché dans la doc de Postfix, celle de postfwd, mais je n'ai pas trouvé comment implémenté un tel filtre.
Quelqu'un a une idée de la marche à suivre pour atteindre ce but ?
Merci d'avance.
# un bout de solution
Posté par NeoX . Évalué à 4.
ben augmente les capacités allouées à spamassassin, ou configure le comme il faut comme ca il ne laissera pas filer les emails non scannés
sinon, ben il te faut coder un smtp, qui va decouper ton email en plusieurs morceaux et les traiter separement
[^] # Re: un bout de solution
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 4.
C'est une blague ?
J'espère que spamassassin est un processus muni d'une queue, sinon, il suffirait en gros d'envoyer plus de mails d'un coup qu'il y a de processus spamd pour garantir qu'un mail ne sera pas traité par l'antispam ! Et ça, je doute que ce soit le cas…
[^] # Re: un bout de solution
Posté par Xavier Maillard . Évalué à 2.
Avec dspam, j'ai un problème qui ressemble; si le processus qui qualifie le message -i.e. spam ou non - met trop de temps à repondre, le mail est tout de même délivré sans l'étiquette "spam" ou "ham".
J'ai partiellement résolu ce problème en déportant la charge SGBD sur une autre machine et je n'ai plus le problème.
[^] # Re: un bout de solution
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 3.
Euh, je te suggère de changer de logiciel alors.
C'est un comportement que je trouve inacceptable !
T'imagines un antivirus qui dit "oh, vous faites chier, le fichier est trop gros, je le scanne pas" ? ou « y a trop de fichiers, alors on va dire qu'ils sont tous clean » ?
[^] # Re: un bout de solution
Posté par Xavier Maillard . Évalué à 2.
Hum je ne pense pas que dspam soit fautif (ni même le MTA) tout simplement un problème de configuration (un timeout à modifier). J'ai préféré changer mon architecture plutôt que passer en mode "trial and error" pour trouver les bonnes valeurs pour les timeout (et/ou le pool de connexions au SGBD).
[^] # Re: un bout de solution
Posté par N-Mi . Évalué à 1.
J'ai déjà passé le nombre de processus spamd de 5 à 10. Mais comme tu l'indiques, il suffit d'envoyer plus de mails que ce que peut traiter le serveur pour contourner le filtre anti-spam.
Postfix utilise un pool de processus spamd pour faire mouliner les mails. D'après ce que j'ai vu c'est le mécanisme habituel, mais je n'ai pas encore fouillé assez pour savoir s'il est possible de mettre les mails dans une queue. Mais cela pourrait ralentir considérablement le délai de livraison des mails.
Je ne peux pas changer la politique par défaut pour refuser les mails non scannés. En effet, je dois éviter le plus possible de passer à la trappe des mails légitimes (clients business, donc potentiellement susceptibles et exigeant un service mail fonctionnel). De plus, un tel changement ferait qu'un PC infecté envoyant une grosse quantité de spam ferait un dénis de service aux autres utilisateurs légitime du réseau (dont les mails qui n'ont pu être scannés seraient droppés). Le but est donc d'appliquer la restriction en amont de l'anti-spam qui est coûteux.
Merci.
[^] # Re: un bout de solution
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 3.
Change de logiciel alors. Un filtre qui ne filtre pas, c'est inutile.
Ça tombe bien, la délivrance d'emails est asynchrone est non-garantie : un email peut mettre deux jours pour arriver, ou même ne jamais arriver, et ça serait complétement normal et acceptable.
Si tu as des contraintes plus fortes en terme de délais et garantie de livraison, il te faut un autre moyen de communication. Va jeter un œil aux solutions comme AMQP par exemple.
# utilise postfwd
Posté par zozo . Évalué à 3.
Il offre plein de solution pour limiter le nombre d'envois par heure
http://postfwd.org/ je l'utilise depuis plusieurs années, il marche trés bien
[^] # Re: utilise postfwd
Posté par N-Mi . Évalué à 1.
Justement, j'ai jeté un coup d'oeil à la doc de postfwd, mais j'ai pas trouvé comment limiter le nombre d'adresse mail source par IP.
Si tu as une suggestion pour la règle à écrire, je t'en serais très reconnaissant.
[^] # Re: utilise postfwd
Posté par zozo . Évalué à 1.
voici un exemple
je suis pas sur qu'il corresponde
on gros je limite le nombre de mail, un mail avec deux adresse (êgale 2 mailz)
id=RATE01 ; protocol_state==RCPT ; action==rate($$client_address/560/21600/521 Levez les mains de votre clavier vous avez depasse le quota de 450 mails par 6 heures, vous avez un gage!) id=SIZE01 ; protocol_state==END_OF_DATA ; action==size($$client_address/15728640/600/521 Vous envoyez des messages trop gros)
# Identification SASL plus vérification
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Puisque ton serveur sert en somme de relais, à ta place, je ferais plutôt de l'identification SASL obligatoire. À partir de là, on peut vérifier la correspondance entre le login SASL et l'adresse d'expéditeur, et refuser le message sinon.
[^] # Re: Identification SASL plus vérification
Posté par N-Mi . Évalué à 0.
Impossible de mettre un mécanisme d'authentification, je n'ai pas la possibilité d'imposer quoi que ce soit au niveau de la configuration des clients. C'est un serveur SMTP qui se trouve entre des hotspots wifi et internet.
# Solution
Posté par N-Mi . Évalué à 0.
Au cas où quelqu'un passerait dans le coin et trouverait cette entrée du forum, voici la solution que j'ai finalement retenue.
Comme je n'ai pas trouvé de mécanisme dans postfix pour limiter le nombre de connexions par IP, j'ai regardé du côté de Netfilter et c'est là que j'ai trouvé mon bonheur, à savoir le module ipt_recent.
Ce module me permet de compter le nombre d'établissement de session dans la table conntrack, et d'activer une règle si une même adresse IP la déclenche un certain nombre de fois dans un intervalle donné.
Voici donc l'ensemble de règles que j'ai appliquées :
Traduction : - je jette tous les paquets initiant une connexion vers le port 25 d'une machine autre que mon serveur, si l'adresse source a initié plus de 3 connexions en 10 secondes (compteur "spammer") - toutes les nouvelles connexions vers le port 25 à destination d'une IP autre que le serveur incrémentent le compteur "spammer" - les paquets vers le port 25 sont redirigés vers le Postfix en local, qui appliquera maintenant tranquillement le filtre anti-spam sans être surchargé.
Merci à tous pour les suggestions.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.