WikiMiNET

La documentation technique et administrative

Outils pour utilisateurs

Outils du site


wiki:mail:presentation

Présentation de l'infrastructure de mail

En bref

Schéma de l'architecture mail de MiNET :

Au niveau DNS

Enregistrement MX

Quand un serveur veut acheminer un email vers l'adresse test@example.com, il va utiliser un champ particulier du DNS, le champ MX (Mail eXchanger). Par, exemple, pour MiNET :

$ dig mx +short minet.net
10 mx1.minet.net.
10 mx2.minet.net.

Les MX ont la même priorité, pour effectuer une répartition de charge entre les deux, tout en permettant à un des serveurs de gérer l'ensemble du trafic en cas de problème, assurant une redondance de la réception des emails.

Les enregistrement mx-main et mx-second anciennement présents correspondaient à une technique nommée nolisting, qui permet de n'accepter que les serveurs prêts à essayer plusieurs serveurs de destination (ce qui n'est pas le cas de certain spammeurs). Cela peut entraîner des problèmes et n'a plus vraiment d'utilité.

Sender Policy Framework

Nous utilisons aussi une technique appelée SPF, Sender Policy Framework, qui permet de vérifier les noms de domaines des mails reçus. Sans ce type de protection, il n'y a aucun filtrage des expéditeurs. Noter que le SPF, comme le DKIM présenté ci-dessous, ne permet de vérifier que le domaine, reste à la charge des administrateurs de ce domaine d'authentifier leur utilisateurs. Les techniques authentifiant les utilisateurs (du type PGP) sont déployées au niveau des clients, et ne sont pas gérées par les serveurs. Si elles offrent de bien meilleures garanties, leur mise en place se révèle assez complexe, et peut demander des efforts aux utilisateurs.

Pour afficher la politique sur les serveurs sortants :

$ dig txt +short minet.net
"v=spf1 mx ~all"
$ dig spf +short minet.net
"v=spf1 mx ~all"

