# uname -a - Mot-clé - postfix

C'est l'histoire d'un spam Partie 1: petit cours d'anatomie

Mathieu — Mon, 02 May 2016 15:48:00 +0200

Le SPAM par mail, c'est pénible. C'est du travail à temps plein si on veut s'en débarrasser en gênant le moins les utilisateurs. De la stricte application des RFC aux paramètres secrets de spamassassin, je vais essayer dans cette nouvelle série d'articles essayer de vous en faire mieux comprendre les techniques, et proposer à mon échelle les quelques solutions "qui marchent", du moins pour moi.

Voici donc pour cette première partie un cours d'autopsie. Le SPAM que nous décortiquer aujourd'hui est un mail est est resté coincé en queue sur le serveur mail. Bien que tous les mails en queue ne soient pas du SPAM, il est important de surveiller la taille de cette liste de mails "en transit" ; un grand nombre de mails dans cette liste indiquant souvent un problème d'envoi ou de réception.

Affichons donc la queue :

# mailq
1430281C33     8589 Thu Apr 28 14:51:58  MAILER-DAEMON
             (connect to serveurspamserveur.net.ae[86.96.xxx.xxx]:25: Connection refused)
                                         spammeur@serveurspamserveur.net.ae

Première constatation : l'adresse source ne correspond pas à une adresse gérée par le serveur, ce n'est donc pas un mail envoyé par un des utilisateurs du serveur. Mais alors comment ça se fait que je route des mails qui ne viennent pas de chez moi, et qui ne vont pas chez moi ? Mon serveur serait configuré en OpenRelay (ça serait inquiétant) ?

Examinons le contenu brut du mail à partir de son ID. La commande postcat permet de le faire pour Postfix, à adapter selon votre MTA.

# postcat -q 1430281C33

Ci-dessous la sortie de la commande postcat que j'ai colorisée :

*** ENVELOPE RECORDS deferred/1/1430281C33 ***
message_size:            8589             234               1               0            8589
message_arrival_time: Thu Apr 28 14:51:58 2016
create_time: Thu Apr 28 14:51:58 2016
named_attribute: log_message_origin=local
named_attribute: trace_flags=0
sender:
original_recipient: spammeur@spamserveur.net.ae
recipient: spammeur@spamserveur.net.ae
*** MESSAGE CONTENTS deferred/1/1430281C33 ***
Received: by monserveur.com (Postfix)
    id 1430281C33; Thu, 28 Apr 2016 14:51:58 +0200 (CEST)
Date: Thu, 28 Apr 2016 14:51:58 +0200 (CEST)
From: MAILER-DAEMON@monserveur.com (Mail Delivery System)
Subject: Undelivered Mail Returned to Sender
To: spammeur@spamserveur.net.ae
Auto-Submitted: auto-replied
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
    boundary="B25FA81C32.1461847918/monserveur.com"
Content-Transfer-Encoding: 8bit
Message-Id: <20160428125158.1430281C33@monserveur.com>

This is a MIME-encapsulated message.

--B25FA81C32.1461847918/monserveur.com
Content-Description: Notification
Content-Type: text/plain; charset=us-ascii

This is the mail system at host monserveur.com.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

                   The mail system

<monclient@gmail.com>: host
    gmail-smtp-in.l.google.com[2a00:1450:400c:xxxx::xxxx] said: 552-5.7.0 This
    message was blocked because its content presents a potential 552-5.7.0
    security issue. Please visit 552-5.7.0
    https://support.google.com/mail/answer/6590 to review our message 552 5.7.0
    content and attachment content guidelines. cw9si10769736wjb.20 - gsmtp (in
    reply to end of DATA command)

--B25FA81C32.1461847918/monserveur.com
Content-Description: Delivery report
Content-Type: message/delivery-status

Reporting-MTA: dns; monserveur.com
X-Postfix-Queue-ID: B25FA81C32
X-Postfix-Sender: rfc822; spammeur@spamserveur.net.ae
Arrival-Date: Thu, 28 Apr 2016 14:51:57 +0200 (CEST)

Final-Recipient: rfc822; monclient@gmail.com
Original-Recipient: rfc822;monclient@gmail.com
Action: failed
Status: 5.7.0
Remote-MTA: dns; gmail-smtp-in.l.google.com
Diagnostic-Code: smtp; 552-5.7.0 This message was blocked because its content
    presents a potential 552-5.7.0 security issue. Please visit 552-5.7.0
    https://support.google.com/mail/answer/6590 to review our message 552 5.7.0
    content and attachment content guidelines. cw9si10769736wjb.20 - gsmtp

--B25FA81C32.1461847918/monserveur.com
Content-Description: Undelivered Message
Content-Type: message/rfc822
Content-Transfer-Encoding: 8bit

