Alsace Réseau Neutre

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
====== 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 : 
  * Zabbix et Picomon (voir [[benevoles:technique:monitoring|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 !

<note important>**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 !</note>

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 !