Cela signifie qu'on autorise les serveurs pointés par les entrées MX du domaine minet.net à envoyer des emails pour le domaine minet.net, et qu'on déconseille les autres (~ correspond à un “softfail”, qui évite de détruire le message, en place le temps de vérifier que la mise en place d'un rejet complet ne posera pas de problème). Il y a un champ texte, plus ancien et plus utilisé, et un champ de type spécifique normalisé spf.

Du côté des serveurs qui reçoivent les emails de l'extérieur, on vérifie aussi la politique du domaine (y compris le nôtre !) de chaque email, pour éviter l'usurpation d'identité.

DKIM

Le DKIM est une autre manière d'authentifier un domaine, en signant les mails sortant avec une clé privée, la clé publique se trouvant sur le DNS :

dig txt +short mail._domainkey.minet.net
"v=DKIM1\; k=rsa\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC2Tod8HGcu/qy+RrGCYzGXjdAB3Bjs8tBTcEb9Lk4luic4uenHmAYpsybTjZWCsT27goW+u6fWY7Xbu3Z3uSTGaT54Aycy1AXKZ1MafCO6WAikYmh4ohqFCfLGErgntPhWuqGtTlROkIezQMJFk9TYtkvanRd9EbkZbnJ+NRQSZQIDAQAB"

Il est destiné à être utilisé par les serveurs pour contrôler le domaine d'origine d'un email. Sa présence confirme l'authenticité, mais il faut définir une politique (ADSP) en cas d'absence de signature valide, pouvant aller jusqu'au rejet des emails, ce qui peut avoir de lourdes conséquences en cas d'erreur de configuration. Il n'y a pour l'instant aucune configuration d'ADSP à MiNET, le temps de vérifier le bon fonctionnement de dkim sur nos services.

Ce serait peut-être bien de le faire maintenant, ou alors passer directement à DMARC.

RBL

Le première barrière sont les RBL, des serveurs répertoriant les IP connues pour envoyer du spam. Nous le rejetons dès la connexion aux serveurs de réception de MiNET.

Analyse du contenu : antispam/antivirus

Les techniques présentées au dessus ne portant que sur l'enveloppe du mail, le filtrage du contenu est réalisé si le message n'a pas été bloqué avant, et est expliqué sur la page dédiée.

Pourquoi un serveur mail ? Pourquoi Postfix ?

Les MTA transmettent les emails d'un client (MUA, Mail User Agent) à un MDA (Mail Delivery Agent), qui va distribuer le courrier.

Postfix présente les avantages suivants :

  • Rapide et performant
  • Simple à administrer
  • Aussi sûr que possible, développé avec le principe de séparation des privilèges
  • Robuste et bien documenté (doc officielle)
Configuration générale d'un postfix

La documentation est très bien faite et à jour, ne pas hésiter à s'y référer.

La configuration se fait principalement dans /etc/postfix/main.cf et /etc/postfix/master.cf. Le premier contient la configuration générale du serveur tandis que le second contient la configuration des différents processus internes à Postfix, avec éventuellement des règles selon le port ou l'interface.

Postfix utilise des données externes de plusieurs types (base de donnée, regexp, table hashée, …). Dans le cas des tables, il faut générer le fichier hashé avec la commande

postmap fichier

qui va créer fichier.db.

Les configurations des serveurs ne sont pas détaillées ici, mais les fichiers de configuration sont commentés. Les logs se trouvent dans /var/log/mail.{err,warn,log}.

Pour recharger le configuration après une modification :

/etc/init.d/postfix reload

Pour voir la configuration différente des valeurs par défaut (assez pratique) :

postconf -n

Pour voir la configuration par défaut (en complément de la commande précédente) :

postconf -d

À noter que postconf permet aussi de modifier les configurations en ligne de commande au lieu de modifier manuellement le fichier de configuration.

Configuration du smtp

Le serveur smtp accepte les connexions authentifiées (grâce au ldap, avec sasl) sur l'adresse publique, et toutes les connexions dans les réseaux d'admin. On choisit de forcer le ssl/tls sur les interfaces publiques (soit du STARTTLS sur le port 587, soit du SSL sur le le 465). Il relaie ensuite l'ensemble des mails aux serveurs mx.

On accepte d'envoyer des emails pour d'autres domaines que MiNET, ce qui est raisonnable pour nous dans la mesure où les utilisateurs sont authentifiés, et que le login est ajouté aux headers du mail.

C'est aussi sur le smtp que les emails provenant de MiNET sont signés par DKIM, en utilisant opendkim. Cela permet d'authentifier le domaine (@minet.net) auprès des serveurs des destinataires. Il permet donc d'éviter l'usurpation d'adresse quand il est activé.

Configuration des mx

C'est la configuration mail la plus complexe. Les serveurs MX reçoivent les mails destinés à une adresse du type @minet.net ou @listes.minet.net, et envoient tous les messages venant d'adresses MiNET (si on utilise le SMTP MiNET évidemment).

Sur un serveur de ce type, il est important de ne pas devenir relai de spam ;), et de manière générale d'éviter de laisser rentrer trop de spam. Nous recevons relativement peu de spam, mais il est quand même nécessaire d'être attentif à ces problèmes.

Les messages sortants (sortant d'un vlan privé, par exemple depuis le SMTP) ne subissent aucun traitement et sont envoyés directement (on fait confiance à nos utilisateurs, qui sont authentifiés et à nos serveurs dans les vlan d'admin, protégés par le VPN).

Le première barrière sont les RBL, des serveurs répertoriant les IP connues pour envoyer du spam. Nous le rejetons dès la connexion aux MX (en pratique au RCPT TO). Nous utilisions avant le service postgrey, qui effectue du greylisting, c'est à dire demander à l'expéditeur de renvoyer son message plus tard, partant du principe qu'un spammeur ne prendra pas cette peine. Cela induit des retards qui peuvent être important, et est de moins en moins efficace, il n'est donc plus utilisé. Les messages reçus sont envoyés sur spam, et scannés par amavis, qui utilise un antivirus et un antispam basé sur le contenu du message (filtrage bayésien). Il est ensuite traité (envoi sur imap par LMTP, sur les listes, …).

