# uname -a - Mot-clé - mail

The war on SPAM: an review of the real world tools

Mathieu — Tue, 12 Sep 2017 02:54:00 +0200

Anti-spam techniques review: a few hints and tools review from my own experience.

Spam mesage are very common these days, but filtering them out is not as easy as it seems. The filtering techniques have evolved at the same rate than the spammers' evasive techniques, and the risk of filtering out a legitimate message is greater than ever.

It is also quite difficult to find good and up-to-date counter-measures list that anyone can implement.

Here is a summary of the anti-spam strategies I used / am still using. I hope it will help you understanding today's threats, and build your own solutions.

Definitions

MTA : Mail Transport Agent : this is the software that will actually do mail delivery. It is listening on port 25 and answers to SMTP commands. Some common MTAs : Postfix, Exim. More about MTA.
MX : MX records are DNS entries that are identifying the server responsible for mail delivery for the domain. More about MX records.
RBL : Realtime Blackhole List : a list of blacklisted IPs, that should be considered as spam sources. It is called Realtime because they are constantly updated. More about RBL.
RFC : Request For Comments, these are proposal for norms, some of them become norms. More about RFC.
IPS : Intrusion Protection System : these are "smart firewalls" that are blocking malicious requests, often based on behavioral rules. More about IPS.

The goals

My personal goals on SPAM war are pretty short:

Minimum false positive: having a spam is better than missing an important mail, try keeping the "permanent bashing" as low as possible
Hit harder on reoffending: coming-back spammers should be slapped harder
Internet neutrality: try not to encourage big mail farm, and let fair little providers doing their business

Available techniques

Blacklist / Blackhole Lists

Blacklists, Blackhole Lists (or RBLs) are the most ancient and most common measures for reducing spam. They are still pretty accurate, but:

It depends A LOT on the quality of the list, trashy lists are very common and they would end up sucking resources for no result, or worse, blocking legitimate emails
They are only accurate when updated often. I mean, very often (the R in RBL).
You should not use it directly on the MTA, these lists are an aggressive artefact of the past, where spam did not come from mail farms.
Very few are implementing IPv6, I agree that IPv6 spam is quite anecdotal, but it will probably change pretty soon (believe me)

Greylist

Greylisting is issuing a temporary REJECT code to force the foreign server to keep the message and send it back later. It aims at increasing the "cost per mail" for spam farms, as they cannot "hit and run" as fast as before.

The main culprits are that some providers are not implementing it well (hello Facebook) and so it needs an educated whitelist to work properly.

Some spammers are also re-sending the same mail several times in case of failure, looking like a legitimate mail server, and making Greylisting inefficient.

It is also hurting the fastness of the mail transmission, as the retry may occur several tens minutes after, slowing the mail delivery with little control on delays.

Also, some legitimate mail farms (hello OVH) are distributing their retry on several servers, making Greylisting inapplicable without fully whitelisting them.

RFC compliance

Spammers are often running special softwares for their crafted emails, tightening RFC compliance may be a good way to kick them out.

It can be as simple as forcing an HELO on SMTP protocol, or more tricky like checking the mail headers or enforcing a valid reverse.

In the majority of cases, it is very efficient, but:

Some home-made servers, especially Synology or Windows servers may be blocked while they are sending legitimate email. These servers are often ran by people who doesn't know or care on how to correctly setup a mail server. These buggy setups are more common than you think, and they are often legitimate senders, who have no clue of what is wrong, and are not willing to fix it (did I mentioned banking companies?).
In the vast majority of cases, IPv6-ready servers have no reverse on their IPv6 addresses and/or the IPv6 reverse is wrong.

SPF and DKIM

SPF and DKIM are anti-spoofing techniques. They does not guarantee that a mail is legitimate, but if the controls are showing an anomaly, it is very likely to be spam (or worse : scam or social engineering tentative).

The SPF technique is based on IP or sending domain whitelist: the sending email domain publishes a list of servers allowed to send email, along with a hint on what is expected if it does not pass (soft or hard reject).
DKIM is much more complex as the sending mail server has to cryptographically sign every message with a domain-specific key, which is then published in a special domain record.