Return-Path: <spammeur@spamserveur.net.ae>
Received: from localhost (localhost [127.0.0.1])
    by monserveur.com (Postfix) with ESMTP id B25FA81C32
    for <monclient@gmail.com>; Thu, 28 Apr 2016 14:51:57 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at monserveur.com
Received: from monserveur.com ([127.0.0.1])
    by localhost (monserveur.com [127.0.0.1]) (amavisd-new, port 10024)
    with ESMTP id vn_xZRLJ3EKq for <monclient@gmail.com>;
    Thu, 28 Apr 2016 14:51:51 +0200 (CEST)
Received: by monserveur.com (Postfix, from userid 5000)
    id BE51181C31; Thu, 28 Apr 2016 14:51:51 +0200 (CEST)
X-Sieve: Pigeonhole Sieve 0.4.2
X-Sieve-Redirected-From: contact@monclient.com
Delivered-To: contact@monclient.com
Received: from localhost (localhost [127.0.0.1])
    by monserveur.com (Postfix) with ESMTP id 95E2581C33
    for <contact@monclient.com>; Thu, 28 Apr 2016 14:51:51 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at monserveur.com
Received: from monserveur.com ([127.0.0.1])
    by localhost (monserveur.com [127.0.0.1]) (amavisd-new, port 10024)
    with ESMTP id 8agkFLPzF_vy for <contact@monclient.com>;
    Thu, 28 Apr 2016 14:51:44 +0200 (CEST)
Received: from bba148580.serveurspam.net.ae (bba148580.serveurspam.net.ae [217.165.xxx.xxx])
    by monserveur.com (Postfix) with ESMTP id 774C481C27
    for <contact@monclient.com>; Thu, 28 Apr 2016 14:51:44 +0200 (CEST)
Received: from www.serveurspam.net.ae ([127.0.0.1]) by AMAZONA-F00CA66 with Microsoft SMTPSVC(7.5.7601.17514);
     Thu, 28 Apr 2016 16:51:42 +0400
Date: Thu, 28 Apr 2016 16:51:42 +0400
To: "contact@monclient.com" <contact@monclient.com>
From: xxxx xxxx <spammeur@spamserveur.net.ae>
Subject: [SPAM] FW: Invoice
Message-ID: <be0fa65c2e77bf81d3fd1b0216e8e742@www.serveurspam.net.ae>
X-Priority: 3
X-Mailer: PHPMailer [version 1.73]
MIME-Version: 1.0
Content-Type: multipart/mixed;
    boundary="b1_be0fa65c2e77bf81d3fd1b0216e8e742"
X-OriginalArrivalTime: 28 Apr 2016 16:51:42.0538 (UTC) FILETIME=[40C0DFC0:01D1A068]

--b1_be0fa65c2e77bf81d3fd1b0216e8e742
Content-Type: multipart/alternative;
    boundary="b2_be0fa65c2e77bf81d3fd1b0216e8e742"

--b2_be0fa65c2e77bf81d3fd1b0216e8e742
Content-Type: text/plain; charset = "iso-8859-1"
Content-Transfer-Encoding: 8bit

Please find attached invoice #726990

Have a nice day

Rowena Pittman
Executive Director Sales Account Management Training Performance Support

--b2_be0fa65c2e77bf81d3fd1b0216e8e742
Content-Type: text/html; charset = "iso-8859-1"
Content-Transfer-Encoding: 8bit

<html>
<body>
<p>Please find attached invoice #726990<br><br><br>Have a nice day<br><br><br>Rowena Pittman<br>
Executive Director Sales Account Management Training Performance Support</p>
</body></html>

--b2_be0fa65c2e77bf81d3fd1b0216e8e742--
--b1_be0fa65c2e77bf81d3fd1b0216e8e742
Content-Type: application/zip; name="B1095_scan-invoice_0B0C3F.zip"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="B1095_scan-invoice_0B0C3F.zip"

UEsDBBQAAAAIAIRenEiR5N/wYgcAAHQTAAAKAAAAMTk0MGMwOS5qc9VYaW/TMBj+DBL/IUQC
ElYGLacoCNJr7Wh6LKVrixBKHCdxDid17oz9d+ys45IzBN+YtmWLX7/v4+c93Uwnwgha4xSe

...

--b1_be0fa65c2e77bf81d3fd1b0216e8e742--

--B25FA81C32.1461847918/monserveur.com--
*** HEADER EXTRACTED deferred/1/1430281C33 ***
named_attribute: encoding=8bit
*** MESSAGE FILE END deferred/1/1430281C33 ***

Les lignes que j'ai mises en gris ne sont pas très intéressantes : il s'agit de l'enveloppe et des informations fournies par le système qui gère la queue, intéressons-nous plutôt au reste.

