Délivrabilité des e-mails Discourse hébergés à iCloud

L’un de nos visiteurs a eu du mal à recevoir l’e-mail de confirmation à son adresse e-mail habituelle.

Les e-mails arrivent apparemment sans adresse d’expéditeur, ce qui leur cause une erreur dans Cloudflare.

Je n’ai pas assez d’accès pour confirmer quoi que ce soit. Une aide ?

J’ai eu quelques minutes pour essayer d’aider, et j’ai tendance à lever un sourcil quand quelqu’un prétend qu’il s’agit d’un « bug ».

J’espère que cela vous aidera.

Il semble que ce ne soit pas iCloud, mais icloud « Masquer mon e-mail ».

Vous pouvez essayer de désactiver le paramètre du site « normaliser les e-mails ». Il s’avère que créer de fausses adresses e-mail pour empêcher Discourse de connaître votre véritable adresse e-mail revient exactement à créer de fausses adresses e-mail pour pouvoir créer des centaines de comptes.

Vous devrez décider si vous souhaitez autoriser les personnes à créer des comptes avec des adresses e-mail qui ne sont pas leur véritable adresse e-mail, semble-t-il.

1 « J'aime »

D’accord, j’ai en fait iCloud+, donc j’ai essayé d’utiliser Masquer mon e-mail, et cela a bien fonctionné. Il s’avère que ce n’est pas non plus le problème. Y a-t-il autre chose que je devrais essayer ?

Si nous pouvons obtenir une explication claire du problème, nous pourrons l’examiner.

par exemple, comment Cloudflare intervient-il dans ce problème ?

Cela signifie que seuls les e-mails envoyés à partir d’adresses e-mail désignées par l’application ou le site Web seront automatiquement transférés à l’adresse e-mail vérifiée définie dans votre compte Apple.

L’envoi à l’e-mail masqué ne fonctionne-t-il que depuis un seul expéditeur ? Comment iCloud gère-t-il cela ? Utilise-t-il le champ “From” ? “Envelope-From” ? “Sender” ?

Pour tous les sites hébergés, nous pouvons consulter les enregistrements de livraison pour les e-mails individuels via l’ID de la file d’attente sortante à partir de /admin/email-logs. Les sites auto-hébergés devront faire de même avec leur fournisseur de messagerie.


J’ai examiné les journaux pour voir si je pouvais comprendre le problème de Dir - tout ce qui suit est anonymisé.

Dans le cas de Dir, trois e-mails envoyés depuis le site Rust ont été livrés :

timestamp,queueid,message
2025-06-29T19:54:24.000Z,60Axxxxxxxx,client=unknown[2602:fd3f:3:112:0:242:ac11:10]
2025-06-29T19:54:24.000Z,60Axxxxxxxx,message-id=<c39588c5-xxxxxxxxxxxxxxxxxxxxxxxxxxx@users.rust-lang.org>
2025-06-29T19:54:24.000Z,60Axxxxxxxx,"from=<incoming+verp-e5bxxxxxxxxxxxxxxxxxxxxxxxxxxxxx@rust-lang.discoursemail.com>, size=4556, nrcpt=1 (queue active)"
2025-06-29T19:54:28.000Z,60Axxxxxxxx,"to=<dxxxxxxxxxxxxxxx@icloud.com>, relay=mx02.mail.icloud.com[17.57.154.33]:25, delay=4.1, delays=0.01/0/0.55/3.5, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as D2xxxxxxxxx)"
2025-06-29T19:54:28.000Z,60Axxxxxxxx,removed
2025-06-29T19:56:20.000Z,2A7xxxxxxxx,client=unknown[2602:fd3f:3:108:0:242:ac11:1f]
2025-06-29T19:56:20.000Z,2A7xxxxxxxx,message-id=<d72180b5-xxxxxxxxxxxxxxxxxxxxxxxxxxx@users.rust-lang.org>
2025-06-29T19:56:20.000Z,2A7xxxxxxxx,"from=<incoming+verp-ea8xxxxxxxxxxxxxxxxxxxxxxxxxxxxx@rust-lang.discoursemail.com>, size=4556, nrcpt=1 (queue active)"
2025-06-29T19:56:23.000Z,2A7xxxxxxxx,"to=<dxxxxxxxxxxxxxxx@icloud.com>, relay=mx02.mail.icloud.com[17.57.156.30]:25, delay=3.4, delays=0.01/0/0.41/3, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as B9xxxxxxxxx)"
2025-06-29T19:56:23.000Z,2A7xxxxxxxx,removed
2025-06-29T20:24:33.000Z,C8Cxxxxxxxx,client=unknown[2602:fd3f:3:104:0:242:ac11:1f]
2025-06-29T20:24:33.000Z,C8Cxxxxxxxx,message-id=<c5db2547-xxxxxxxxxxxxxxxxxxxxxxxxxxx@users.rust-lang.org>
2025-06-29T20:24:33.000Z,C8Cxxxxxxxx,"from=<incoming+verp-9bfxxxxxxxxxxxxxxxxxxxxxxxxxxxxx@rust-lang.discoursemail.com>, size=5589, nrcpt=1 (queue active)"
2025-06-29T20:25:36.000Z,C8Cxxxxxxxx,"to=<dxxxxxxxxxxxxxxx@icloud.com>, relay=mx02.mail.icloud.com[17.57.156.30]:25, delay=63, delays=0.01/60/0.4/2.9, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as DAxxxxxxxxx)"
2025-06-29T20:25:36.000Z,C8Cxxxxxxxx,removed

et aussi des rebonds pour chacun d’eux dans le journal des rebonds, par exemple :

From: Mail Delivery System <mailer-daemon@icloud.com>
To: incoming+verp-e5bxxxxxxxxxxxxxxxxxxxxxxxxxxxxx@rust-lang.discoursemail.com
Message-ID: <20250629195443.xxxxxxxxxxxx@outbound.ms.icloud.com>
Subject: Undelivered Mail Returned to Sender

This is a system-generated message to inform you that your email could not
be delivered to one or more recipients. Details of the email and the error are as follows:


<exxx@actualemaildomain.com>: host route1.mx.cloudflare.net[162.159.205.13] said:
    550 5.7.1 missing or invalid address in From: header. tUExxxxxxxxx (in
    reply to end of DATA command)

Ah. Cela explique comment Cloudflare intervient - c’est le MX réel pour le domaine de messagerie de Dir.

En mettant de côté le résultat risible d’iCloud qui transmet un message de rebond contenant l’adresse e-mail réelle de l’utilisateur à l’expéditeur, il semble que le problème se situe entre iCloud et Cloudflare.

J’imagine qu’iCloud utilise probablement SRS pour encapsuler l’adresse Envelope-From réelle lors de l’envoi à Cloudflare, mais Cloudflare la rejette.

Je ne vois pas comment Discourse pourrait faire quoi que ce soit de différent ici - il fait tout ce qui lui est demandé ? Le problème réside manifestement ailleurs.

2 « J'aime »

Oui, il semble que ce soit une configuration d’e-mail qui ne fonctionne pas. Merci de votre aide pour diagnostiquer le problème !

1 « J'aime »

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.