SPF has been proven efficient at its beginnings, but today many spammers are just using stolen email accounts or custom domains that does not publish any SPF records, making it less pertinent.

DKIM is, like SPF, an anti spoofing technique, and spammers may be likely to sign mails from their custom domain if it becomes a necessity. Like SPF, a signed mail is not necessarily a clean mail. By the way, signature problems are pretty comon, and trashing an offending DKIM may not be the right behavior: Yahoo broke a lot of mailing lists when they enforced their DMARC policy.

To conclude, DKIM is relevant if you need to certify outgoing mails or if you are enforcing policies inside your company (to block spoofed email targeting your organisation) but it is definitely not an efficient anti-spam measure. And the recipient's servers may decide to simply ignore your painfully-configured DKIM headers.

Bayesian filters

Bayesian filters are frequency-based spam detection mechanisms. The idea is to sort out ham and spam for a short period of time, to let it "learn" what spam is made of, for efficient content-based detection. It has the benefit of being organisation-specific, as what is ham and what is spam may vary from one company to another (a company selling drugs may not be willing to filter out every message containing the word "pill").

But the learning process has to be taken seriously, and many end-users are just deleting spam instead of marking it for feeding the learning. By the way, the learning process needs IMAP folders to sort mails, and it will not work properly if all users are using POP mailboxes.

Spammers techniques

Or "the today's weapons of this war" .

Here is a short review of the spammers techniques I know, and some counter measures.

Address guessing

Some spammers are taking random web domains from their crawling, and then try to send their mails to commonly used addresses patterns. It can be webmaster@ ; ceo@ or whatever. These are easy to spot in log files, and a well configured MTA can take counter measures to lock out these guesses. Free (French ISP) is actually implementing this: postmaster.free.fr/index_en.html

Unfortunately, some legitimate email are sometimes sent to non existent addresses (typo, user deleted, etc) and legitimate MTA sometimes get blocked if the ban trigger is too low.

Moreover, nowadays' spammers are distributing their guesses trough zombie machines to stay under triggers, making it hard to spot.

Botnets

A lot of spammers are using zombies machines to send a high amount of mail in a short amount of time. Commercial ISP are taking the problem seriously, and many are blocking or filtering port 25 on their dynamic ranges, making impossible to have a custom mail server at home, but also preventing infected machines from sending direct-to-SMTP queries.

Direct to SMTP connections, ignoring MXes

Some spammers are just scanning IP ranges and directly talking to MTA, even if these MTAs are internal and pointed by no MX records. You may think that an authoritarian firewall is the neat solution, but it may be worth collecting these feisty IPs and feed them to an IPS, to protect the network from their guesses on the real MTAs.

Fake bounces and backsquatting

Sometimes you get an Undelivered Message notice (DSN) for a mail you never sent. This is probably backsquatting.
Backsquatting is sending email to a buggy address with a valid "from" address. An incorrectly configured mailserver would reply straight away to the from address to notify the failed delivery, instead of rejecting the mail and letting the foreign server doing the dirty job.

These configuration errors are pretty common, sometimes in defaut configurations or example configurations, but they can be easily avoided (look for documentation about backsquatting for your MTA, and test if your y server is vulnerable).

Real life advices

I am sorry, I don't have the magic wand to stop all Spam. A good spam fighting solution is always a combination of techniques, SpamAssassin for instance uses scoring from RBL as well as a bayesian filter and SPF checks.

I think that constant monitoring is important. Not just automated monitoring, but also clever log reading and mind openness on what can be a better solution for each problem. You never know what can happen in a spammer mind, and what works today may not work tomorrow. The Internet of Things is already a game changer.

I also advise you to be careful. Some decisions on our implementations may really hurt the Internet. Locking whole countries out is not without consequences, and the rise of IPv6 Internet has to be take into consideration from now.