Les lignes en bleu sont les en-têtes, ce sont elles qui retracent à la fois le format du message, mais aussi leur trajet à travers les différents serveurs mails qui l'ont manipulé. Comme une liste de tampons sur un passeport. Ce sont en particulier les lignes commençant par Received, qui tracent le trajet des mails à travers les échanges entre les serveurs. La première ligne Received correspondant au dernier échange réalisé, et la dernière ligne Received au premier échange réalisé.

Dans l'en-tête on retrouve aussi l'ID du message, 1430281C33, et son parcours entre les seveurs mail. Chaque serveur par lequel le mail passe va rajouter une ligne, la première ligne correspondant au dernier serveur ayant reçu le message.

Les lignes en rouge sont ce que l'on appelle les boundaries (et leurs déclarations). Ce sont des lignes de séparation permettant de dissocier les pièces jointes du reste du message. Ici on en a plusieurs, parce qu'en fait à chaque échange, le mail s'est fait attacher à un autre mail. Ce n'est pas courant, à moins que le mail n'ai été enrichi d'informations supplémentaire après un "rejet" du serveur de destination. Ici, il s'est donc probablement fait "jeter" plusieurs fois !

Commençons notre analyse par la fin du message. Le mail original contenait visiblement lui aussi une pièce jointe, et à en juger par le texte invitant à ouvrir la pièce jointe, il est fort possible que ça soit un SCAM. Un message vous invitant à ouvrir un faux fichier PDF qui va infecter l'ordinateur. Heureusement donc que ce mail n'est pas arrivé jusqu'à sa destination.

Remontons un peu, on constate que le mail a été envoyé avec PHPMailer, et qu'il a été marqué en [SPAM] dans le sujet par mon filtre antispam. La première trace de l'arrivée du mail est la suivante :

Received: from bba148580.serveurspam.net.ae (bba148580.serveurspam.net.ae [217.165.xxx.xxx]) by monserveur.com (Postfix) with ESMTP id 774C481C27 for <contact@monclient.com>; Thu, 28 Apr 2016 14:51:44 +0200 (CEST)
Received: from www.serveurspam.net.ae ([127.0.0.1]) by AMAZONA-F00CA66 with Microsoft SMTPSVC(7.5.7601.17514); Thu, 28 Apr 2016 16:51:42 +0400

La ligne au-dessus, c'est la trace du passage à l'antispam et à l'antivirus :

