Comment configurer un hébergement d'email sur un serveur Debian (ou autre).

Les caractéristiques du serveur mail en bref :

• Postfix
• Dovecot
• SALS-auth
• maildrop
• multi-domaine
• multi-utilisateur
• pas de base de donnée
• OpenDKIM
• SpamAssassin

Se base sur le tutoriel Postfix virtual MAILBOX example: separate domains, non-UNIX accounts et Ubuntu.com - PostfixVirtualMailBoxClamSmtpHowto

L'idée est d'avoir un utilisateur (ici vmail) qui va gérer tous les mails. Ils seront stocké selon la hiérarchie suivante :

/home/vmail/
        example.com/
             alice/
             bob/
        domain.net/
             eve/

Avant de commencer, quelques limites importantes à garder en tête

• Tous les mails sont en clair, lisible par l'administrateur du système
• Le choix du mot de passe des comptes se fait via un script bash (pas pratique pour créer un compte pour toute la famille par ex)
• Les mots de passes sont hashés mais non salés (deux mots de passes égaux possèdent le même hash)

A la fin de la configuration, voici les paramètres avec lesquels on pourra authentifier notre adresse email dans le client (Thunderbird par exemple).

• IMAP
  • Serveur: imap.example.com
  • Port: 993
  • Login: alice@example.com
  • Sécurité: SSL/TLS
  • Méthode: Mot de passe chiffré (CRAM-MD5)
• SMTP
  • Serveur: smtp.example.com
  • Port: 465
  • Login: alice@example.com
  • Sécurité: SSL/TLS
  • Méthode: Mot de passe chiffré (CRAM-MD5)

Avertissement: J'ai écrit tout ceci après avoir fait l'installation. Il se peut que j'ai oublié ou me suis trompé quelque part. Si vous repérez un problème, n'hésitez pas à me le signaler. Bien entendu n'exécutez pas de script ou commande sans les avoir comprises. Je vous rappelle que c'est un wiki et qu'un petit malin à pu ajouter un rm -rf / au milieu d'un script pendant la nuit. A bon entendeur…

Pour chacun de vos domaine, créez les records suivants en replaçant l'adresse IP par celle de votre serveur :

example.com    MX 1   smtp.example.com
smtp.example   A      1.2.3.4
imap.example   A      1.2.3.4

Note: je vois partout l'utilisation d'un sous-domaine pour le champ MX mais ne connaît pas exactement la raison. Si tout est sur le même serveur, il me semble que ce n'est pas nécessaire. Sans savoir, respectons les conventions.

Postfix est le serveur SMTP.

Le fichier de config principal est /etc/postfix/main.cf Voici les options importantes (ou à modifier) par rapport au fichier par défaut

# Les domaines depuis lesquels on va recevoir des mails
virtual_mailbox_domains = example.com, domain.net, monsite.org
# Dossier de base de stockage des mails
virtual_mailbox_base = /home/vmail
# C'est là qu'on va stocker la liste des emails
virtual_mailbox_maps = hash:/etc/postfix/vmaps
virtual_minimum_uid = 100
# UID du user et group vmail
virtual_uid_maps = static:5000
virtual_gid_maps = static:5000
virtual_alias_maps = hash:/etc/postfix/virtual
# 5GB de taille max des boites virtuelles
virtual_mailbox_limit = 5368709120

# la liste des ip depuis lesquelles on peut accéder au serveur smtp
# on commente car on va utiliser SASL-auth pour contrôler
# mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128

# 5GB de mailbox max
mailbox_size_limit = 5368709120

# faire du dot addressing
recipient_delimiter = +

# 50MB de piece jointe max, on est plus en 2000
message_size_limit = 52428800

# SASL
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noplaintext,noanonymous
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth-client
smtpd_sender_restrictions = reject_unlisted_sender,reject_unknown_sender_domain,reject_non_fqdn_sender,reject_sender_login_mismatch,reject_authenticated_sender_login_mismatch
smtpd_recipient_restrictions = permit_sasl_authenticated,permit_mynetworks,reject_unauth_destination
smtpd_client_restrictions = permit_sasl_authenticated,sleep 1,reject_unauth_pipelining

# Ajoute une ligne désignant l'utilisateur authentifié dans le header.A décommenter pour lutter contre les emails forgés.
#smtpd_sasl_authenticated_header = yes

# Table d'autorisation d'adresse mail par login SASL
smtpd_sender_login_maps = hash:/etc/postfix/sender_login