Things are often not that pretty in mail servers, the temptation is great for a default blocking policy (hello MailInBlack). But as sysadmins, it is our responsability to not abuse and not hurting the smallest actors in the market (mails not coming from big farms). That may be a big word, but in my opinion, the freedom of the Internet also count on our neutrality on mail processing.

Thanks for reading.

SSL vs TLS vs STARTTLS

Mathieu — Mon, 13 Jun 2016 17:03:00 +0200

Cet article est une traduction libre de https://www.fastmail.com/help/technical/ssltlsstarttls.html

J'ai réalisé cette traduction pour fournir à mes clients une explication simple mais complète sur le pourquoi du comment de SSL/TLS/STARTTLS lors de la configuration de leur client mail.

Attention, l'article original date de 2012.

Définitions

Protocole : un protocole de communication est un format de données, un "langage" permettant à deux machine de communiquer entre elles. Les deux machines doivent être en capacité de parler le même protocole pour pouvoir échanger des données. SSL est un protocole de communication sécurisé ("chiffrés"), popularisé par le célèbre "cadenas" visible sur les pages web.
Port : un port est un numéro de service sur lequel les logiciels vous pouvoir communiquer entre eux. La plupart des numéros de port sont associés à des protocoles précis.

Introduction

Il y a souvent de la confusion autour des différents termes SSL, TLS and STARTTLS.

SSL et TLS fournissent tous deux un moyen de chiffrer le canal de communication entre deux ordinateurs (par exemple votre ordinateur et votre serveur mail). TLS est le successeur de SSL et les termes SSL et TLS sont interchangeables, à moins que vous ne fassiez référence à une version particulière du protocole.

STARTTLS est un moyen de prendre une connexion non chiffrée existante, et la "mettre à jour" vers une connexion sécurisée en utilisant SSL/TLS. Notez que même s'il contient TLS dans son nom, STARTTLS ne signifie pas que vous devez obligatoirement utiliser TLS, vous pouvez utiliser SSL.

Numéros de version SSL/TLS

La numérotation des versions du protocole est inconsistante entre SSL et TLS. Lorsque TLS a remplacé SSL comme protocole préférentiel pour les communications chiffrées, il a commencé avec une nouvelle numérotation de versions, et a également commencé à utiliser des sous-versions. L'ordre des versions des protocoles du plus ancien au plus récent est donc : SSL v2, SSL v3, TLS v1.0, TLS v1.1, TLS v1.2.

Lorsque vous vous connectez sur un port chiffré avec SSL/TLS, ou que vous utilisez STARTTLS pour convertir la connexion en connexion chiffrée, les deux systèmes vont négocier quel protocole et quelle version utiliser, en se basant ce qui a été configuré et sur ce que chaque système supporte.

Le support pour SSL/TLS est "virtuellement" universel de nos jours, mais le support des versions est variable. Pratiquement tous les systèmes supportent SSL v3 (à part quelques rares appareils Palm Treo comme nous avons pu le constater). La plupart des systèmes supportent TLS v1.0. À la date de Mai 2012, le support pour TLS v1.1 et TLS v1.2 est beaucoup plus restreint.

Dénomination incorrecte TLS vs STARTTLS

Pour compliquer les choses, certains logiciels de mail utilisent incorrectement le terme TLS à la place de STARTTLS. Les plus vieilles versions de Thunderbird en particulier utilisent "TLS" pour dire « utiliser STARTTLS pour chiffrer la connexion dès que possible et abandonner si STARTTLS n'est pas supporté » et « TLS, si disponible » signifie « utiliser STARTTLS pour chiffrer la connexion dès que possible si le serveur déclare le supporter, sinon utiliser simplement une connexion non chiffrée ».

Numéros de ports SSL/TLS vs plaintext/STARTTLS

Le problème du dessus est particulièrement problématique lorsque vous devez configurer des ports différents pour chaque protocole.

