Outils pour utilisateurs

Outils du site


benevoles:technique:emails

Emails

Généralités

Nous avons deux serveurs de mails postfix :

  • mail.arn-fai.net
  • alsace.tetaneutral.net

Ces serveurs gèrent :

  • Nos listes de discussion ;
  • L'acheminement des messages des démons comme cron ;
  • Des alias (trésorerie, présidence, etc.).

Centralisation des emails des démons avec ssmtp

Toutes les machines (hyperviseurs,VM, LXC) de l'infra utilisent le logiciel ssmtp avec mail.arn-fai.net en mailhub/smarthost afin de pouvoir envoyer les emails de leurs démons sans qu'il y ait un exim ou un postfix ou autre MTA sur chaque machine et afin que les serveurs de mails de l'asso soient clairement identifiés (utile si l'on implémente un jour SPF/DKIM). ssmtp est une implémentation de /usr/bin/sendmail, ce n'est pas un démon, il ne se bind pas sur le port 25 = tranquillité vis-à-vis de l'extérieur.

Configuration ssmtp :

# root=postmaster
mailhub=mail.arn-fai.net
rewriteDomain=arn-fai.net
hostname=<FQDN de la machine, sans le point de la racine :- >
# FromLineOverride=YES

+ dans /etc/ssmtp/revaliases, on ajoute les alias habituels et normalisés afin que le champ « From: » indique toujours l'adresse mail des admins, plus facile pour trier les mails automatiquement avec Sieve, procmail ou autre.

mailer-daemon: admins
postmaster: admins
nobody: admins
hostmaster: admins
dnsmaster: admins
usenet: admins
news: admins
webmaster: admins
www: admins
ftp: admins
abuse: admins
noc: admins
security: admins
root: admins
listmaster: admins
#
#
admins: <adresse_emails_des_admins>

Quelques exceptions à cette règle du ssmtp partout :

  • Le LXC web a un exim. Historique + permettre l'utilisation d'applications web qui utilisent une lib pour envoyer des mails au lieu d'utiliser /usr/bin/sendmail (comme le fait la fonction mail de php) ou équivalent ;
  • Zabbix et Picomon (voir Monitoring ) utilisent tous deux une lib pour communiquer avec le serveur mail et n'utilisent donc pas ssmtp.

Juguler l'envoi de spam suite à une faille de sécu web

Afin d'éviter d'inonder la planète de spam (et se faire griller nos IPs) si l'une de nos applications web se fait trouer, nous positionnons une limite maximale d'emails qui peuvent être envoyés par une adresse IP par jour sur nos deux serveurs d'emails (exception faite des outils de monitoring qui sont conçus pour hurler autant que nécessaire) :

smtpd_client_message_rate_limit = 100
anvil_rate_time_unit = 1d
smtpd_client_event_limit_exceptions = <IP_monitoring>

Configurer un serveur de mails secondaire simpliste

C'est comme cela qu'est configuré notre serveur secondaire, alsace.tetaneutral.net.

Avec Postfix :

relay_domains = exemple.com, example.com

smtpd_relay_restrictions = 
  permit_mynetworks,
  reject_unauth_destination,
  reject_unlisted_recipient,
  reject_non_fqdn_recipient,
  reject_unknown_recipient_domain,
  reject_unverified_recipient,
  check_policy_service inet:127.0.0.1:10023

maximal_queue_lifetime = 30d
bounce_queue_lifetime = 30d

Cette configuration permet de conserver les mails durant un mois en cas de panne du serveur de mail primaire des domaines listés dans $relay_domains.

Concernant les restrictions, on est sur du standard mais il faut noter la présence de « reject_unverified_recipient ». Cette directive permet d'aller vérifier qu'une adresse (ou un alias) est connue du primaire avant d'accepter un mail. La réponse du primaire (positive ou négative) est mise en cache pour $address_verify_cache_cleanup_interval , 12h par défaut.

En fonctionnement normal, cela permet de virer directement le courrier à destination d'adresses inexistantes sans aller consulter le serveur primaire à chaque fois. Si l'on n'utilise pas cette restriction, alors le secondaire va passer son temps à mettre en cache des emails bidons que le primaire lui refusera en boucle, jusqu'à l'expiration du délai de conservation (1 mois dans notre cas). Puis, il tentera d'envoyer un mail d'erreur à l'expéditeur qui, dans le cas d'un spam, n'est généralement pas joignable donc on repart pour 1 mois d'attente avec un mail d'erreur (bounce) en queue !

Lorsque le primaire est en panne prolongée, il faut impérativement désactiver cette restriction : en effet, en absence de liaison avec le primaire, le secondaire n'acceptera pas les emails, il ne les mettra donc pas en queue. Ils seront donc détruit selon le délai configuré sur le serveur de l'expéditeur, ce qui rend notre secondaire totalement inutile !

Important : il faut positionner l'option « reject_unauth_destination » avant l'option « reject_unverified_recipient ». Dans le cas contraire, le secondaire va contacter inutilement la destination indiquée dans le RCPT TO avant de rejeter le mail pour cause de relai interdit ! Donc on vérifie d'abord qu'on est un serveur de backup du domaine indiqué dans le destinataire du mail puis, seulement après, on vérifie que la partie locale de l'adresse existe. Ne pas le faire = risque de se faire backlister par les serveurs que l'on va déranger inutilement !

benevoles/technique/emails.txt · Dernière modification : 2023/07/01 10:32 de ced117