# pour refuser les adresses non définies
local_transport = virtual
local_recipient_maps = $virtual_mailbox_maps

# Trick IPv6 pour résoudre le problème de "address not listed for hostname"
import_environment = MAIL_CONFIG MAIL_DEBUG MAIL_LOGTAG TZ XAUTHORITY DISPLAY LANG=C RESOLV_MULTI=on

En plus du port 25 (non protégé), on veut accéder au mail depuis le port 465 via SSL. Décommentez en plus les lignes suivantes dans le fichier /etc/postfix/master.cf. La première ligne concernant SMTP “simple” doit rester décommentée pour accepter les connexions des serveurs n'utilisant pas SMTPS.

smtps     inet  n       -       -       -       -       smtpd
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject

N'oubliez pas d'ouvrir les ports avec iptable

iptables -t filter -A INPUT -p tcp --dport 25 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 25 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 465 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 465 -j ACCEPT

Un complément sur le chiffrement SSL/TLS est présent dans Certificats avec StartSSL.

C'est l'utilisateur qui gère le tout

groupadd -g 5000 vmail
useradd -m -u 5000 -g 5000 -s /bin/false vmail

Note : l'utilisateur vmail est créé de façon à ne pas avoir d'accès shell pour plus de sécurité. En fonction de votre configuration, il est cependant possible que vous ayez besoin d'en activer un.

Un peu plus loin dans le tuto, on a un script qui rempli ce fichier pour vous mais vous pouvez le remplir à la main maintenant.

alice@example.com         example.com/alice/
bob@example.com           example.com/bob/
eve@domain.net            domain.net/eve/

Dans le fichier /etc/postfix/virtual, vous pouvez indiquer des redirections comme

bob@domain.net          bob@example.com
postmaster@example.com  bob+postmaster@example.com