Pour ajouter de la sécurité à certains protocoles (e.g. IMAP, POP, etc.), il a été décidé d'ajouter nativement une couche de chiffrement SSL/TLS dans le protocole. Cependant, pour identifier que le logiciel doit parler la version nativement chiffrée du protocole au lieu de la version non chiffrée, un port différent a été déclaré pour chaque protocole. Vous avez donc :

IMAP utilise le port 143, mais IMAP avec SSL/TLS utilise le port 993.
POP utilise le port 110, mais POP avec SSL/TLS utilise le port 995.
SMTP utilise le port 25, mais SMTP avec SSL/TLS utilise le port 465.

Au bout d'un moment, il a été décidé qu'utiliser deux ports pour chaque protocole était du gaspillage, et qu'à la place il devrait y avoir un seul port sur lequel commencer la communication de manière non chiffrée, puis proposer au système distant de mettre à jour vers la version chiffrée. C'est ce pour quoi STARTTLS a été créé.

Il y a eu quelques problèmes avec cette proposition. Il y avait déjà des logiciels qui utilisaient les numéros de port alternatifs avec une connexion SSL/TLS native. Les logiciels clients peuvent avoir une durée de vie très longue, donc vous ne pouvez pas juste désactiver les ports chiffrés avant que tous les logiciels ne soient remplacés ou mis à jour.

Des mécanismes ont été mis en place sur chaque protocole pour dire aux systèmes que le protocole non chiffré supportait STARTTLS, et qu'ils ne doivent pas essayer de se connecter avant de démarrer la négociation STARTTLS. Cela créa deux situations malheureuses :

Certains logiciels ignoraient simplement l'instruction « login désactivé jusqu'à ce que la connexion soit convertie en SSL avec STARTTLS » et essayaient de se connecter tout de même, envoyant leur login et mot de passe à travers la connexion non chiffrée. Même si le serveur à ce moment là rejette le login, les informations sont déjà passées en clair sur Internet.
D'autres logiciels voyaient l'annonce « login désactivé jusqu'à conversion en SSL », mais ne mettaient pas à jour leur connexion automatiquement, et renvoyaient des erreurs « mot de passe incorrect » à l'utilisateur, ce qui provoqua de la confusion sur ce qui était incorrect dans la configuration.

Ces deux problèmes causèrent finalement d'importantes incompatibilités entre les logiciels existants, et la plupart des administrateurs systèmes continuèrent d'utiliser les connexions exclusivement non sécurisés sur le port d'origine, et les connexions SSL natives sur un port alternatif.

C'est donc devenu de fait le standard que tout le monde utilise. IMAP SSL/TLS chiffré sur le port993 ou POP SSL/TLS chiffré sur le port 995. Beaucoup de sites (dont FastMail) désactive à présent le port IMAP non sécurisé (port 143) et le port POP non sécurisé (port 110) pour que les utilisateurs utilisent obligatoirement une connexion chiffrée SSL/TLS. En désactivant les ports 143 et 110, cela supprime également complètement STARTTLS, même en tant qu'option pour les connexions IMAP/POP.

SMTP STARTTLS comme une exception

La seule vraie exception à ce qui précède est SMTP. Cependant, c'est pour une raison différente. La plupart des logiciels email utilisent utilisaient le port 25 pour soumettre des messages à envoyer au serveur mail. Cependant, SMTP a été créé à l'origine comme un protocole d'échange de messages, et non de soumission. Un autre port (587) a donc été déclaré pour la soumission de messages. Bien que le port 587 ne nécessite pas explicitement STARTTLS, l'utilisation du port 587 est devenu populaire au même moment où l'utilisation de SSL/TLS était devenue un enjeu important de sécurité et de confidentialité.

Le résultat c'est que dans la plupart des cas, les systèmes qui proposent la soumission par le port 587 nécessitent que les logiciels utilisent STARTTLS pour chiffre la connexion, et nécessitent aussi un login et un mot de passe pour s'identifier. Il y a plusieurs avantages à cette approche. En écartant les utilisateurs du port 25, les FAI ont été en mesure de bloquer le port 25 pour prévenir les envois automatiques de SPAM causés par l'infection des postes de leurs utilisateurs.

