Serveur mail - Problèmes d'envoi possibles?

[laurentS]

Faire tourner son propre serveur mail semble être de plus en plus difficile, parce que les serveurs des gros domaines (google, etc...) ont apparement tendance à classer tous les emails venant de serveurs "indépendants" comme spam.

Il faudrait rechercher ce qui est possible, afin de ne pas se trouver dans une situation où l'on ne peut plus envoyer de mails, vu leur role central pour la plateforme.

[laurentS]

Quelques tips ici https://alaveteli.org/docs/running/server/#email-configuration

[laurentS]

Checklist (merci Gandi!):
Verifier les points problématiques avec par exemple: https://www.hardenize.com

Serveur mail

• remplacer exim par postfix, bien meilleur qu'exim, plus aisément configurable et débugable
• avoir des certificats SSL/TLS (X.509) valides et bien suivre leur renouvellement (ajout de sonde de monitoring ?)
• préférer les protocoles TLSv1.2 et TLSv1.3
• préférer les ciphers de haut niveau voir très haut niveau
• si possible, disposer d'un antispam type rspamd, très performant, mais très moustache carrée quand il est à peine configuré, il faut bien le tuner, mais ça vous évitera des blagues, bien entendu, pour ne pas jeter de message, il est nécessaire de les conserver ou d'ajuster les scores pour qu'ils passent tout de même, puis de voir au fur et à mesure
• configurer de très bonnes règles en entrée comme en sortie pour ne pas qu'on se serve, par le biais de l'applicatif ou directement du serveur de mail, de notre serveur de mail pour spammer la planète
• activer les protocoles SMTP (port 25), SMTP/S (port 465) et Submission (port 587) pour être bien propre
• activer le STARTTLS, la mandatory encryption ainsi que l'opportunistic encryption, comme cela, même en cas de merdouille sur les certificats SSL, les mails seront chiffrés de bout en bout

DNS

• déclarer un enregistrement de type CAA correspond à l'autorité de certification vous ayant délivré les certificats TLS/SSL (X.509)
• activer DNSSEC au niveau du nom de domaine (faisable en un clic avec Gandi LiveDNS sans avoir à gérer les clés, pratique)
• cela afin de pouvoir activer DANE (enregistrement de type TLSA)
• avoir un enregistrement de type SPF contenant uniquement les MX du domaine (si le domaine est dédié à cet applicatif) sinon contenant les ipv4/ipv6 du serveur
• avoir un enregistrement DKIM côté DNS et signer les mails en sortie côté serveur de mail, c'est très apprécié par tous les providers, voir obligatoire

application (alaveteli)

• mettre en place un backup de tous les mails entrants/sortants, eventuellement sur une autre boite mail

[pzwsk]

J'imagine que c'est un pb récurrent pour les plateformes alaveteli. Ça vaudrait le coup d'en parler à Oslo ou avant.

…

On Mon, Sep 2, 2019 at 2:02 PM Laurent Savaete ***@***.***> wrote: Faire tourner son propre serveur mail semble être de plus en plus difficile, parce que les serveurs des gros domaines (google, etc...) ont apparement tendance à classer tous les emails venant de serveurs "indépendants" comme spam. Il faudrait rechercher ce qui est possible, afin de ne pas se trouver dans une situation où l'on ne peut plus envoyer de mails, vu leur role central pour la plateforme. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#6?email_source=notifications&email_token=AASEVRYD4MOBXNZ2G4KYTGTQHT6EPA5CNFSM4IS4YEM2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HIYVBXQ>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AASEVR5ZEFI7JYDEOYPFE53QHT6EPANCNFSM4IS4YEMQ> .

[laurentS]

TLSA / DANE

Notes sur le process pour l'enregistrement TLSA pour DANE. Il s'agit d'un enregistrement DNS (il faut avoir mis en place DNSSEC avant) qui confirme que le certificat SSL est bien celui qu'on veut, et pas un faux produit par un "man in the middle".
Il faut renouveler cet enregistrement sur le DNS à chaque fois que le certificat est renouvelé, c'est-à-dire tous les 3 mois pour notre certificat letsencrypt.

Procédure A (sans renouvellement de la clé privée, plus simple que B):

• certbot renew --reuse-key
  C'est tout! L'enregistrement TLSA DANE est basé sur la clé privée, la commande ci-dessus la conserve, ce qui permet du coup de garder le même enregistrement DANE sur le DNS. Idéalement, il faudrait utiliser la procédure B ci-dessous une fois par an environ, histoire de renouveler la clé privée aussi (et en cas de clé compromise).

Procédure B (avec renouvellement de la clé privée):

• voir A.4. Handling Certificate Rollover dans le RFC pour la source
• Il faut télécharger le certificat depuis letsencrypt (mais pas l'installer de suite)
• Générer le nouvel enregistrement TLSA avec cet outil en ligne paramètres:
  • usage field: 3 - DANE EE,
  • Selector Field: 1 - SPKI,
  • Matching type field: 1 - SHA-256 (ce sont les paramètres par défaut),
  • Copier l'ensemble du certificat (y compris le BEGIN CERTIFICATE et END CERTIFICATE) dans le champ suivant.
  • Port number 25,
  • Transport TCP,
  • domain name: madada.fr
• NE PAS SUPPRIMER l'enregistrement TLSA existant
• Copier l'enregistrement DNS dans le DNS record de gandi tel quel (ça ressemble à _25._tcp 10800 IN TLSA 3 1 1 4374880637dea65fd36877e8c569653d263ea4db245de46ef3fa7339b8d42cc2). On a donc 2 enregistrements TLSA à ce stade. Valider, et laisser propager le DNS.
• attendre au moins 2 fois le TTL du DNS (a priori 1800 secondes x 2, donc 1 heure?)
• basculer sur le nouveau certificat
• supprimer l'ancien enregistrement TLSA du DNS zonefile

Voir ce blog https://blog.apnic.net/2017/01/06/lets-encrypt-dane/ pour détails (bien lire le Postscript à la fin, qui contredit un partie du texte)

Resource additionnelle pour simplifier la rotation avec letsencrypt, voir la fin de la discussion (vers sept 2018):
https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022/19 (c'est la procédure A)

Pour vérifier:

• https://www.huque.com/bin/danecheck-smtp
• https://en.internet.nl/
  (les 2 ne sont pas toujours d'accord, semble-t-il)

[laurentS]

Notes concernant DKIM

• c'est un mix de réglages DNS et serveur
• je l'ai mis en route avec opendkim qui semble être le standard ubuntu à ce jour
• le code ansible montre ce que j'ai fait, vaguement inspiré de cette page (qui n'est plus tout à fait à jour)
• la clé privée est stockée dans les variables encryptées dans le vault ansible

[laurentS]

Notes sur le SPF

il est reglé pour marquer notre serveur comme seule source d'emails valide pour le domaine madada.fr (le mx dans l'enregistrement), avec une validation stricte (-all), donc une tentative d'envoi d'email @madada.fr depuis un autre serveur sera rejetée.