Qmail devient joum !

[Plog]

J'ai un utilisateur qui envoi une Newsletter à beaucoup de monde.

L'un des serveurs mails de destination (skynet pour ne pas le citer) me renvoi constamment à la gare avec le message suivant

delivery 510: deferral: 195.238.5.129_does_not_like_recipient./Remote_host_said:_452_Too_many_recipients_received_this_hour/Giving_up_on_195.238.5.129./

Je les ai appelé et il m'ont dit que mon serveur faisait trop de connexion simultanées. Ils n'autoriseraient qu'une connexion par seconde...

Je ne trouve rien sur Google. La seule chose que j'ai trouvée c'est le fichier /var/qmail/control/concurrencyremote

Mais rien ne permet de "limiter le nombre de connexions/seconde"...


J'ai ma pile de mail qui grossi à tout allure...


Une idée ?

[MasterSleepy]

Salut,

Ton FAI est Skynet je suppose?
Essaye de paramétrer la déléguation du serveur de mail vers skynet.
http://www.smeserver.fr/manager.php#courrier.

A+,
MasterSleepy.
http://www.vanhees.cc
Index des contribs pour SmeServer

[Plog]

Malheureusement non, nous sommes chez OVH.

Quand je met 1 dans /var/qmail/control/concurrencyremote les mails arrivent chez Skynet mais si je fais ça ma pile va mettre 2 siècles à se vider.

J'ai demandé à OVH si on pouvait utiliser leur SMTP, j'attends leur réponse. J'imagine qu'ils ont déjà dû avoir ce genre de problème et sont certainement plus qualifiés que nous (j'espère)

J'ai parcouru tous les forum possibles et imaginables et je suis tombé sur un thread.
Ils n'avaient pas de solution sinon un patch Qmail (avec recompilation et tout et tout)
Autant dire que je vais pas recompiler Qmail en prod....

Dans ce thread ils se plaignaient de la stupidité de limiter le nombre de connexions/seconde.
Les spammeurs utilise des PC zombies donc des centaines d'adresses IP différentes, c'est pas en limitant les connexions /sec qu'ils vont arranger quoi que ce soit


C'est l'impasse....

[tomtom]

Avec limit sur les paquets syn vers le serveur de mails, dans netfilter, ça doit pouvoir se faire....

Regarde la doc iptables et netfilter sur le module limit, ou hashlimit....



t.

[Plog]

Merci de ton aide, je regarde ça

[Plog]

J'ai trouvé deux références intéressantes :

Ceci s'applique aux paquets ICMP mais devrait pouvoir être utile : http://linuxzoo.net/mc/quiz.cgi/sa-14.html
et
http://radagast.bglug.ca/linux/packet_f ... rewall.pdf

Limits
The limit match extension allows a match against the rate
at which the firewall receives packets. For instance, the
rule

Code: Tout sélectionner

iptables -A INPUT -m limit –limit 1/second -p TCP -dport 80-j ACCEPT

accepts one http packet per second. The limit module also
understands “/minute”, “/hour”, and “/day”. We can also
specify a burst-limit match, for instance

Code: Tout sélectionner

iptables -A INPUT -m limit –limit 1/second –limit-burst 5 -p TCP -dport 80 -j ACCEPT

accepts up to five http packets in the first second, then one packet per second after that.

Tout ça en réception... moi c'est en sortie ..à suivre

[tomtom]

En sortie ca marche pareil....

A toi de voir comment tu veux monter la chose.
Il faudra voir aussi comment se comporte qmail quand les paquets seront dropés

Et pense à ne mettre la limite que sur le flag syn (nombre de connexions qui s'etablissent), car le but n'est pas de limiter les connexions établies...

t.

[Plog]

Code: Tout sélectionner

iptables -t filter -A FORWARD -p tcp --destination-port 25 -d 195.238.5.129 -m limit --limit 1/second -j ACCEPT

.....


non non ce qui est ci-dessus est pas bon

[tomtom]

Déja, il faut le faire sur la chiane OUTPUT et non forward a priori.

Ensuite, regarde mon message au dessus, il faut bien filtrer sur les paquets SYN pour ne gérer que les connexiosn quand elles s'etablissent.

Enfin, connaissant SME, il serait judicieux de regarder dans quel template est faite la règle qui permet l'envoi de mails et de la modifier en conséquence plutot que d'ajouter cette règle comme un barbare


a+

t.

[jibe]

Salut,

Enfin, connaissant SME, il serait judicieux de regarder dans quel template est faite la règle qui permet l'envoi de mails et de la modifier en conséquence plutot que d'ajouter cette règle comme un barbare

Remarque ô combien pertinente !

Simplement, on peut oublier pendant la mise au point : les règles resteront valides jusqu'au prochain signal ip-change (il y en a aussi quelques autres, comme bien sûr expand-templates). Ca permet de faire des essais sans trop se casser la tête avec les templates dont chaque modif doit être suivie d'un signal-event expand-templates pour être prise en compte.

Mais il est bien évident qu'il est indispensable de passer par les templates une fois la mise au point terminée, Il était bon de le rappeler

[Plog]

Je n'oublierai pas les templates promis !

Je pense que j'ai une piste

iptables -A OUTPUT -p tcp --syn -d 195.238.5.129 -m limit --limit 1/second -j ACCEPT

Tant que je vous ai, vou connaissez le meilleurs endroit pour mettre une règle de ce genre ?

dans /etc/e-smith/templates/etc/rc.d/init.d/masq/ y a plein de trucs ....

[Plog]

85PolicyOutput ?


expand-template /etc/rc.d/init.d/masq
service masq restart


c'est ça ?

[Gaston]

Bonsoir,
ça va être une bataille de cuisine ça, je verrai ça plus dans un 42SetupSMTPSyn
et d'après le guide de dev, il semble qu'un

Code: Tout sélectionner

signal-event remoteaccess-update

soit de rigueur

G.

[Plog]

iptables -A OUTPUT -p tcp --syn -d 195.238.5.129 -m limit --limit 1/second -j ACCEPT

Ne semble faire aucun effet et ni hashlimit ni dstlimit ne semble supporté par SME

Skynet ! Grrrrrrr

"La vie est une dure lutte"

[tomtom]

Ce n'ets pas anormal que ca ne fasse aucun effet !


Il existe sans doute deja dans la SME une règle qui te permet d'accepter tout ce qui sort, ou au moins ce qui sort sur le port 25 pour relayer des mails !


Il faut donc que tu identifies cette règle (c'est peut-etre la policy) et que tu l'adaptes.

Il faut :

- Que tu acceptes que les paquets sorttent vers le serveur de mail dans la limite de 1/s (pense au limit burst aussi, qui autorise par défaut 5 connexions avant d'appliquer la limite).
- Que tu dropes tout le reste après


Si ta policy sortante est ACCEPT (assez souvent sur OUTPUT), il faut spécifier la règle de drop à la main.

Le principe de limit, c'est que quadn la limite ets atteinte la règle est ignorée et on passe à la suivante.
L'ordre est important dans netfilter !

Simplement, on peut oublier pendant la mise au point : les règles resteront valides jusqu'au prochain signal ip-change

Tout à fait d'accord, à condition de faire des tests en mettant la règle au bon endroit et en tenant compte de l'ordre


t.