Actuellement, les choses semblent encore aléatoires, divisées entre les gens qui utilisent SMTP SSL/TLS chiffré sur le port 465, et les gens qui utilisent SMTP avec STARTTLS sur le port 587.

NDLR : SMTPS sur le port 465 est aujourd'hui définitivement obsolète.

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 :

Set-up SQL quarantine with Amavisd-new and ISPConfig

Mathieu — Sun, 06 Dec 2015 16:56:00 +0100

It's documented, but it took me two days to do it correctly, so here is how to reconfigure an ISPConfig installation of Amavis to store quarantined mail in SQL database, in order to install a quarantine viewer like Mailzu.

1. Prerequisites

A working Postfix+Amavis stack with ISPConfig
A working SQL (PostgreSQL, MySQL...) database
Optional : a working mail server with PHP (for Mailzu)

Jump to Installation if you know what you are doing.

2. Off-subject generic explanations

2.1 Amavis and ISPConfig policies

ISPConfig policies, Tag-Levels

In a default ISPConfig installation per-user ISPConfig policies are loaded. The configuration file for Amavis, written by ISPConfig contains :

@lookup_sql_dsn =
   ( ['DBI:mysql:database=dbispconfig;host=127.0.0.1;port=3306', 'ispconfig', 'xxxx'] );
$sql_select_policy =
   'SELECT *,spamfilter_users.id'.
   ' FROM spamfilter_users LEFT JOIN spamfilter_policy ON spamfilter_users.policy_id=spamfilter_policy.id'.
   ' WHERE spamfilter_users.email IN (%k) ORDER BY spamfilter_users.priority DESC';
$sql_select_white_black_list = 'SELECT wb FROM spamfilter_wblist'.
    ' WHERE (spamfilter_wblist.rid=?) AND (spamfilter_wblist.email IN (%k))' .
    ' ORDER BY spamfilter_wblist.priority DESC';

It means that whatever you would set as $sa_spam_subject_tag, $sa_tag_level_deflt, $sa_tag2_level_deflt, $sa_kill_level_deflt, $sa_dsn_cutoff_level, it will be overridden by per-user policies.

The ISPConfig policies can be changed in tab Email => Spamfilter => Policy in ISPConfig panel. If you struggle wondering why your message keeps getting smashed at level 4.5, look at the sa_tag_level in policies. We will have to change values in that policies, to make the SQL quarantine working.

2.2 Lookup DSN and Storage DSN

DSN (Data Source Name) are the connection strings with host, username, and password, used to connect to databases.

Amavis can set two DSN : one for Policies lookup (used to retrieve ISPConfig policies from Panel), and one for storage of mail meta informations and quarantine. We will use the Storage DSN to set up a secondary database for quarantine storage, to not mess with existing ISPConfig database.

2.3 Levels and cutoffs

Amavis uses Spamassassin to score the mail, in order to decide what to do with it. The category of test (spam test, antivirus, etc) and the score along with levels determines the actions Amavis will trigger, and the final destiny where the mail belongs.

Spamassassin levels are :

tag_level : a message above that score will be tagged with X-Spam-Status, X-Spam-Score and X-Spam-Level headers.
tag2_level : a message above that score will be marked as X-Spam-Status: Yes and the subject is changed if sa_spam_modifies_subj is set to true.
kill_level : a message above that score is taken to the final_spam_destiny, and quarantined, it will not be delivered unless D_PASS is set to final_spam_destiny.
dsn_cutoff_level : a message above that level will never trigger a bounce or a reject, whatever spam_destiny is.
quarantine_cutoff_level : a message above that level will not be quarantined.

2.4 Final destinations

Once the message is categorized by Amavis tests (through SpamAssassin, ClamAV, etc), Amavis decides if it should be delivered to user mailbox or not, and if a bounce will be issued.

This is the purpose of $final_virus_destiny, $final_spam_destiny, $final_banned_destiny, $final_bad_header_destiny.

