====== 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= # 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: **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 [[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 = ===== 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 !