Archives de catégorie : mails

Client mails, serveurs de mails, greylisting, spam etc.

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.

Migration courier-imap => dovecot

dovecotLogo

C’est quoi ça encore ?

Dans des articles précédents, je montre comment se monter un serveur de mails assez complet sous Debian. Mais un choix fait il y a fort longtemps, le choix de courier-imap et courier-pop comme brique gérant l’IMAP et le POP, n’avait pas été bien réfléchi et il se trouve que courier-* manque de fonctions, notamment la prise en charge du protocole SIEVE, permettant du tri de mails en amont, sur le serveur.
Après un peu d’utilisation, il y a aussi d’autres petites choses qui se passent mieux avec dovecot plutôt que courier-*. Bref, autant y aller. Continuer la lecture

Et vous, comment vous bloquez le spam « propre » ?

spamContre le spam, j’utilise tout l’arsenal de greylisting, quelques listes RBL, les outils tels spamassassin agrémenté de filtre plus avancés (je regrette feu l’outil SARE qu’il ne faut plus utiliser maintenant).
Côté RBL, je ne trouve pas mon bonheur complet, soit trop violent dans le blocage, soit pas assez.

Bilan, ceux que j’appelle les spammeurs propres continuent de me polluer (pas beaucoup, mais un peu quand même), surtout sur des adresses visibles que j’héberge et qu’on peut retrouver par exemple sur les pages jaunes. C’est bien du spam puisque le destinataire n’a rien demandé.

Ces spammeurs sont « propres » en ce sens où ce sont des sociétés bien définies Continuer la lecture

Ralentir le débit de postfix pour wanadoo/orange

Si vous avez un serveur d’envoi de mails (je ne parle pas d’être un spammeur) et beaucoup d’abonnés chez Wanadoo et Orange, vous risquez fort le rejet temporaire de votre serveur si le débit d’envoi est trop fort.
C’est ce qui m’est arrivé et hop, 5000 mails entassés dans la file de postfix.

On peut donc créer une file spéciale dans le master.cf de postfix et une règle de transport pour ces domaines, avec un débit réduit. Du moment où j’ai rechargé la configuration postfix et relancer le traitement de la file, magie, en 1 heure, les 5000 mails étaient distribués.

Pour ce faire, j’ai utilisé les documentations suivantes et adapté au contexte « configuration postfix définie dans MySQL », comme expliqué dans mes articles précédents, toujours d’actualité. Continuer la lecture

mailing-lists multi-domaine avec mailman sur un postfix « virtuel » (mysql)

Nouvel article pour compléter tous ceux sur l’installation d’un serveur de mails bien complet (voir ces tags).
Cette fois il s’agit d’ajouter un outil de gestion de mailing-lists avec inscription, désinscription, modération etc.
Bref, au choix, je pensais à « sympa » (dont j’ai déjà un peu parlé) ou mailman, que je ne connaissais pas.

  • « sympa » en mode multi-domaine, arrêtez-moi si je me trompe, sur une installation postfix « virtuelle » (utilisateurs en base MySQL), c’était loin d’être gagné. Mal documenté à mon goût sur la partie multi-domaine.
  • « mailman » semblait pouvoir faire tout ça, avec une interface web (et ligne de commande) assez ancestrale, mais suffisante, efficace et qui marche 🙂

Deux points de détails à bien regarder, qui m’ont fait faire cet article afin de ne pas oublier tout ça et que ça puisse resservir :

  • l’interconnexion de mailman avec la partie Mysql de postfix
  • le multi-domaine, afin de pouvoir gérer des listes genre liste1@domaine1.fr et liste2@domaine2.com, ces 2 domaines étant hébergés sur la même machine, la même installation postfix

Allez hop, c’est parti pour l’installation et les détails de configuration.
Voyez d’abord mes articles sur l’installation complète postfix/mysql/amavis/spamassassin/etc histoire de situer de quoi je parle. Continuer la lecture

spamassassin : rulesemporium est mort

Hop,
Je n’avais pas vu le truc avant qu’une mise à jour spamassassin me remonte une alerte, mais le site RulesEmporium a fermé. Plus d’activité, soit. Mais d’avoir supprimé le contenu, c’est dommage je trouve.
Bon bref, toujours est-il que j’ai de nouveau un petit bout de l’outil de détection des textes « cachés » dans les images (spam viagra & co) qui ne fonctionne plus.
D’ici à trouver quelque chose d’autre, je laisse en plan et je supprime simplement les quelques règles de détection impactées. Continuer la lecture

postfix, utilisateurs virtuels et appels à procmail

Hello,
Dans un précédent article, j’avais expliqué comment faire en sorte qu’une installation postfix/amavis/…/mysql – avec donc des domaines et des utilisateurs virtuels – puisse faire appeler « procmail » afin de passer le relai à « vacation », l’outil de répondeur automatique d’absence.
Depuis, j’ai trouvé plus élégant pour passer des règles plus complètes à procmail (quitte à envoyer à vacation ensuite). C’est juste beaucoup plus joli et mieux construit. J’explique – toujours en partant d’une conf postfix/amavis/mysql comme celle que je décris dans des précédents articles. Continuer la lecture