Pour que tout les mails de Bob reçu à la première adresse soit reçu par la deuxième (ça fonctionne aussi pour les adresses sur des domaines externes. Notez que selon la RFC5321 demande d'avoir une adresse postmaster@ existante pour chaque domaine.

Pour générer la base de donnée de vmaps et virtual.

postmap /etc/postfix/vmaps
postmap /etc/postfix/virtual

Et on redémarre le serveur !

systemctl restart postfix

Via le fichier virtual, vous pouvez facilement créer des alias et faire votre service d'email jetables. En vous inscrivant sur un site suspect, ajoutez une ligne nom-site-suspect@example.com compte-principal+nom-site=suspect@example.com et régénérez le fichier via postmap. Tous les emails seront delivres a votre adresse principale et vous pourrez facilement identifier la source de spam et la supprimer en enlevant la ligne ou la redirigeant vers un autre compte.

On teste que la réception de mail fonctionne bien. La commande mail va permettre d'envoyer un email à un utilisateur créé. On veut vérifier que Postfix fonctionne bien et va stocker le mail reçu au bon endroit.

$ mail alice@example.com
Cc: 
Subject: Un email 
Ceci est un email
<ctrl-d>

Le mail doit être dans /home/vmail/example.com/alice/new/

En cas de problème gardez un œil sur le fichier /var/log/mail.info.

Un peu plus poussé. On veut essayer d'envoyer un email vers l'extérieur en exécutant directement des commandes SMTP.

$ telnet localhost 25
ehlo example.com
mail from:alice@example.com
rcpt to:machin@autre.com
data
Bonjour machin, voici ma nouvelle adresse

-Alice
.
quit

Si tout va bien, machin@autre.com doit avoir reçu votre email. Vous serez peut être tenté de tester telnet sur le port 465 (sécurisé) mais en raison de la règle -o smtpd_tls_wrappermode=yes mise dans le fichier master.cf, la connexion sur ce port doit être chiffrée en TLS, ce qui est vachement difficile en telnet (je dirais même impossible).

Si vous testez de vous connecter depuis l'extérieur, vous aurez besoin de vous authentifier. Configurez d'abord Dovecot (suite du tutoriel). Un exemple de communication SMTP avec authentification est donné ici.

TODO remplacer cette section par sieve

Cette section est optionnelle. Le serveur mail fonctionnera très bien si vous laissez Postfix gérer la réception des mails. Seulement, si l'on veut appliquer des filtres, SpamAssassin et autres, l'utilisation de maildrop peut être utile. Si vous utilisez maildrop, le contenu du fichier /etc/postfix/vmaps change de rôle. Il est nécessaire de continuer à lister chaque adresse email présente dans ce fichier (sinon les mail reçu seront rejetés) mais la seconde partie de la ligne (le dossier de destination), n'a plus d'importance.

On veut faire le tri des mails via maildrop (alternative à procmail qui n'est plus maintenu depuis 2001). On va suivre la manière expliquée par postfix.org.

Installez le paquet maildrop.

Dans /etc/postfix/main.cf, ajoutez (ou modifier si déjà présentes), les lignes suivantes

virtual_transport = maildrop
maildrop_destination_recipient_limit = 1
#mailbox_command = /usr/bin/procmail 

Parfois la dernière ligne est décommentée mais il est important qu'on utilise pas procmail ici (ou alors supprimez ce qui se trouve après le =, ça fonctionne aussi). On va ensuite configurer les règles dans /etc/postfix/master.cf. Encore une fois, modifiez les lignes si déjà existantes.

maildrop  unix  -       n       n       -       -       pipe
#  flags=ODRhu user=vmail argv=/usr/bin/maildrop -d ${recipient} 
   flags=ODRhu user=vmail argv=/usr/bin/maildrop /etc/postfix/maildroprc ${domain} ${user} ${extension} ${recipient} ${user} ${nexthop}

La première ligne commentée est la forme habituelle où l'on utilise l'adresse email complète comme nom de dossier. Cependant ça ne correspond pas à notre structure et l'on aimerait être capable d'utiliser des emails sous la forme user+extension@domaine. On va donc utiliser des règles spécifiées dans /etc/postfix/maildroprc en passant les arguments dans l'ordre d'apparition (les inutilisés sont ignorés). Sur certains systèmes ce fichier se trouve dans /etc/maildroprc (changez la commande ci dessus en conséquence) et doit appartenir à vmail:vmail avec un chmod à 600 sous peine de provoquer une erreur.

DEFAULT="/home/vmail/$1/$2"

Le wiki de Gentoo (down ? archive) donne plusieurs exemples de règles de filtrage que l'on peut mettre. Voici par exemple, une que j'utilise pour rediriger les mails venant d'une instance StatusNet dans le sous dossier StatusNet et une autre pour rediriger sur base de l'adresse de la personne qui envoie.

# Redirect to statusnet subdomain
if (/^X-StatusNet-Domain: */)
{
        to $DEFAULT/.statusnet/
}

# Redirect mail from friends to the folder .Personal/
if ( /^From:.*(friend_1|friend_2|friend_3)/ )
{
    exception {
        to $DEFAULT/.Personal/
    }
}

Les dossiers mentionnés peuvent être créé avec la commande suivante:

maildirmake.dovecot /home/vmail/example/alice/.statusnet 5000:5000

Le . devant le nom du dossier permet d'être détecté par votre client de messagerie. Il existe également la commande maildirmake.maildrop cependant celle-ci ne semble pas tenir compte du propriétaire spécifié, et l'on aura besoin de faire un chown -R vmail:vmail après.

Dovecot se charge de IMAP. Installez le paquet dovecot-imapd. Si vous voulez configurer du POP3 (mais franchement, je vois pas pourquoi vous voudriez faire ça), c'est Dovecot qui vous sera utile également (à adapter de la config IMAP).

Le fichier de config principal de Dovecot. On va utiliser des fichiers /etc/dovecot/users et /etc/dovecot/passwd qui fonctionnent comme les fichiers /etc/users et /etc/passwd pour les utilisateurs normaux.

Avertissement la version 2 est nécessaire pour faire fonctionner ces règles (pour les Debian-users, backport est votre ami). Cependant, certaines de ces règles sont dépréciées. Je n'ai pas été capable de trouver la correction, si vous la connaissez → me [at] mart-e [point] be).

## Dovecot configuration file
auth_mechanisms = plain login
auth_username_format = %Lu
base_dir = /var/run/dovecot/
log_timestamp = "%Y-%m-%d %H:%M:%S "
mail_location = maildir:/home/vmail/%d/%n
mail_privileged_group = mail
protocols = imap
ssl_cert = </etc/ssl/certs/dovecot.pem
ssl_key = </etc/ssl/private/dovecot.pem

auth_debug = yes
auth_debug_passwords = yes
auth_verbose = yes
verbose_proctitle = yes
mail_debug = yes
log_path = /var/log/dovecot.log
info_log_path = /var/log/dovecot-deliver.log

passdb {
  args = /etc/dovecot/passwd
  driver = passwd-file
}
service auth {
  executable = /usr/lib/dovecot/auth
  user = root
}
service imap-login {
  chroot = login
  executable = /usr/lib/dovecot/imap-login
  user = dovecot
}
service imap {
  executable = /usr/lib/dovecot/imap
}
valid_chroot_dirs = /var/spool/vmail


auth default {
  user = root
  socket listen {
    client {
      # The client socket is generally safe to export to everyone. Typical use
      # is to export it to your SMTP server so it can do SMTP AUTH lookups
      # using it.
      path = /var/spool/postfix/private/auth-client
      mode = 0660
      user = postfix
      group = postfix
    }
  }
}

auth_mechanisms = plain cram-md5
passdb {
    driver = passwd-file
    args = /etc/dovecot/passwd
}
userdb {
    driver = passwd-file
    args = /etc/dovecot/users
}

## /etc/dovecot/10-auth.conf
!include auth-passwdfile.conf.ext

## /etc/dovecot/conf.d/auth-passwdfile.conf.ext
passdb {
  driver = passwd-file
  args = scheme=CRAM-MD5 username_format=%u /etc/dovecot/passwd
}

Si vous avez plusieurs domaines email, il y a des chances que vous ayez également plusieurs certificats SSL. Si vous voulez éviter les grosses alertes de sécurité lorsque vous accédez à vos emails, vous pouvez modifier la configuration Dovecot pour utiliser des certificats en fonction du domaine.

ssl_cert = </etc/ssl/certs/certificat_global.pem
ssl_key = </etc/ssl/certs/clef_global.key
...
local_name imap.domaine1.org {
  ssl_cert = </etc/ssl/certs/imap.domaine1.org.pem
  ssl_key = </etc/ssl/private/imap.domaine1.org.key
}
local_name imap.domaine2.org {
  ssl_cert = </etc/ssl/certs/imap.domaine2.crt
  ssl_key = </etc/ssl/private/imap.domaine2.key
}

Et pour vérifier que le bon certificat est bien sélectionné: openssl s_client -connect imap.domaine2.org:993 -servername imap.domaine2.org.

Attention que le filtre est fait sur le TLS SNI (Server Name Indication), une fonctionnalité que tous les clients mail n'implémentent pas. Thunderbird le fait, pas K9 mail (Android) par exemple. Dans le cas d'un client qui ne l'implémente pas, vous retomberez sur le certificat global. Il suffit de retirer le -servername imap.domaine2.org dans la commande openssl pour voir le résultat.

Plutôt que de tout faire à la main, on va utiliser des scripts pour créer un supprimer des utilisateurs. Ce script va créer des dossiers, ajouter un alias dans vmaps (n'oubliez pas de supprimer les doublons) et enregistrer l'utilisateur dans les deux fichiers adéquats.

Utilisez simplement avec ./newuser.sh alice@example.com

wget http://paste.mart-e.be/raw/curireqale -O ~/newuser.sh

#!/bin/sh
if [ ! $# = 1 ]
 then
  echo "Usage: $0 username@domain"
  exit 1
 else
  user=`echo "$1" | cut -f1 -d "@"`
  domain=`echo "$1" | cut -s -f2 -d "@"`
  if [ -x $domain ]
   then
    echo "No domain given\nUsage: $0 username@domain"
    exit 2
  fi
  echo "Adding user $user@$domain to /etc/dovecot/users"
  echo "$user@$domain::5000:5000::/home/vmail/$domain/$user/:/bin/false::" >> /etc/dovecot/users

  # Create the needed Maildir directories
  echo "Creating user directory /home/vmail/$domain/$user"
  # maildirmake.dovecot does only chown on user directory, we'll create domain directory instead
  if [ ! -x /home/vmail/$domain ]
   then
    mkdir /home/vmail/$domain
    chown 5000:5000 /home/vmail/$domain
    chmod 700 /home/vmail/$domain
  fi
  /usr/bin/maildirmake.dovecot /home/vmail/$domain/$user 5000:5000
  # Also make folders for Drafts, Sent, Junk and Trash
  /usr/bin/maildirmake.dovecot /home/vmail/$domain/$user/.Drafts 5000:5000
  /usr/bin/maildirmake.dovecot /home/vmail/$domain/$user/.Sent 5000:5000
  /usr/bin/maildirmake.dovecot /home/vmail/$domain/$user/.Junk 5000:5000
  /usr/bin/maildirmake.dovecot /home/vmail/$domain/$user/.Trash 5000:5000

  # To add user to Postfix virtual map file and relod Postfix
  echo "Adding user to /etc/postfix/vmaps"
  echo $1               $domain/$user/ >> /etc/postfix/vmaps
  postmap /etc/postfix/vmaps

 # Add user's mail address to the list of addresses he is allowed to use
  echo "Adding user to /etc/postfix/sender_login"
  echo $1	$1 >> /etc/postfix/sender_login
  postmap /etc/postfix/sender_login
  postfix reload
fi
echo "Create a password for the new email user"
#SWAP THE FOLLOWING passwd LINES IF USING A UBUNTU VERSION PRIOR TO 12.04
#passwd=`dovecotpw`
passwd=`doveadm pw -u $user`
echo "Adding password for $user@$domain to /etc/dovecot/passwd"
if [ ! -x /etc/dovecot/passwd ]
 then
  touch /etc/dovecot/passwd
  chmod 640 /etc/dovecot/passwd
fi
echo  "$user@$domain:$passwd" >> /etc/dovecot/passwd

# Register special mailboxes (Junk, Trash...)
for mailbox in `doveadm mailbox list -u $user@$domain`
do
	doveadm mailbox subscribe -u $user@$domain $mailbox
done


exit 0

La même chose pour la suppression, ./deluser.sh alice@example.com.

wget http://paste.mart-e.be/raw/hewisesido -O ~/deluser.sh

#!/bin/bash
#
# deldovecotuser - for deleting virtual dovecot users
#
if [ ! $# = 1 ]
 then
  echo -e "Usage: $0 username@domain"
  exit 1
 else
  user=`echo "$1" | cut -f1 -d "@"`
  domain=`echo "$1" | cut -s -f2 -d "@"`
  if [ -x $domain ]
   then
    echo -e "No domain given\nUsage: $0 username@domain: "
    exit 2
  fi
fi
read -n 1 -p "Delete user $user@$domain from dovecot? [Y/N]? "
echo
case $REPLY in
 y | Y)
  new_users=`grep -v $user@$domain /etc/dovecot/users`
  new_passwd=`grep -v $user@$domain /etc/dovecot/passwd`
  new_vmaps=`grep -v $user@$domain /etc/postfix/vmaps`
  new_sender=`grep -v "^$1" /etc/postfix/sender_login`
  echo "Deleting $user@$domain from /etc/dovecot/users"
  echo "$new_users" > /etc/dovecot/users
  echo "Deleting $user@$domain from /etc/dovecot/passwd"
  echo "$new_passwd" > /etc/dovecot/passwd
  echo "Deleting $user@$domain from /etc/postfix/vmaps"
  echo "$new_vmaps" > /etc/postfix/vmaps
  echo "Deleting $user@$domain from /etc/postfix/sender_login"
  echo "$new_sender" > /etc/postfix/sender_login
  postmap /etc/postfix/sender_login
  postmap /etc/postfix/vmaps
  postfix reload
  read -n1 -p "Delete all files in /home/vmail/$domain/$user? [Y/N]? " DELETE
  echo
  case $DELETE in
   y | Y)
    echo "Deleting files in /home/vmail/$domain/$user"
    rm -fr /home/vmail/$domain/$user
   ;;
   * )
    echo "Not deleting files in /home/vmail/$domain/$user"
   ;;
  esac
 ;;
 * )
  echo "Aborting..."
 ;;
esac

Et on redémarre !

systemcl restart dovecot

Le principe des filtres anti-spam (dont spamassain est le plus connu) est très simple. Vous partez d’un score de zéro. Lorsque le filtre détecte quelque chose de suspect votre score augmente, lorsque vous avez un comportement que n’aurait pas un spammeur, vous perdez des points. Arrivé à une certaine limite, vous devenez un spam.

Évidement toute la difficulté réside à bien pondérer et trouver les bons critères. Le fait d’utiliser des mots comme « viagra » va vous faire gagner des points. Les spammeurs l’ayant comprit, ils utiliseront v1agra par exemple. Les critères faisant perdre des points ne doivent pas non plus être simples où un spammeur les utilisera pour passer inaperçu.

Il existe également le filtre bayésien plus complexe mais très puissant qui va utiliser des probabilités statistiques. Ce filtre se base sur le contenu du message et l’on a donc pas d’influence coté serveur. Évitez juste de parler de vente de médicament en ligne dans vos messages.

Voici un exemple de résultat SpamAssassin donné par un serveur mail. N'hésitez pas à faire de nombreux tests, tous ne sont pas réglés de la même façon et j'en ai rencontré des beaucoup plus sévères que d'autres.

X-SGSI-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-0.119,	requis 5,
 autolearn=not spam, DKIM_SIGNED 0.10, DKIM_VALID -0.10,	DKIM_VALID_AU -0.10,
 DKIM_VERIFIED -1.00, RDNS_DYNAMIC 0.98,	SPF_HELO_PASS -0.00)

