Re: [sympa-fr] Sympa Vs Greylisting

["Francois Vadrot" <adresse@cachée>]

Merci pour vos réponses,

Entre temps, nous avons modifié le paramétrage de notre mailer, et ça semble 
régler les cas de rejets rencontrés récemment.

François

----- Original Message ----- 
From: "Olivier Fauveaux" <adresse@cachée>
To: "Francois Vadrot" <adresse@cachée>
Cc: <adresse@cachée>
Sent: Wednesday, February 20, 2008 3:32 PM
Subject: Re: [sympa-fr] Sympa Vs Greylisting




Francois Vadrot wrote:

>Bonsoir,
>
>
Bonjour et désolé pour le "off topic" (mais si ça peut aider),

>J'avais plutôt compris que le greylisting demandait à l'émetteur de 
>répondre
>dans un délai très court, faute de quoi il était considéré comme un
>spammeur, caractérisé par le fait qu'en général il ne prend pas la peine de
>répondre rapidement ??
>
>
Non, "caractérisé par le fait qu'en général il ne prend pas la peine de
répondre" tout court, ou justement, certains répondent de suite.
Augmenter les délais sur un système de greylisting permet de temporiser,
le temps que l'IP emmetrice soit inscrite dans des DNS-BL, ce qui permet
ensuite de refuser le mail en s'appuyant sur ces RBL, c'est pour ces
raisons que les délais d'acceptation d'un triplet des systèmes de
greylisting qui étaient au début de cette technique de 5 minutes en
général ont été passés à 20 minutes, voir plus.

>Parce que s'il faut répondre vite, le problème, c'est quand on est sur un
>gros routage (par exemple 20.000 envois de 500 ko), je ne vois pas comme le
>mailer (postfix dans notre cas) peut répondre en quelques minutes à une
>demande de confirmation d'un filtrage en greylisting, sauf peut-être si on
>peut lui mettre en priorité cette tâche, mais alors cela pénalise les 
>autres
>envois en cours.
>
>??
>
>F.
>
>

Il suffit d'avoir des files d'attente suffisamment dimensionnées (espace
disque) et Postfix gèrera très bien la réexpédition.
Sur un Postfix "stock", le délais de réexpédition face à un rejet
temporaire de type greylisting (ou autre) dépend des paramètres
queue_run_delay et minimal_backoff_time.
Suivant les versions de Postfix, les valeurs par défaut sont variables :

Postfix avant 2.4 :
queue_run_delay = 1000s
minimal_backoff_time = 1000s

Postfix 2.4 et après :
queue_run_delay = 300s
minimal_backoff_time = 300s

queue_run_delay correspond à la fréquence de balayage de la queue des
messages "différés".
minimal_backoff_time correspond au temps minimum à laisser le message
dans la queue des messages "différés".

Donc dans le meilleur des cas, un mail est réexpédié après 300 secondes
(5 minutes) pour un Postfix V2.4 et supérieur, et 1000 secondes (+ de 16
minutes) sur un Postfix antérieur à V2.4.
Dans le pire des cas, ces délais sont multipliés par deux.

On pourrait donc être tenté de réduire de manière significative ces
valeurs, mais il faut s'attendre dans ce cas à un effet contraire à
celui souhaité :
Les systèmes de greylisting sont configurables au niveau du délai
souhaité pour accepter un triplet après la première connexion, si le
triplet est de retour trop tôt, la connexion est de nouveau rejetée.
Le serveur "client" garde donc le mail en file d'attente, dans le cas de
Postfix, pour chaque rejet temporaire d'un même mail les tentatives pour
l'expédier de nouveau seront de plus en plus espacées, c'est propre à
Postfix et normal, cela permet de diminuer les sollicitations d'un
serveur distant qui aurait un problème de charge, de configuration, ou
autre....Le délai maximum entre les tentatives de réexpédition est
limité par le paramètre maximal_backoff_time (par défaut 4000s ).


Il faut donc trouver le réglage pour ne pas ré-expédier trop tôt, et
pour ré-expédier dans des délais "acceptable" pour les utilisateurs...
Les valeurs par défaut des Postfix récents sont certainement un bon
compromis.


Cdlt.


-- 
Olivier Fauveaux
Rectorat de Versailles