They can take the following values :

D_PASS : mail will be delivered to inbox.
D_BOUNCE : mail will not be delivered, and a delivery status notification will be returned by Postifx to sender (except if the score exceeds the dsn_cutoff level)
D_REJECT : Postfix will answer REJECT to the distant mail server, and the distant mail server may produce a delivery status notification to the user
D_DISCARD : forgive and forget : the mail will not be delivered and the sender is not informed. The mail may be quarantined if the quarantine_cutoff level is not exceeded.

3. Installation

For Amavis : Nothing ! Amavis comes out-of-the-box with SQL storage.
For Mailzu : see Mailzu section.

4. Configuration

4.1 Database

Create an user and a database for quarantine storage :

# mysql -u root -p
mysql> CREATE DATABASE amavis_storage;
mysql> CREATE USER 'amavis_storage'@'localhost' IDENTIFIED BY 'xxxx';
mysql> GRANT ALL PRIVILEGES ON amavis_storage.* TO 'amavis_storage'@'localhost';
mysql> FLUSH PRIVILEGES;

Load the initial schema from Amavis docs (usually located in /usr/share/doc/amavisd-new/ ).

Delete unnecessary tables, as we will be using this database only for mail storage and not for lookups :

# mysql -u amavis_storage -p amavis_storage
mysql> DROP TABLE users;
mysql> DROP TABLE mailaddr;
mysql> DROP TABLE policy;
mysql> DROP TABLE wblist;

Nota Bene : while executing DROP TABLE users, don't be silly, and do not remove mysql users database.

4.2 Amavis

Update your Amavis configuration /etc/amavis/conf.d/50_user :

@storage_sql_dsn = ( ['DBI:mysql:database=amavis_storage;host=127.0.0.1;port=3306', 'amavis_storage', 'xxxx'] );  # none, same, or separate database

# Quarantine SPAM into SQL server.
$spam_quarantine_to = 'spam-quarantine';
$spam_quarantine_method = 'sql:';

# Quarantine VIRUS into SQL server.
$virus_quarantine_to = 'virus-quarantine';
$virus_quarantine_method = 'sql:';

# Quarantine BANNED message into SQL server.
$banned_quarantine_to = 'banned-quarantine';
$banned_files_quarantine_method = 'sql:';

# Quarantine Bad Header message into SQL server.
$bad_header_quarantine_method = 'sql:';
$bad_header_quarantine_to = 'badheader-quarantine';

# Do not store non-quarantined messages info
# You can set it to 1 (the default) to test if Amavis is filling correctly the tables maddr, msgs, and msgcrpt
$sql_store_info_for_all_msgs = 0;

#
# SQL Select statements
#

$sql_select_policy =
   'SELECT *,spamfilter_users.id'.
   ' FROM spamfilter_users LEFT JOIN spamfilter_policy ON spamfilter_users.policy_id=spamfilter_policy.id'.
   ' WHERE spamfilter_users.email IN (%k) ORDER BY spamfilter_users.priority DESC';

$sql_select_white_black_list = 'SELECT wb FROM spamfilter_wblist'.
    ' WHERE (spamfilter_wblist.rid=?) AND (spamfilter_wblist.email IN (%k))' .
    ' ORDER BY spamfilter_wblist.priority DESC';

#
# Quarantine settings
#

$final_virus_destiny = D_BOUNCE;
$final_spam_destiny = D_DISCARD;
$final_banned_destiny = D_BOUNCE;
$final_bad_header_destiny = D_PASS;

# Default settings, we st this very high to not filter aut emails accidently
$sa_spam_subject_tag = '[SPAM] ';
$sa_tag_level_deflt  = 20.0;  # add spam info headers if at, or above that level
$sa_tag2_level_deflt = 60.0; # add 'spam detected' headers at that level
$sa_kill_level_deflt = 60.0; # triggers spam evasive actions
$sa_dsn_cutoff_level = 100;   # spam level beyond which a DSN is not sent
#$sa_debug = 1;