En compte mails gratuits, je n'ai trouvé qu'Opera qui donnait le détail du score SpamAssasin sans être très bavard non plus (mais toujours mieux que Google ou Yahoo).

La résolution DNS classique est de faire correspondre une URL à une IP. Le reverse DNS est le chemin inverse. S'il n'est pas configuré, vous aurez le « bonus » RDNS_DYNAMIC 0.98.

En mettant votre nom de domaine à la place, le problème est réglé. Vous pouvez vérifier que vous avez la bonne valeur via la commande $ dig -x 11.22.33.44 dans le champ PTR. J’ai remarqué que certains serveurs prenaient beaucoup de temps à mettre à jour leurs reverse DNS donc prenez votre mal en patience.

Si vous possédez comme moi plusieurs domaines pointant sur la même IP, sachez qu’il est inutile de mettre plusieurs entrées DNS PTR, cela pourrait être même contre productif (source).

Si votre serveur de mail est amené à utiliser de l'IPv6 il faut aussi mettre à jour de reverse DNS de la ou des adresse(s) IPv6.

SPF pour Sender Policy Framework est une méthode pour certifier l'envoie d'un email et diminuer le risque de tomber dans le dossier spam de certains filtres.

Certains registars comme OVH (ndlr: je ne fais pas de la pub pour eux, juste que c'est le seul que j'utilise et je ne peux pas dire si c'est une pratique courante ou non) proposent de configurer un champ spf automatiquement. Autrement le site openspf.org explique en détail la marche à suivre. Un exemple très simple de record SPF serait:

v=spf1 a mx ~all

Attention, il est important de configurer un reverse DNS pour votre adresse IP vers votre nom de domaine. Certains serveurs mails vérifient cela et autant ne pas en partir.

Attention: SPF casse la redirection ! Si vous envoyez un mail à machin@gmail.com sur laquelle votre correspondant a réglé une redirection automatique vers machin@myopera.com, c'est l'adresse IP de Google qui apparaîtra et pas la votre. La vérification SPF échouera donc. Cependant, ce n'est pas si grave que ça parce que le filtre anti-spam de Opera doit avoir l'habitude de recevoir tous les emails venant de machin@gmail.com qui a des bonnes chances d'être dans une liste blanche. Donc si le serveur du correspondant est bien fait, ça ne devrait pas poser de problèmes.

Comme SPF, DKIM (pour DomainKeys Identified Mail) est un standard pour certifier l'envoie d'un email et diminuer le risque de tomber dans le dossier spam de certains filtres. En comparaison SPF va donner la liste des adresses IP pouvant envoyer un courrier tandis que DKIM va signer les headers avec une clef asymétrique. La clef privée est connue uniquement du serveur mail et la clef publique est publiée dans les DNS. Étant donné que la clé publique est stockée dans une entrée DNS il est recommandé d'activer DNSSEC sur votre zone autrement votre signature sera classé comme insecure.

La méthode utilisée vient de ce tutoriel: Guide to Install OpenDKIM for multiple domains with Postfix and Debian. Il existe dk-filter mais on va utiliser ici OpenDKMI (pas spécialement de raison).

Commencez par installer le paquet opendkim et opendkim-tools. La version dans Debian stable, la 2.0, date de 2010, j'ai donc préféré installer celle venant des backports plus à jour.

Modifiez le fichier /etc/opendkim.conf et ajoutez à la fin les quatres lignes suivantes:

KeyTable           /etc/opendkim/KeyTable
SigningTable       /etc/opendkim/SigningTable
ExternalIgnoreList /etc/opendkim/TrustedHosts
InternalHosts      /etc/opendkim/TrustedHosts

Créez le dossier mentionné (/etc/opendkim) et les trois fichiers contenant ceci.

KeyTable

default._domainkey.example.com example.com:default:/etc/opendkim/keys/example.com/default.private

SigningTable

example.com default._domainkey.example.com

TrustedHost

127.0.0.1
localhost
11.22.33.44

En remplaçant les example.com par votre nom de domaine et le 11.22.33.44 par l'adresse IP de votre serveur, vous pouvez aussi ajouter une IPv6. Créez une ligne par domaine que vous désirez signer dans les deux premiers fichiers.

Pour générer les clefs mentionnées, exécutez les commandes suivantes à répéter et adapter pour chaque domaine que vous possédez

# mkdir -p /etc/opendkim/keys/example.com
# cd /etc/opendkim/keys/example.com
# opendkim-genkey -r -d example.com
# chown opendkim:opendkim default.private

Votre clef privée se trouve dans default.private (chhhht secret) et la clef publique se trouve dans default.txt. Dans la configuration de votre zone DNS pour chacun des domaines, créez un champ TXT pour le sous-domaine selector._domainkey et mettez la valeur indiquée dans le fichier. Mon entrée DNS est par exemple:

selector._domainkey.mart-e.be TXT IN "k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4 GNADCBiQKBgQChUywElHkvIJwgp9B Yce97yhv0ImwK5+2Jm0CHBCfjYpeV7 pSaAh/aYmX9+BJcSupVnJYBPf4DT/A FbV7O6snG6rGf3bnJSHdfyGa7Zq8a/ 7ERdTYo6/W5LJvaenDAxqlWPlgVafQt ncRt+4/iF133FXLpC4VL6NmbMirK0yM RKQIDAQAB"

Spécifiez l'adresse et port sur lequel on va écouter en décommentant la ligne suivante dans /etc/default/opendkim (vous pouvez bien entendu changer le numéro de port à répercuter par la suite).

SOCKET="inet:12345@localhost" # listen on loopback on port 12345

Dans la configuration Postfix (/etc/postfix/main.cf pour ceux qui ne suivent pas), ajoutez maintenant simplement les quatre lignes suivantes :

milter_default_action = accept
milter_protocol = 6
smtpd_milters = inet:localhost:12345
non_smtpd_milters = inet:localhost:12345

Toujours pour Postfix, dans le fichier master.cf, ajoutez le champ smtpd_milters pour chaque type activé (smtp, submission et smtps selon votre configuration). Pour smtps, on obtient donc :

smtps     inet  n       -       -       -       -       smtpd
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
  -o smtpd_milters=inet:127.0.0.1:12345

Redémarrez opendkim et postfix

# /etc/init.d/opendkim restart
# /etc/init.d/postfix restart

Pour vérifier votre signature DKIM, envoyez un email à autorespond+dkim@dk.elandsys.com. Vous receverez un rapport

DKIM Signature validation: pass
DKIM Author Domain Signing Practices: no DNS record for _adsp._domainkey.mart-e.be

Avertissement: cette section n'est encore qu'à l'état de commencement. Fiez vous y avec un regarde critique.

Si les règles ci-dessus évitent de se faire passer pour un spam voyons comment on peut éviter de crouler sous le spam. On va utiliser le célèbre SpamAssassin histoire de faire comme tout le monde.

Sous Debian, installez le paquet spamassassin. On va créer un utilisateur spamd responsable du démon spamassassin.

Note: l'on utilise ici spamassassin en mode client-démon. Il est également possible de faire tourner spamassassin en standalone à la place du couple spamc/spamd. Cela peut être intéressant si vous avez un faible volume de mail (pour éviter de faire tourner un service inutilement). Il faudrait tester à quel point c'est consommateur en ressources.

$ groupadd -g 5001 spamd
$ useradd -u 5001 -g spamd -s /sbin/nologin -d /var/lib/spamassassin spamd
$ mkdir /var/lib/spamassassin
$ chown spamd:spamd /var/lib/spamassassin

Modifiez le fichier /etc/default/spamassassin pour y mettre ceci

ENABLED=1
SAHOME="/var/lib/spamassassin/"
OPTIONS="--create-prefs --max-children 5 --username spamd --helper-home-dir ${SAHOME} -s ${SAHOME}spamd.log"
PIDFILE="${SAHOME}spamd.pid"

Pour que les mails soient vérifiés par maildrop, ajouter dans le fichier de configuration /etc/postfix/maildroprc, avant les règles de filtrage :

# Filter spamassassin pour moins de 25Mo
if ( $SIZE < 26144 )
{   
    exception {
       xfilter "/usr/bin/spamc -u spamd"
    }
}

# Uniquement désirez déplacer les spam dans un dossier
if (/^X-Spam-Flag: YES/)
{
   exception {
      to $DEFAULT/.spam/
   }
}

Le fichier de configuration principal est /etc/spamassassin/local.cf. Lisez le et décommentez les lignes pour activer les options qui vous intéresse. On a par exemple :

# mettre SPAM dans le sujet du message suspecté
rewrite_header Subject *****SPAM*****

# Les headers des mails entrants vont être modifié avec des x-spam
report_safe 0

# le score requis avant d'être considéré comme spam
required_score 6.0

# activer le filtre baysien
use_bayes 1

La documentation SpamAssassin décrit les différentes règles qui peuvent être intéressantes.

Après cela démarrez spamassassin (service spamassassin start) qui va se mettre à scanner vos mails. Surveillez les headers de vos messages ainsi que le fichier de /var/log/mail.log.

Pour accélérer la procédure, vous pouvez compilez vos règles SA (spamassassin 3.2 min) avec la commande sa-compile. Décommentez ensuite la ligne loadplugin Mail::SpamAssassin::Plugin::Rule2XSBody dans /etc/spamassassin/v320.pre.

Vous pourrez désormais, voir passer des superbes échantillons de spam comme celui-ci (efficace n'est ce pas).

Pour faire simple, installez le paquet libmail-spf-perl. Si vous ne possédez pas ce paquet ou que vous aimez compilez tout à la main, on va utiliser CPAN (attention, c'est lent), package manager perl.

Pour que SA vérifie les champs SPF, on a besoin du plugin Mail::SPF::Query.

$ perl -e 'require Mail::SPF::Query'

Si la commande retourne une erreur “Can't locate Mail/SPF/Query.pm in @INC…” , vous avez besoin d'installer le plugin.

$ perl -MCPAN -e shell
...
> install Mail::SPF::Query

Pour que SA vérifie la signature DKIM il faut le paquet libmail-dkim-perl. De plus il est préférable de récupérer les enregistrements DNS des mails que vous vérifiez avec DNSSEC.

Pour débugger SpamAssassin, plusieurs choses peuvent être faites. Tout d'abord, regardez le fichier de log spécifié dans /etc/default/spamassassin. Si vous avez appliqué la config proposé, il se trouvera dans /var/lib/spamassassin/spamd.log.

Un moyen de tester si votre détection de spam fonctionne bien est de vous envoyer un mail contenant : XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X.

Cette chaîne vous donne un “bonus” de 1000 et déclenchera donc le filtrage spam.

Par défaut, le détail de l'analyse n'est affiché qu'en cas de spam. Si vous désirez l'afficher également pour les messages normaux, modifiez le fichier /etc/spamassassin/local.cf.

# decommentez si vous désirez effacer toutes les regles de headers pour utiliser les votres
#clear_headers

# ajouter le rapport en cas de ham
add_header ham Report _REPORT_

# vous pouvez meme en inventer tant que ca respecte le format
# add_headers { spam | ham | all } header_name string
# https://spamassassin.apache.org/full/3.3.x/doc/Mail_SpamAssassin_Conf.html#template_tags
add_header spam Waw c'est du spam _STARS(*)_ ca

Installer le package fail2ban et activer dans /etc/fail2ban/jail.conf les regles postfix, dovecot et sasl.

Une fonctionnalité intéressante dans Gmail est le “plus-addressing”, le fait de pouvoir créer une infinité d'adresse email de type nom+alias@serveur.com. Dans postfix, c'est facilement reproductible (sans doute même activé par défaut il me semble).

Dans le fichier /etc/postfix/main.cf, chercher la ligne suivante (l'ajouter si inexistante)

recipient_delimiter = +

Cela spécifie que le symbole + sera considéré comme délimiteur. Si vous changez le “+” par “.”, “_” ou autre, il deviendra le nouveau délimiteur. Cela vous permet donc de crever des adresses de type nom.alias@serveur.com a la place. Certains formulaires refusant les + ou les retirant automatiquement, vous servez ainsi paré (évidement ne fonctionne pas si votre adresse est prenom.nom@serveur.com).

La page msmtp explique comment envoyer des mails en ligne de commande et avec PHP après avoir configuré ce serveur mail.

Email Security Grader permet de tester son serveur mail. Fait la vérification de SPF, reverse DNS, quelques points de sécurité… Pratique pour s'assurer qu'on a rien oublié. Si vous suivez l'ensemble de ce tuto, vous devriez décrocher le rang de “VERY STRONG SECURITY”, pas mal hein

CheckTLS permet de tester la connexion sécurisée de votre serveur de mail en testant la validité de votre certificat et permet la visualisation complète du déroulement du protocole SMTP.