托管 Discourse 邮件送达率至 iCloud

支持
1

我们的一位访客在收到确认邮件到其常用邮箱时遇到了问题。

邮件似乎没有发件人地址，导致他们在 Cloudflare 中遇到错误。

我没有足够的权限来确认这些信息。有什么帮助吗？

2

我花了几分钟尝试提供帮助，而且当有人声称“有 bug”时，我倾向于表示怀疑。

希望有所帮助。

3

听起来不是 iCloud，而是 iCloud 的“隐藏我的电子邮件”。

您可以尝试关闭规范化电子邮件网站设置。事实证明，编造虚假电子邮件地址以阻止 Discourse 了解您的真实电子邮件地址，与编造虚假电子邮件地址以便您可以创建数百个账户的做法完全相同。

您似乎需要决定是否允许人们使用非其真实电子邮件地址的电子邮件地址创建账户。

1 个赞
4

好的，我其实有 iCloud+，所以我试用了“隐藏我的邮箱”，它运行正常。

事实证明，那也不是问题所在。

还有什么我应该尝试的吗？

5

如果我们能清楚地解释问题，我们可以进行调查。

例如：Cloudflare 在此过程中是如何发挥作用的？

这意味着只有应用程序或网站指定的电子邮件地址发送的电子邮件才会被自动转发到 Apple 帐户上设置的已验证电子邮件地址。

隐藏的电子邮件是否只能从单个发件人发送？iCloud 如何处理这个问题？它使用发件人（From）？信封发件人（Envelope-From）？发送者（Sender）？

对于任何托管的网站，我们可以通过 /admin/email-logs 中的发件队列 ID 来查找单个电子邮件的投递记录。任何自托管的网站都需要使用其邮件提供商执行相同的操作。

我查看了日志，看看是否能弄清楚 Dir 的问题 - 以下所有内容都已匿名化。

在 Dir 的情况下，有三封来自 rust 网站的电子邮件被成功投递：

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

以及每个邮件的退信日志，例如：

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)

啊。这解释了 Cloudflare 是如何介入的——它实际上是 Dir 的电子邮件域的 MX 记录。

撇开 iCloud 将包含用户实际电子邮件地址的退信消息转发给发件人的可笑结果不谈，问题似乎出在 iCloud 和 Cloudflare 之间。

我猜测 iCloud 可能是使用 SRS 在发送给 Cloudflare 时包装实际的信封发件人地址，但 Cloudflare 拒绝了它。

我看不出 Discourse 在这里还能做些什么——它不是在做所有被要求的事情吗？问题显然出在别处。

2 个赞
6

是的，这似乎是一个不起作用的电子邮件设置。感谢您帮助诊断！

1 个赞
7

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