#
# Disable spam and virus notifications for the admin user.
# Can be overridden by the policies in mysql
#

$virus_admin = undef;
$spam_admin = undef;

#
# Enable Logging
#

$DO_SYSLOG = 1;
$LOGFILE = "/var/log/amavis.log";  # (defaults to empty, no log)

# Set the log_level to 5 for debugging
$log_level = 0;                # (defaults to 0)

4.3 ISPConfig policies

Remember that ISPconfig policies are overriding a lot of our configuration in 50_user. In order to majke the quarantine work, you have to reconfigure all the available policies in ISPConfig Panel.

Look at your policies list, you have to change the quarantine settings for every policies :

ISPConfig Mail Spamfilter Policy

When editing a policy, on the Quarantine tab, set the destinations :

ISPConfig Mail Spamfilter Policy Quarantine destinations

If you do not fill something in these fields, Amavis will not store quarantined mails in SQL database, and will just discard it !

These fields correspond to the virus_quarantine_to, spam_quarantine_to, banned_quarantine_to, bad_header_quarantine_to variables in Amavis configuration, and an empty value is overriding those we set in Amavis configuration.

4.4 Test

Send some spam to your server, check if the tables are populated :

mysql> SELECT * FROM maddr;

Check if meta informations are populated :

mysql> SELECT * FROM msgs;
mysql> SELECT * FROM msgrcpt;

And if quarantine is filling :

mysql> SELECT * FROM quarantine;

5. Cleanup !

You should not "setup and forget" your quarantine SQL storage. Messages has to be deleted periodically, otherwise your database will grow forever. Look at the documentaion in /usr/share/docs/amavisd-new to make a cronjob like this :

#!/bin/bash

SQL_HOST="localhost";
SQL_LOGIN="amavis_storage"
SQL_PASSWORD="xxxx"
SQL_DB="amavis_storage"

mysql --user="$SQL_LOGIN" --password="$SQL_PASSWORD" --host="$SQL_HOST" $SQL_DB -e " \
  DELETE FROM msgs WHERE time_num < UNIX_TIMESTAMP() - 30*24*3600; \
  DELETE FROM msgrcpt WHERE NOT EXISTS (SELECT 1 FROM msgs WHERE mail_id=msgrcpt.mail_id); \
  DELETE FROM quarantine WHERE NOT EXISTS (SELECT 1 FROM msgs WHERE mail_id=quarantine.mail_id); \
  DELETE FROM maddr WHERE NOT EXISTS (SELECT 1 FROM msgs WHERE sid=id) AND NOT EXISTS (SELECT 1 FROM msgrcpt WHERE rid=id); \
"

6. Mailzu

I have to admit, Mailzu seems a bit obsolete as I had to patch to make it working with Amavis 3.3 tables. But it still works pretty well for a simple task like reading and releasing quarantine mails.

6.1 Installation

Download the source files at http://sourceforge.net/projects/mailzu/.

62. Patch

The existing Mailzu source code is quite old, and the schema of Amavis SQL tables changed. Download and apply this patch in to make Mailzu work.

6.3 Configuration

I suppose that you know how to spawn PHP with CGI to serve the Mailzu files.

Configure your database login and password in config/config.php :

$conf['db']['dbType'] = 'mysql';
$conf['db']['dbUser'] = 'amavis_storage';
$conf['db']['dbPass'] = 'xxxx';
$conf['db']['dbName'] = 'amavis_storage';
$conf['db']['hostSpec'] = 'localhost:3306';

I am using IMAP login to authenticate in Mailzu. Unfortunately, I had to turn off SSL authentication, as it wasn't working. Here is my configuration :

$conf['auth']['serverType'] = 'imap';
$conf['auth']['imap_hosts'] = array( 'localhost:143' );
$conf['auth']['imap_type'] = 'imaptls';
$conf['auth']['imap_domain_name'] = 'example.com';

Don't forget to set yourself "super" :

$conf['auth']['s_admins'] = array ('me@example.com');

And to set your web uri :