utilisateurs postfix virtuels : ajouter un répondeur « vacation »

Avec mes précédents articles ci-dessous, vous avez de quoi monter une architecture complète de mails avec utilisateurs virtuels. Pour faire simple.

Il manque cependant un morceau : la possibilité de faire appel à des « procmail » personnalisés pour ces utilisateurs virtuels.

Lorsqu’on n’est pas avec des utilisateurs virtuels, chaque utilisateur réel (ayant un compte utilisateur, donc) utilise généralement son ~/.procmailrc pour trier un peu ou – cas qui m’intéresse particulièrement – activer son répondeur d’absence, « vacation«  pour ne pas le nommer.
Dans le cas d’utilisateurs virtuels, c’est sensiblement différent. C’est ce que je décrirai dans cet article. Ce n’est au final pas compliqué, mais il faut comprendre le rôle de chaque composant et les limites de fonctionnement de chaque outil.
En effet, je n’ai pas trouvé de doc ultra-claire sur le sujet sur le web, surtout les bricoles de chacun. Avec un peu de recul, et, voyant ma propre solution, j’ai l’impression qu’il y a tellement de configurations possibles (maildrop et pas procmail, mes utilisateurs virtuels comme ci, pas comme ça, il utilise postfixadmin et pas moi etc) qu’il est impossible d’écrire un truc qui n’est pas spécifique.
Le plus dur est donc de comprendre ce qu’on fait pour transposer à sa conf. Je tâcherai donc, comme d’hab, d’expliquer ce que je fais plutôt que de copier-coller les fichiers de conf.

Allez, let’s go pour la mise en place sur la base d’une archi postfix & co comme décrite dans les docs mentionnées en début de cet article.

Ah, dernier point : à la base, et tel que je le décris, l’utilisateur ne pourra pas mettre lui même son répondeur en place. Dans mon cas, ce n’est pas important. En effet, j’utilise des utilisateurs virtuels car il s’agit d’un serveur frontal de mails (qui trie le spam, en gros), livre les messages dans des arborescences virtuelles en attendant d’être POPées depuis un backend de mails quelconque (un vilain Exchange :)). Donc, le répondeur d’absence des utilisateurs « physiques » est géré par eux-mêmes dans Outlook « normalement », et je n’applique ce principe de répondeur qu’exceptionnellement, à quelques boîtes mails IMAP génériques, qui n’ont pas vraiment de notion de « vacances ». Des boîtes partagées entre plusieurs personnes, si vous voulez, mais stockées sur le frontal et pas dans le backend, pour diverses raisons dont on se moque ici. Après vous pourrez toujours bricoler un truc pour que tout un chacun accède à son procmail ou son message d’asbence pour le mettre, l’enlever etc. Continuer la lecture

Monitoring (vite fait̉) du volume de mails

Hop, juste pour y penser. Sur votre beau serveur de mails, pensez à mettre ces 2 outils (surtout mailgraph en fait) :

aptitude install isoqlog mailgraph

Il n’y a rien à dire sur le paramétrage de mailgraph. Dans le cas d’une installation standard de Debian, vous trouverez le rapport temps réel sur http://le.serveur/cgi-bin/mailgraph.cgi.

Si vous avez désactivé l’alias /cgi-bin/ de la conf standard Apache, débrouillez-vous pour accéder au script /usr/lib/cgi-bin/mailgraph.cgi.
Voici le genre de rapport que l’on obtient : http://www.stat.ee.ethz.ch/mailgraph.cgi.

Pour isoqlog, il ne vous demande que des choses faciles pendant l’installation : nom du domaine, type de logs (postfix, exim etc). Les rapports tournent en crontab journalière, résultats dans /var/www/isoqlog/. Par défaut, c’est donc http://le.serveur/isoqlog/ pour accéder.

Voilà, statistiquez bien.

postfix : utilisateurs « virtuels » MySQL ; accès POP3[S], IMAP[S], SASL et TLS ; quota (bingo, j’ai tout mis dans le titre)

Introduction

Hop,
Après ma doc d’initiation Debian, où un rapide chapitre est consacré au montage d’un serveur postfix, spamassassin, greylisting etc, dans une configuration simple,
Après cet article sur le montage complet cette fois, en incluant amavisd-new, anti-virus etc,
=> Voici le complément idéal, par exemple en PME (et même plus gros) :

  • Gestion d’utilisateurs virtuels, entendez par là « utilisateurs définis en base de données et non pas utilisateurs réels de l’OS ».
  • Mise en place de tout ce qu’il faut pour lire les mails (POP3, POP3S, IMAP, IMAPS) via les outils « courier-* »
  • Authentification via SASL
  • Mise en place d’authentification sécurisée plus forte pour l’envoi (TLS).

Pour le webmail, j’en ai parlé déjà quelques fois sur mon blog et dernièrement, la version 0.3 de roundcubemail a fait de gros progrès par rapport à la 0.1. Ca s’installe en 3 clics. Si j’ai le temps je ferai un article, mais c’est mal barré. Continuer la lecture