Divers

Débloquer des mails dans la queue

Après une panne, par exemple serveur de spam down et donc tous les mails mis en attente, il peut être utile de vouloir libérer tous les mails qui sont dans la queue et que l'on souhaite faire partir tout de suite sans attendre que Postfix le fasse tout seul une fois.

Pour voir ce qui est dans la queue :

mailq

Ensuite on choisit (étape non obligatoire) de faire un requeue de tout les messages (très utile si on a par exemple changé des règles de transport et qu'on souhaite les faire appliquer aux mails dans la queue)

postsuper -r ALL

Flush de la queue = Libération des mails :

postqueue -f

Il pourra vous arriver de supprimer des mails qui sont bloqués pour connexion refusée et dont vous voulez vous débarrasser : adresse erronée, etc:

postsuper -d mailID

Pour tout supprimer (fonctionne pour l'alerte Zabbix: Postfix mailq is heavy)

postsuper -d ALL

Traitement de Queue mail Postfix

Ajouter un alias pour une mailing list

Sur les 2 mx :

  • modifier /etc/postfix/virtual_minet
  • créer /etc/postfix/virtual_minet.db avec postmap /etc/postfix/virtual_minet
  • /etc/init.d/postfix reload

Monitoring Zabbix

Le monitoring utilise pflogsumm (analyseur de log postfix), et un template Zabbix particulier. Pour le mettre en place :

apt-get install logtail pflogsumm zabbix-sender

Dans la crontab :

0/30 * * * * root   /usr/local/sbin/zabbix-postfix.sh

Le fichier en question :

#!/bin/bash
 
MAILLOG=/var/log/mail.log
DAT1=/tmp/zabbix-postfix-offset.dat
DAT2=$(mktemp)
PFLOGSUMM=/usr/sbin/pflogsumm
ZABBIX_CONF=/etc/zabbix/zabbix_agentd.conf
ZABBIX_SERVER=192.168.102.78
DEBUG=0
 
function zsend {
  key="postfix[`echo "$1" | tr ' -' '_' | tr '[A-Z]' '[a-z]' | tr -cd [a-z_]`]"
  value=`grep -m 1 "$1" $DAT2 | awk '{print $1}'`
  [ ${DEBUG} -ne 0 ] && echo "Send key \"${key}\" with value \"${value}\"" >&2
  /usr/bin/zabbix_sender -z $ZABBIX_SERVER -c $ZABBIX_CONF -k "${key}" -o "${value}" 2>&1 >/dev/null
}
 
/usr/sbin/logtail -f$MAILLOG -o$DAT1 | $PFLOGSUMM -h 0 -u 0 --bounce_detail=0 --deferral_detail=0 --reject_detail=0 --no_no_msg_size --smtpd_warning_detail=0 > $DAT2
 
zsend received
zsend delivered
zsend forwarded
zsend deferred
zsend bounced
zsend rejected
zsend held
zsend discarded
zsend "reject warnings"
zsend "bytes received"
zsend "bytes delivered"
zsend senders
zsend recipients
 
rm $DAT2

Il suffit ensuite d'appliquer le template Template_App_Postfix à l'hôte.

Firewall

Ces services sont sujets à des normes particulières de sécurité. Si vous souhaitez ajouter un serveur MX, veuillez lire [[wiki:cluster:proxmox:firewall | cette page

Problème de mémoire et queuing MX

Il arrive assez fréquemment que les queues des MX soient trop pleine. Il faut alors les vider avec les commandes précisés plus haut. Ce problème va de pair avec une saturation swap. Les queues tentent de réenvoyer les mails et utilisent donc des ressources swap. Il suffit alors de vider les queues et de swap off les swaps des MX et de les réactiver.

wiki/mail/presentation.txt · Dernière modification: 2020/06/27 18:16 (modification externe)