$conf['app']['weburi'] = 'https://example.com/mailzu';

6.4 Configure in-app release

Mailzu can also release quarantined mail. I did not implement this function, but you have to set up the amavisd-release internface on an inet socket on port 9998, instead of the existing unix socket located at /var/lib/amavis/amavisd.sock . Read more.

References

STOP aux adresses gmail, yahoo, hotmail dans les communications professionnelles

Mathieu — Wed, 30 Sep 2015 10:49:00 +0200

Ceci est juste un billet d’humeur sur quelque chose que je trouve de plus en plus exaspérant : la recrudescence des aderses Gmail, Yahoo, ou Microsoft dans des emails soit-disant sérieux, professionnels, etc.

PME, syndicats, gouvernements, fédérations politiques, arrêtez d’utiliser des fournisseurs d’emails grand public, et assumez votre marque ! Vous ne voudriez pas avoir la publicité de votre imprimeur au verso de tous vos tracts ? Alors ne faites pas pareil avec les mails.

Donc NON, ce n’est pas acceptable, à part si vous êtes un particulier, d’avoir une adresse mail en @gmail.com, @yahoo.com ou @outlook.com. En faisant cela vous démontrez :

Votre méconnaissance et/ou votre amateurisme le plus total dans l’utilisation des NTIC.
Qu’aucun de vos amis, agences de com, ou conseillers n’a de connaissances solides sur le sujet (ça fait flipper hein ?).
Que vous aimez tellement les américains que vous êtes prêt à leur transmettre tous vos emails.
Que vous êtes radin au point de ne pas dépenser les 30 euros nécessaires pour obtenir un nom de domaine et une boîte mail chez un registrar.

Avoir une adresse contact@monentreprise.com c’est compliqué ? Non, ça prend 20 minutes maximum pour peu que vous sachiez comment s’appelle votre entreprise.

En bonus, le mail que j’ai reçu ce matin :

Bordel de merde.

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).

# uname -a - Mot-clé - mail

The war on SPAM: an review of the real world tools

Definitions

The goals

Available techniques

Blacklist / Blackhole Lists

Greylist

RFC compliance

SPF and DKIM

Bayesian filters

Spammers techniques

Address guessing

Botnets

Direct to SMTP connections, ignoring MXes

Fake bounces and backsquatting

Real life advices

SSL vs TLS vs STARTTLS

Définitions

Introduction

Numéros de version SSL/TLS

Dénomination incorrecte TLS vs STARTTLS

Numéros de ports SSL/TLS vs plaintext/STARTTLS

SMTP STARTTLS comme une exception

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

Conclusion

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

Réputation (et monitoring)

IPv6

Reverse, PTR, et Hostname

Postmaster, Hostmaster, et RFC

Limites

Diminuer la vitesse d’envoi

DKIM et SPF

Smarthosts

Pour aller plus loin

Set-up SQL quarantine with Amavisd-new and ISPConfig

1. Prerequisites

2. Off-subject generic explanations

2.1 Amavis and ISPConfig policies

2.2 Lookup DSN and Storage DSN

2.3 Levels and cutoffs

2.4 Final destinations

3. Installation

4. Configuration

4.1 Database

4.2 Amavis

4.3 ISPConfig policies

When editing a policy, on the Quarantine tab, set the destinations :

4.4 Test

5. Cleanup !

6. Mailzu

6.1 Installation

62. Patch

6.3 Configuration

6.4 Configure in-app release

References

STOP aux adresses gmail, yahoo, hotmail dans les communications professionnelles

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

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

Requirements

Installation

Set-up the Cluebringer database

Configure Cluebringer

Configure Cluebringer webui

Configure Cluebringer using its webui

Add a policy

Add a quota

Configure Postfix to call Cluebringer for each mail sent

Check your config

Pitfalls, bleeding edges, etc

References

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

Abstract

Postfix : installation and configuration

SASL : installation and configuration

Enable PAM authentication for SASL

Enable SASL for Postfix

Configuration check

Sources