Distribution des mails à l'extérieur

Les dispositifs officiels

SPF

Sender Policy Framework, un enregistrement DNS à ajouter sur tous les domaines envoyant des mails pour indiquer les machines autorisées à le faire :

tila.im.		1800	IN	TXT	"v=spf1 mx -all"

Cet enregistrement indique que les mails envoyés depuis les MX du domaine tila.im sont valides.

DKIM

DKIM est une norme de signature cryptographique permetant d'assurer que les mails sont bien signés avec la clef inscrite dans le DNS du domaine.

La mise en place sur Tila.im est la suivante :

Enregistrement DNS de la clef publique sur tous les domaines envoyant des mails :

tila2013._domainkey.tila.im. 10800 IN   TXT     "k=rsa; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3YPDzFrczktLo7tTpUyyxeZjZyroMbZ+uYYzJmhrfFDoDOwtU3k8BkicPE5xAhYjZ7zPxTE8sCdmJAMH2K6M1e+qfkvtGoObKQQ/FJg07Hj3KH1dDow0dgVQ5hxi40tF2WCgWjBZ6OFQg8ux1AKeyQxBaqis7Fo9Im0XUgizpxQIDAQAB"

OpenDKIM est installé sur Tila.im, et postfix est configuré pour lui envoyer les mails sortants pour signature, à l'aide de ces entrées dans main.cf :

## Envoi, signature DKIM, puis passage par OpenDMARC ##
milter_default_action = accept
milter_protocol = 6
smtpd_milters = inet:127.0.0.1:8891
non_smtpd_milters = $smtpd_milters

DMARC

Domain-based Message Authentication, Reporting and Conformance permet de donner des indications sur ce qu'un destinataire doit faire si un mail ne respecte pas SPF et DKIM. C'est un enregistrement DNS qui doit être sur tous les domaines envoyant des mails. Exemple pour Tila.im :

_dmarc.tila.im.		10800	IN	TXT	"v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:dmarc@tila.im"

p indique que faire en cas d'échec avec le domaine principal, sp en cas d'échec avec un sous-domaine. Ici, dans les deux cas, on recommande la quarantaine (marquage comme spam). rua permet d'indiquer une adresse mail où les destinataires peuvent envoyer des rapports DMARC.

Les dispositifs spécifiques à certains fournisseurs de mails

Microsoft

Concrètement, ça ne fonctionne pas bien chez Microsoft (hotmail, live, outlook…). On peut en théorie se créer un compte sur leur programme Smart Network Data Services. Ça n'a pas un effet de fou forcément…

Voir aussi leur doc sur Outlook.com Postmaster. Cette doc indique bien qu'il faut respecter SPF, DKIM et DMARC.

Google

Globalement, les mails arrivent bien chez Google si l'on a déployé SPF, DKIM et DMARC. En plus de cela, on peut ajouter ses domaines sur Google Postmaster Tools. Cela consiste à ajouter un enregistrement TXT dans le DNS avec une clef donnée par Google. Cela permet également d'avoir des stats sur les mises en spams chez Google.

Les fournisseurs qui demandent une distribution lente

Un certain nombre de destinataires de mails veulent qu'on ne leur envoie pas trop de mails d'un coup. Concrètement, sur Tila.im, c'est configuré à l'aide d'un transport slow de postfix.

Dans master.cf :

slow unix - - n - 5 smtp -o syslog_name=postfix-slow -o smtp_destination_concurrency_limit=3 -o slow_destination_rate_delay=4

Dans main.cf :

# on défini une transport_map :
transport_maps = hash:/etc/postfix/transport
# on configure le transport slow :
slow_destination_recipient_limit = 20
slow_destination_concurrency_limit = 10
slow_destination_rate_delay = 1s

Et dans /etc/postfix/transport :

# ne pas oublier postmap /etc/postfix/transport après modif
# slowdown traffic for this domains:
orange.fr                       slow:
orange.com                      slow:
wanadoo.fr                      slow:
sfr.fr                          slow:
yahoo.fr                        slow:
free.fr                         slow:
reading.ac.uk                   slow:
me.com                          slow:

Certainement d'autres domaines peuvent avoir besoin de passer par slow. Ne pas hésiter à lire les logs pour vérifier ça.

Les listes noires

On peut tester si on est sur une liste noire, comme par exemple sur MXToolBox.

Backscatters

L'été 2020, Tila.im s'est retrouvé dans la liste des backscatters, c'est-à-dire des serveurs qui renvoient des mails d'information suite à une action. Si c'est un faux mail qui a demandé l'info, la personne dont l'adresse a été usurpée reçoit un mail non-désiré. Mailman est une source probable de ce problème.

Les mitigations mises en places :

Script pour configurer toutes les listes pour refuser de nouveaux abonnements, ne pas renvoyer de mails d'infos quand un abonnement ne fonctionne pas et supprimer les alias de commandes de liste pour les listes les utilisant (à relancer à chaque création de liste) :

#!/bin/sh
  
#
# part 1: fix mail list options
#

#doc : https://wiki.list.org/SEC/Controlling%20spam

f=`mktemp`

# disable response to post requests
echo "respond_to_post_requests = False" > $f
# ban all adresses to subscribe
echo 'ban_list = ["^.*$"]' >> $f
# don't try to tell someone that it's subscription doesn't work
echo "bounce_you_are_disabled_warnings = 0" >> $f

# apply to all lists
for list in `list_lists --bare`
do
        config_list -i $f $list
        echo "Config applied to $list"
done

rm $f

#
# part 2: fix mail list aliases
#
virtual=/var/lib/mailman/data/virtual-mailman

cp $virtual $virtual.bak

echo "remove mail command aliases"
cat $virtual | \
        grep -v '.*-bounces' | \
        grep -v '.*-confirm' | \
        grep -v '.*-join' | \
        grep -v '.*-leave' | \
        grep -v '.*-request' | \
        grep -v '.*-subscribe' | \
        grep -v '.*-unsubscribe' > $virtual.new

mv $virtual.new $virtual

postmap $virtual

Suppression des commandes mails pour les listes sur des sous-domaines spécifiques, dans le fichier /etc/postfix/transport :

/^.*-join@.*$/                  discard:
/^.*-subscribe@.*$/             discard:
/^.*-request@.*$/               discard: