Je configure un environnement de test (actuellement la version 2.4.0.beta4) à la maison sur un mini-PC local sous Ubuntu 16.04 LTS. Je l’ai installé en suivant le guide d’installation en 30 minutes qui est excellent. Il dispose bien d’un nom de domaine complet (FQDN). L’envoi d’e-mails via une boîte mail de mon FAI, en utilisant SMTP sur le port 587 avec une authentification simple, fonctionne parfaitement depuis plus d’un an.
Je viens de réaliser que je n’ai reçu aucune notification par e-mail depuis un certain temps, comme « nouvelle version disponible ». En vérifiant dans Admin > E-mails > Ignorés, je vois que tout est bloqué avec le message :
550-Bad HELO: localhost.localdomain does not exist - Please see RFC 2821
En remontant dans ma boîte mail, cela semble avoir commencé avec la version 2.4.0.beta2. Mais cela pourrait aussi être dû à un changement de politique de mon FAI à peu près à la même époque (fin juillet 2019). Je ne sais pas par où commencer. D’où vient ce localhost.localdomain ? Lors de l’installation, je n’ai eu qu’à modifier app.yml, et ce fichier affiche correctement mon FQDN dans DISCOURSE_HOSTNAME :
Je n’avais jamais entendu parler de Mailgun. Parlez-vous de mailgun.com, le « service d’API pour les e-mails transactionnels » ? Pour vous donner une idée de mon niveau de connaissances : je sais vaguement ce qu’est une API, mais je ne saurais pas comment l’utiliser. Cependant, je pourrais essayer d’utiliser SMTP pour envoyer un e-mail vers une autre boîte aux lettres chez un autre FAI. Je reviendrai vers vous ici demain.
Mailgun fournira vos identifiants SMTP si vous vous inscrivez. Je parie que vous saurez les obtenir simplement en suivant leurs instructions lors de l’inscription.
@itsbhanusharma, @jtbayly Merci ! J’ai réussi à envoyer un message de test via Mailgun. Le problème venait donc d’une nouvelle politique sur le serveur SMTP de mon FAI. Je risque de continuer à utiliser Mailgun.
J’ai effectué d’autres recherches, car je ne peux pas utiliser Mailgun pour notre forum de production.
Dans l’en-tête des e-mails reçus via Mailgun, je vois toujours :
Received: from localhost.localdomain
HELO est la première commande lors d’une session SMTP (source).
Elle devrait ressembler à :
HELO discourse.mydomain.tld
Certains serveurs SMTP, comme Postfix, disposent d’une option permettant de vérifier cela par rapport à l’adresse IP du client. localhost.localdomain se résout à l’adresse IP du serveur SMTP ; elle se trouve probablement dans son fichier hosts. Il semble que les FAI activent cette vérification dans leur lutte contre les spams.
Cela fonctionne avec Mailgun car Mailgun n’effectue pas cette vérification. Mais cela reste un « mauvais HELO ».
À titre de comparaison, j’ai envoyé un e-mail en utilisant un client de messagerie (Sylpheed) sur le même système. Cela fonctionne, même avec la boîte aux lettres de mon FAI, et il semble utiliser :
HELO HL80L
HL80L est le nom de mon réseau local. Ce n’est toujours pas un FQDN, mais du moins cela ne semble pas être un faux évident pour le serveur de mon FAI.
Il est donc possible que cela doive être amélioré. Mais note de non-responsabilité : je ne suis pas un expert en SMTP.
Au fait, j’ai réussi à le faire fonctionner à nouveau via la boîte aux lettres de mon FAI en plaçant un MTA intermédiaire comme relais. Il s’agit d’une application basée sur Postfix sur mon NAS. Elle utilise HELO mydomain.tld.
Je vais vérifier si nous avons cassé quelque chose lors du passage à Debian 10 ou de la mise à niveau vers Rails 6. En attendant, définir DISCOURSE_SMTP_DOMAIN dans app.yml devrait fonctionner. Je pense que nous devrions utiliser par défaut la valeur de DISCOURSE_HOSTNAME si le domaine SMTP n’est pas défini explicitement.
Merci, @gerhard ! DISCOURSE_SMTP_DOMAIN n’était pas présent dans mon app.yml, mais j’ai pris une grande inspiration, je l’ai ajouté et oui, cela fonctionne. Je peux à nouveau utiliser la boîte aux lettres de mon FAI. Du côté de la réception, je trouve dans l’en-tête :
Received: from XXXXXXX.cable.dynamic.v4.ziggo.nl ([XX.XX.XX.X] helo=mydomain.tld)
by smtp7.mnd.mail.iss.as9143.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1)
Entre-temps, j’ai appris que tant la RFC 2821 que son successeur RFC 5321, section 4.1.4 stipulent que :
Un serveur SMTP PEUT vérifier que le nom de domaine fourni dans la commande EHLO correspond effectivement à l’adresse IP du client. Cependant, si cette vérification échoue, le serveur NE DOIT PAS pour autant refuser d’accepter le message. Les informations recueillies lors de la tentative de vérification servent uniquement à la journalisation et au traçage. Notez que cette interdiction ne s’applique qu’à la correspondance entre le paramètre et son adresse IP ; consultez la section 7.9 pour une discussion plus approfondie sur le rejet des connexions ou des messages entrants.
Pourtant, de nombreux MTA comme Postfix et Exim semblent toujours disposer d’un paramètre optionnel pour effectuer cette vérification. Il est possible que les administrateurs l’activent dans le cadre de la lutte continue contre le spam.