Received: from localhost (localhost [127.0.0.1]) by monserveur.com (Postfix) with ESMTP id 95E2581C33 for <contact@monclient.com>; Thu, 28 Apr 2016 14:51:51 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at monserveur.com
Received: from monserveur.com ([127.0.0.1]) by localhost (monserveur.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8agkFLPzF_vy for <contact@monclient.com>; Thu, 28 Apr 2016 14:51:44 +0200 (CEST)

Rien de spécial, l'antivirus et l'antispam sont installés en local et ont fait leur job dès que le message a été reçu. Continuons.

X-Sieve: Pigeonhole Sieve 0.4.2
X-Sieve-Redirected-From: contact@monclient.com

Ça c'est le mécanisme qui gère les alias de mon serveur. Sieve va rediriger l'adresse contact@monclient.com vers la bonne adresse de destination, l'adresse contact@monclient.com étant un alias.

Received: from monserveur.com ([127.0.0.1]) by localhost (monserveur.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vn_xZRLJ3EKq for <monclient@gmail.com>; Thu, 28 Apr 2016 14:51:51 +0200 (CEST)
Received: by monserveur.com (Postfix, from userid 5000) id BE51181C31; Thu, 28 Apr 2016 14:51:51 +0200 (CEST)

On transfère tout ça au MTA local pour envoi à la destination finale :

Received: from localhost (localhost [127.0.0.1]) by monserveur.com (Postfix) with ESMTP id B25FA81C32 for <monclient@gmail.com>; Thu, 28 Apr 2016 14:51:57 +0200 (CEST)

Fin du premier message, on traverse la boundary pour voir ce qu'il s'est passé ensuite :

<monclient@gmail.com>: host gmail-smtp-in.l.google.com[2a00:1450:400c:xxxx::xxxx] said: 552-5.7.0 This message was blocked because its content presents a potential 552-5.7.0 security issue.

Ça c'est moins cool. En gros, gmail a jeté le message, parce que la pièce jointe était sans doute contaminée. Mon antivirus n'a rien vu, il va falloir chercher pourquoi (plus tard).

On continue de remonter, et au-dessus de la dernière boundary, on a :

Received: by monserveur.com (Postfix) id 1430281C33; Thu, 28 Apr 2016 14:51:58 +0200 (CEST)

Ok, gmail m'a renvoyé le message plus ou moins gentiement en m'expliquant qu'il n'en voulait pas, et mon serveur essaie de le transférer au spammeur original qui nous a fermé sa porte. Le mail reste donc en queue jusqu'à son expiration... Voilà pourquoi il traîne dans la queue des mails et qu'il n'a été envoyé ni par moi ni pour moi...

Conclusion

J'espère que cette courte plongée dans les en-têtes d'un mail vous a permis de vous familiariser avec le "vrai" contenu d'un mail.

Ici je ne peux plus faire grand chose avec ce mail à part le supprimer de la queue mail, le spammeur ayant certainement déjà été bloqué par son hébergeur ou changé d'adresse IP pour continuer à envoyer sans se faire prendre par les blacklists.

À bientôt pour un nouvel article.

Diminuer le taux de rejet des mails sortants pour un fournisseur de boîtes mail

Mathieu — Tue, 09 Feb 2016 21:06:00 +0100

En théorie, tout le monde peut s’improviser fournisseur d’emails, il suffit d’une machine avec les ports ouverts sur Internet et de quelques connaissances pour configurer le serveur mail (Postfix, Exim…)

En pratique, les fournisseurs de mails subissent la « concurrence déloyale » de leur camarades, car envoyer un mail c’est bien, faire en sorte qu’il soit reçu c’est mieux. Les « concurrents » ce sont les fournisseurs de service comme Hotmail, Gmail, Yahoo, et bien d’autres. Afin de lutter contre le SPAM, ces sociétés sont de plus en plus strictes sur la source des mails qui sont reçus par leurs services.

Une des conséquences c’est que les petits opérateurs, comme une start-up qui fournit de l’hébergement, un FAI associatif, ou même un particulier qui veut se réapproprier Internet, se font bloquer assez rapidement avec peu de solutions de recours, le support faisant souvent la sourde oreille.

Dans cet article, je vais donc explorer quelques pistes pour vous permettre d’abord d’éviter de vous retrouver bloqués, et ensuite contourner le blocage le cas échéant.

Ce billet est le produit de mes expériences avec l'hébergeur wellhosted.

Réputation (et monitoring)

Déjà, si vous avez une adresse IP dynamique, oubliez l’envoi de mails. Il est très difficile avec une IP dynamique d’assurer à la fois une réception correcte (même avec un MX pointant sur un DynDNS), et un envoi qui réussisse à tous les coups. D’ailleurs, la plupart des opérateurs proposant des IPs dynamiques bloquent le port 25, rendant l’envoi des mails « entre serveurs » impossible.

Ensuite, la seconde bonne raison pour avoir une IP fixe, c’est que les contrôlent antispam reposent en grande partie sur la réputation des IPs qui leur envoient des mails. Ce mécanisme s’appelle le RBL pour Realtime Block List. Les serveurs s’abonnent à des listes d'adresses IP connues pour émettre du SPAM, et refusent de recevoir les mails depuis ces IPs. Pas de chance si vous avez hérité d’une IP « qui pue », il vous faudra patiemment demander votre retrait de la liste de blocage au cas par cas.

Il existe des outils pour tester votre IP sur un grand nombre de RBL : mxtoolbox.com/blacklists.aspx

Vous pouvez également mettre en place une surveillance automatique de votre réputation sur plusieurs blocklists, soit avec un simple plugin Nagios, soit avec un outil comme RBLMon.

A noter que certaines listes ne permettent pas de faire « retirer » votre IP de la liste. Pas d’inquiétude pour ces listes, personne ne les utilise. Il existe par contre des fournisseurs de service qui ne publient pas leurs listes, et qui ont un processus contraignant pour se faire débloquer (Microsoft par exemple).

Une fois que votre IP est fixe et qu'elle est propre, l’étape suivante c’est conserver la réputation de votre IP et être irréprochable sur les mails que vous envoyez, mail nous verrons cela dans la suite.

IPv6

Même si ce n’est pas indispensable, IPv6 est le futur d'Internet, et de nombreux serveurs mails parlent IPv6. En utilisant IPv6, vous aurez aussi l’avantage que beaucoup de RBL ne sont pas prêtes pour IPv6, et donc votre IP ne sera certainement pas bloquée sur ces listes.

Revers de la médaille : oubliez l’utilisation d’une IPv6 exclusive, certains fournisseurs de mail utilisent encore exclusivement IPv4, il vous faudra donc une configuration réseau supportant les deux adressages pour être certain de pouvoir livrer vos mails.

Reverse, PTR, et Hostname

Le « Reverse », parfois nommé « PTR », est une résolution DNS inverse. De la même façon qu'une résolution DNS permet de passer d'un nom de domaine à une adresse IP, le DNS inverse permet de passer d'une adresse IP à un nom de domaine. Ce mécanisme existe aussi bien pour IPv4 que pour IPv6.

Si votre fournisseur de service (la personne chez qui vous louez les IPs ou les serveurs) ne vous permet pas de changer le Reverse, changez de prestataire immédiatement ! L'envoi d'un mail à partir d'une adresse IP sans Reverse est souvent rédhibitoire pour le serveur mail de destination (pas de reverse, pas de livraison).

De plus, votre Reverse doit être consistant :

L'adresse IP doit résoudre vers un domaine, et ce même domaine doit résoudre vers l'adresse IP.
Le serveur mail doit également fournir son nom de domaine principal dans le processus de négociation, et ce nom doit résoudre correctement vers son IP. Réglez donc les /etc/hostname ; /etc/mailname et myhostname (pour Postfix) correctement.

Une inconsistance à un quelconque niveau est pire qu'une absence de reverse : le serveur de destination considérera qu'il y a peut-être usurpation de l'IP.

Encore une fois, n'oubliez pas de régler aussi le reverse IPv6 si vous utilisez IPv6 sur votre serveur.

Postmaster, Hostmaster, et RFC

Certains serveurs mails sont un peu soupe au lait. Par exemple, il peut arriver que votre réputation descende en flèche juste parce que le propriétaire du serveur n’a pas de moyen automatisé de vous contacter.

J’explique : dans les RFC (Request For Comment, la base des normes et protocoles sur Internet), il est prévu qu’un serveur mail émettant du courrier possède des adresses particulières, à savoir postmaster@ledomaine.com et hostmaster@ledomaine.com permettant de recevoir les mails envoyés automatiquement par ses pairs.

postmaster recevra principalement les plaintes pour SPAM, notification de traffic inhabituel sur les mails, et autres requêtes relatives aux mails
hostmaster recevra les mails relatifs à la gestion du nom de domaine lui-même (demandes de transfert, contact légal du propriétaire - même si on préfère souvent écrire aux contacts du whois), ou parfois pour la réservation d’un certificat SSL (vérification de la propriété du nom de domaine avant délivrance automatique du certificat).

L’absence d’une adresse postmaster@ valide sur votre serveur vous fait donc paraître pour le serveur mail de destination comme un spammeur qui n’a même pas pris la peine d’implémenter correctement le protocole mail.

A noter qu’un alias de postmaster@ vers une adresse de votre choix fonctionne aussi, même si cette adresse est un trou noir. Mais vous ne devriez pas ignorer les notifications automatiques de blocage et de plaintes envoyées à postmaster…

De la même façon, préférez un logiciel de serveur mail respectueux des standards (Postfix, Exim) au tout-dernier-serveur-mail-a-la-mode, dont les réponses ne sont peut-être pas entièrement conformes aux RFC.

Limites

Là on touche au grand dilemme du fournisseur de mails en serveur mutualisé : offrir plus de possibilités aux utilisateurs, ou se protéger contre les usages abusifs ?

Concrètement, imaginons qu’un de vos utilisateurs décide d’envoyer de la publicité aux 500 adresses mail de sa liste de contacts. Les serveurs recevant un tel volume de messages d’un seul coup ne vont peut-être pas apprécier ce trafic non sollicité et encombrant (de la pub ? du SPAM ? Paf, bloqué).

Pire : imaginez qu’un de vos utilisateurs se fasse pirater sa boîte mail, et devienne un émetteur de SPAM ou de virus à partir de votre serveur mail ? Vous pensez que les serveurs de destinations seront compréhensifs s’ils reçoivent des centaines de mails par seconde provenant de votre serveur mail ? Ils ne chercheront pas à comprendre : paf, bloqué.

La solution dans un premier temps c’est de limiter le nombre de mails envoyés par votre serveur, par adresse et par jour. Chaque utilisateur ne devrait par exemple envoyer que 300 mails par jour. Au-delà, le compte sera bloqué en attendant que l’on détermine si c’est une utilisation légitime ou non. La limite est bien entendu à calibrer selon les utilisateurs et les services que vous voulez offrir.

Il existe plusieurs solutions pour implémenter ce comportement, voici la mienne : github.com/mpellegrin/ratelimit-policyd

Diminuer la vitesse d’envoi

Ça peut paraître un comble au moment où l’on veut recevoir les informations le plus vite possible, et pourtant c’est souvent nécessaire pour l’envoi de mails. Afin d’éviter d’envoyer trop vite un grand volume de mail d’un coup, il peut être nécessaire de mettre en place une limite de mails sortants par seconde et par domaine de destination. Ainsi, le serveur mail de destination ne sera pas inondé sous le poids des mails à traiter, et sera plus coopératif pour les recevoir (en résumé : il ne vous bloquera pas pour usage abusif de sa bande passante).

La mitigation du taux d’envoi peut être faite au moyen de simples paramètres pour le serveur mail steam.io/2013/04/01/postfix-rate-limiting/

DKIM et SPF

Avoir un enregistrement SPF valide pour le domaine avec lequel vous envoyez vos mails est pratiquement obligatoire : non seulement cela vous permettra de confirmer que le serveur qui envoie vos mails y est bien autorisé, mais cela vous protégera (un peu) contre les usurpations d'adresses mail. Un exemple de SPF serait :

v=spf1 +a +mx -all

Si vous voulez un effet positif maximal, préférez un réglage strict ("-all") au réglage de debug ("?all"), quitte à élargir votre jeu de règles en insérant toutes vos IPs. Par contre, ne mettez pas un TTL trop haut sur les enregistrements SPF, on ne sait jamais.

Attention également, pour configurer votre domaine, le champ de type "SPF" est obsolète, utilisez un champ de type TXT pour vos enregistrements SPF.

En complément au mécanisme SPF, parce que le SPF n'est pas toujours suffisant pour assurer au serveur de destination que le mail est légitime, vous pouvez mettre en place le DKIM pour tous vos mails sortants. La configuration est plus complexe, mais elle vaut largement le coup pour vous faire sortir de l'ornière d'une réputation trop faible de votre adresse IP dans les premiers mois.

Le principe du DKIM c'est d'ajouter une signature aux mails, cette signature étant calculée à partir d'une clef privée. La clef publique est quant à elle publiée dans un enregistrement TXT dans le nom de domaine, permettant au serveur recevant le mail de vérifier la validité de la signature, et donc la légitimité du message envoyé à partir du nom de domaine.

Smarthosts

Si finalement tout ce dont j'ai parlé plus haut n'a pas fonctionné, et que vous vous êtes fait bloquer sur le réseau d'un des grands fournisseurs de boîtes mail (Google, Microsoft, yahoo...), voici votre dernier recours.

Outre changer d'adresse IP, ce qui pose souvent d'autres problèmes, votre solution c'est d'utiliser un Smarthost. Le Smarthost, c'est tout simplement un serveur mail qui transfère des mails. C'est ce que l'on appelle aussi un relay mail, qui va renvoyer tous vos mails à la place de votre serveur bloqué.

Dans l'idéal vous devriez avoir plusieurs smarthosts, pour pouvoir répartir la charge de traitement, et les échanger lorsque l'adresse IP de l'un d'eux se fait bloquer. Ainsi vous ne touchez pas à vos MX, et vous avez un réseau permettant de faire sortir des mails indépendemment de votre réseau de réception.

Le routage vers le Smarthost se règle très simplement dans Postfix, en utilisant la directive transport_maps de Postfix et en configurant un second serveur mail (le smarthost) en mode Relay.

Attention cependant au moment de créer votre smarthost à ne pas créer de configuration en "Open Relay", qui permettrait à n'importe qui d'envoyer des mails à travers le smarthost, la sentence sera immédiate lorsque des spammeurs s'en apercevront. Réglez bien votre mynetwork, et sender_restrictions (par exemple avec Postfix).

Pour aller plus loin

Voici une liste d'outils assez pratique lorsque l'on configure ou que l'on cherche la cause d'un problème de délivrance sur un serveur mail :

Mail Tester (indispensable pour vérifier votre configuration)
MXToolbox (le couteau suisse des tests sur les serveurs mails)
Quelques conseils de Google

Quelques liens pour (essayer de) se faire retirer de la Blocklist :

Pour se faire dé-bannir par Microsoft (sans garanties...)
Pour se faire dé-bannir par Google (sans garanties)
Pour se faire débannir par Yahoo (sans garanties)
Pour se faire débannir par AOL (sans garanties)

Les programmes de monitoring de réputation :

Postfix : configure postmaster, hostmaster, and abuse catchall for RFC compliance

Mathieu — Sat, 29 Aug 2015 18:02:00 +0200

This short howto will show you how to set up a catchall for common required email addresses. Some mail servers are testing if mail is accepted on this addresses to detect spammymail servers. Hostmaster address can also be used for domain Trading, to check the ownership of the domain.

1. Create a file named /etc/postfix/regexp-catchall.cf with the following content:

# Catchall to comply with RFC standards
/^postmaster@/    youshouldreadit@mydomain.com
/^hostmaster@/    youshouldreadit@mydomain.com
/^abuse@/         youshouldreadit@mydomain.com

Replace youshouldreadit@mydomain.com with a mail address you actually read.

2. Open /etc/postfix/main.cf and locate (or create) the line virtual_alias_maps, and add at the end regexp:/etc/postfix/regexp-catchall.cf, for instance:

virtual_alias_maps = proxy:mysql:/etc/postfix/mysql-virtual_forwardings.cf, regexp:/etc/postfix/regexp-catchall.cf

3. Restart Postfix.

Warning : read comment #4 for issues with this setup.

Configure sender rate limits to prevent spam, using cluebringer (policyd) with Postfix

Mathieu — Fri, 13 Mar 2015 09:18:00 +0100

This small how-to will show you how to configure cluebringer (aka policyd) to set a per-hour/per-user limit for sent mails. Note that sending to multiple recipient will count like multiple mails were sent.

This how-to is Debian-oriented but should apply to any unix operating system.

Requirements

A mail server with Postfix installed.

Installation

Install a DBMS (MySQL for instance), cluebringer, and cluebringer-webui :

apt-get install mysql-server cluebringer cluebringer-mysql cluebringer-webui

Note that cluebringer-webui will install apache as a dependency if you don’t already have a webserver.

Set-up the Cluebringer database

Get the initial database schema that correspond to your DBMS, for instance mysql :

cp /usr/share/doc/postfix-cluebringer/database/policyd-db.mysql.gz ~/ && gunzip ~/policyd-db.mysql.gz

Create the database, and populate it with the initial dump :

# cd  ~/ && mysql -u root -p
mysql> CREATE DATABASE cluebringer;
mysql> CREATE USER 'cluebringer'@'localhost' IDENTIFIED BY 'mypassword';
mysql> GRANT ALL PRIVILEGES ON cluebringer.* TO 'cluebringer'@'localhost';
mysql> \. policyd-db.mysql
mysql> quit
mysql> Bye

Note that on Debian I had to modify the dump to make it work, TYPE=InnoDB was rejected by MySQL as an invalid syntax.

Configure Cluebringer

Add your DBMS credentials to the file /etc/cluebringer/cluebringer.conf :

DSN=DBI:mysql:dbname=cluebringer;host=localhost

DB_Type=mysql
DB_Host=localhost
DB_Port=3306
DB_Name=cluebringer
Username=cluebringer
Password=mypassword

And start it :

service postfix-cluebringer start

Configure Cluebringer webui

Configure the file /etc/cluebringer/cluebringer-webui.conf with your DBMS credentials :

<?php

$DB_DSN="mysql:host=localhost;dbname=cluebringer";
$DB_USER="cluebringer";
$DB_PASS="mypassword";

Cluebringer Webui needs a web server to run. Copy the sample configuration from the package documentation :

cp /usr/share/doc/postfix-cluebringer-webui/examples/httpd/cluebringer-httpd.conf /etc/apache2/conf.d/

Restart Apache :

service apache2 restart

You may need to adjust a few things to access it from the outside. If you a really lazy, just make a ssh tunnel to access the webserver from localhost :

ssh -L 8008:localhost:80 mylogin@mymailserver

Don’t forget : you have to make this tunnel from the outside, do not run this command on server, it won’t work.

You should now be able to open http://localhost:8080/ and see your fresh new Cluebinger Webui !

Configure Cluebringer using its webui

Add a policy

Under Policies -> Main, disable Test policy (select policy and choose Action -> Change and switch Disabled to yes, validate)

Add a new policy : Action -> Add, give it a name and a description

Activate your new policy : select policy and choose Action -> Change (switch Disabled to no)

Add a new member to your policy : select it and choose Action -> Members, and then Action -> Add. Specify any as source and any as destination.

Go back to your policy, choose Action -> Members, and the select your member, do Action -> Change, and activate your new member (switch Disabled to no).

Add a quota

Under Quotas -> Configure, disable Test quotas.

Add a new quota : Choose Action -> Add

Name : whatever you want
Track : user@domain
Period (seconds) : 3600
Link to policy : specify the policy you created here
Verdict : Defer
Data : set a custom error message here
Comment : whatever you want

Activate your quota : switch Disabled to no.

Add a limit to your quota : select your quota, and choose Action -> Limits, then Action -> Add.

Type : MessageCount
Counter Limit : 200

Activate your limit : switch Disabled to no.

Configure Postfix to call Cluebringer for each mail sent

Open /etc/postfix/main.cf and locate the line smtpd_sender_restrictions.

Add check_policy_service inet:127.0.0.1:10031 at the end of the line, for instance :

smtpd_sender_restrictions = check_sender_access mysql:/etc/postfix/mysql-virtual_sender.cf, check_policy_service inet:127.0.0.1:10031

If the line does not exists, simply add it.

Don’t forget to restart Postfix :

service postfix restart

Check your config

You can now send some mails to see what happens. To check if these mails are passed to Cluebringer, connect to MySQL as the cluebringer user :

# mysql -u cluebringer -p cluebringer

And execute the query :

mysql> SELECT * FROM quotas_tracking;

You should see the value LastUpdate and Counter updating when sending a mail. Note that sending to multiple recipient will count like multiple mails were sent.

Pitfalls, bleeding edges, etc

Cluebringer versions prior to 2.1.x does not support IPv6, your customers won’t be able to send any mail if they have an IPv6 connection.

Unfortunately, the Debian stable version (wheezy) provides Cluebringer 2.0.10 within its repositories, as well as the experimental release of Debian (sid). As an alternative, you should consider installing the 2.1.x experimental Cluebringer from official website instead of Debian packages from repositories.

References

Configure Postfix as standalone single-domain SMTP server using Unix users and PAM on Debian

Mathieu — Sat, 01 Feb 2014 22:05:00 +0100

Here is a quick setup to configure Postfix mail server, using existing Unix users.

The server will process mails for only one domain, and every existing user on the server will have a mail box inside his home directory.

Abstract

Postfix is an SMTP server, it receives incoming mail from other SMTP servers, and allows client to send mails to other SMTP servers.

What we don't want is an open mail relay. A mail relay is a SMTP server that take anything from any client, and send it to any SMTP server. We only want trusted users to send emails, to prevent anonymous clients from sending spam.

Incoming mail will be processed either if :

The domain name of one of the recipient matches the mail server domain, and the mail user name is also a system user (SMTP servers can send us incoming mails).
The client who tries to sends the mail has successfully authenticated.

Postfix authentication for clients can be handled by SASL. SASL is a standard protocol to provide an authentication layer. It can query PAM, or other authentication providers (MySQL users, etc).

Notes :

We will use PAM for Unix users SMTP authentication.
Unix users are stored in /etc/passwd and their passwords are stored in /etc/shadow.
Mails will be stored in the ~/Maildir/ of each users, in Maildir format.

Postfix : installation and configuration

Install Postfix : apt-get install postfix

Answer the questions during installation to setup your mail domain (the "example.com" in user@example.com).

Modify config files :

/etc/postfix/main.cf :

Configure TLS and Maildir :

# TLS parameters smtpd_tls_key_file = /etc/ssl/private/ssl-cert-snakeoil.key smtpd_tls_cert_file = /etc/ssl/certs/ssl-cert-snakeoil.pem smtpd_tls_CAfile = /etc/ssl/certs/ca-certificates.crt smtpd_use_tls=yes smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache # See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for # information on enabling SSL in the smtp client. myhostname = mail.example.com alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases myorigin = /etc/mailname mydestination = example.com, localhost mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 mailbox_size_limit = 0 recipient_delimiter = + home_mailbox = Maildir/ # These are the "no relay" restrictions smtpd_recipient_restrictions = permit_mynetworks permit_inet_interfaces permit_sasl_authenticated reject_unauth_destination

/etc/postfix/master.cf :

Enable TLS and alternate (submission) ports :

submission inet n - - - - smtpd -o syslog_name=postfix/submission -o smtpd_tls_security_level=encrypt -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING smtps inet n - - - - smtpd -o syslog_name=postfix/smtps -o smtpd_tls_wrappermode=yes -o smtpd_sasl_auth_enable=yes -o smtpd_client_restrictions=permit_sasl_authenticated,reject -o milter_macro_daemon_name=ORIGINATING

SASL : installation and configuration

SASL plugin for Postfix (Cyrus) is part of the dependencies of Postfix server.

Install SASL administration tools : apt-get install sasl2-bin

Enable SASL daemon at startup : edit /etc/default/saslauthd and switch START to yes.

Start it manually for the first time : service saslauthd start

Enable PAM authentication for SASL

Check that PAM is part of the MECHANISMS variable in /etc/default/saslauthd :

MECHANISMS="pam"

Create /etc/pam.d/smtp :

# # /etc/pam.d/smtp - specify PAM SMTP behavior # @include common-auth @include common-account @include common-password @include common-session

Enable SASL for Postfix

Add to /etc/postfix/main.cf :

smtpd_sasl_auth_enable = yes

Create /etc/postfix/sasl/smtpd.conf :

pwcheck_method: saslauthd mech_list: PLAIN LOGIN

Adjust OPTIONS in /etc/default/saslauthd :

OPTIONS="-c -m /var/spool/postfix/var/run/saslauthd"

Add postfix user to sasl group :

adduser postfix sasl

Configuration check

Restart all services (postfix, salsauthd).

Try authentication using SASL : testsaslauthd -u user -p password

Try authentication from command line, without mail client : https://qmail.jms1.net/test-auth.shtml

Try SMTP reception by sending mail to your domain (your MX fields in domain has to be configured accordingly).