Archives par étiquette : postgrey

postgrey et des délais infernaux avec outlook et gmail – parfois

Il se passe parfois un truc pénible avec les serveurs d’envoi de Google et Microsoft, lorsque vous avez mis en place du greylisting, c’est que lorsque l’expéditeur renvoie, il renvoie depuis un autre serveur. Donc ça déclenche une nouvelle temporisation de greylisting car c’est un nouveau triplet expéditeur/destinataire/ip(? pour le 3è param ? je sais plus). Bref, le mail entrant peut être refoulé un paquet de fois avant d’arriver pour de bon, tant leurs serveurs d’envois sont nombreux.

Pour éviter ça, un whitelist au niveau greylisting uniquement s’avère indispensable. Même si le mail envoyé est du spam, de toute manière il arrive avec la bénédiction d’un serveur gmail/microsoft, donc il *finira* par rentrer et c’est l’analyse de contenu éventuellement qui dira si c’est du spam.

Pour ceci, on crée un fichier /etc/postgrey/whitelist_clients.local (.local car il perdura avec les upgrades de paquets) et contenant :

/^mail-.*\.outbound\.protection\.outlook\.com$/
/^mail-.*\.google\.com$/
/^.*\.amazonses\.com$/

Pour la 3è ligne, c’est vous qui voyez, mais j’ai eu le souci avec Amazon, quoique les nuages Amazon soient aussi plus souvent utilisés pour du spam.
La liste de base de /etc/postgrey/whitelist_clients ne me plait pas trop. Sinon on pourrait la compléter et attention aux upgrades.

Ensuite, on indique à postgrey d’en tenir compte (je crois qu’on précise un fichier uniquement, ça ne vient pas en plus du whitelist_clients de base – à confirmer), en modifiant /etc/default/postgrey

POSTGREY_OPTS="--inet=10023 --whitelist-clients=/etc/postgrey/whitelist_clients.local --auto-whitelist-clients=2"

Le paramètre AWL égal à 2 vaut normalement 5 et indique au bout de combien de mails acceptés on auto-whitelist cet expéditeur+serveur.

Montage d’un serveur de mail complet (postfix, postgrey, amavisd-new, clamav, spamassassin etc)

Cet article présente la mise en place complète d’un serveur de mails sous Debian mélangeant les composants suivants : postfix, postgrey, amavisd-new, clamav, spamassassin, razor, pyzor, les règles spamassassin de RulesEmporium et enfin procmail pour délivrer dans des boîtes (ou faire suivre sur un autre backend si c’est votre cas).

Ce type d’installation peut tout à fait convenir pour des petites et moyennes entreprises (quelques centaines de personnes), sur un serveur moyennement puissant. Pour faire simple. Continuer la lecture

Séquence de greylisting

Je suis en train de préparer une doc de mise en place sauce Debian de la fameuse chaîne complète de traitement de mails : postfix + postgrey + amavisd-new + spamassassin + RulesEmporium + clamav. (j’en oublie ? :))
D’ici que la doc soit prête dans sa globalité, j’en profite pour zoomer sur le greylisting (qui en gros, me divise en général par 10 les spams entrants sur un serveur donnée qui ne faisait pas de greylisting). Continuer la lecture

Statistiques de greylisting

Pour ceux qui ne connaissent pas, le « Greylisting » est un mécanisme utile et extrêmement simple à mettre en oeuvre pour réduire significativement le nombre de spams en entrée des serveurs de mails, sans même avoir besoin de les analyser. En gros, vous pouvez diviser par 10 vos mails entrants et le boulot de votre spamassassin, du coup.
Magique ? non, logique.
Je vous propose dans cet article un résultat chiffré sur une installation comptant un backup MX, un frontal (qui encaisse les tentatives d’abus etc + analyse virus) relayant enfin à un serveur final (backend) faisant tourner un bon gros spamassassin/SARE des familles avant la distribution du courrier. Le tout pour desservir 150 utilisateurs et/ou boîtes mails environ (sans compter des vieux comptent qui n’existent plus et que les spammeurs doivent avoir encore « en tête »).
La mise en place du greylisting pour postfix est détaillée dans ma doc, il ne manque qu’une indication : démarrer le service postgrey après installation 🙂 Continuer la lecture