似乎存在许多异常情况：本不应被拒收的邮件却被拒收了。这意味着有时用户发送的支持邮件我们根本收不到。
例如，来自 mac.com 地址的邮件发往我们的支持邮箱时，常因“无正文”（Email::Receiver::NoBodyDetectedError）而被拒收。但这些邮件实际上往往包含正文内容，因此可能存在解析问题。
除了修复导致这些错误拒收的根本原因外，如果能在有新拒收邮件时收到通知，以便我们查看并判断拒收是否合理，那也将非常有益。
这可以表现为：提供一个选项，在所有邮件被拒收时向工作人员发送警报；或者提供一个选项，将所有拒收邮件抄送给工作人员。
否则，如果我们不想遗漏任何 incoming 支持邮件，就必须持续轮询 Discourse 后端中的“已拒收邮件”列表。这既繁琐又没有必要。
我认为最好聚焦于具体示例。你提到“经常”被拒收，你是否注意到邮件内容中存在某种规律？如果这是一个持续存在的问题，我预计所有来自 mac.com 的邮件都会失败。
嗯……这里的“经常”是指“频繁到有点烦人”。我们主要担心的是，用户可能会因为觉得我们的支持团队没有及时回应而感到不满。
我针对所注意到的这些情况寻找过规律。起初我以为问题可能出在 mac.com 处理邮件的方式上，但后来我发现，大约有 30 位使用 mac.com 邮箱地址的用户并未遇到任何问题。
我还曾想过，如果 mac.com 提供网页版邮件客户端，它可能会以非标准的方式处理 HTML 邮件。但我甚至不确定 mac.com 是否真的有网页版邮件客户端。
当我意识到最近一次事件涉及的邮件正文仅包含引用行时，我本以为找到了问题所在，但随后的测试表明，Discourse 对这类邮件的解析完全正常。
我会查阅日志，看看这类情况究竟发生了多少次，并继续寻找规律。我刚才在想，只要 Discourse 偶尔会犯此类错误的可能性存在，发送一封告警邮件似乎就是一个简单有效的保障措施。
我会将调查结果发布在这里。
Mac.com 电子邮件地址实际上就是 iCloud.com 账户。苹果在五到六年前已将 Mac.com 和 me.com 账户迁移至 iCloud。
并没有真正的规律。有 21 个案例中，拒绝的原因不太清楚，或者看起来是错误的。
其中若干案例涉及客户合法的沟通尝试。由 Discourse 发送的拒绝邮件是进入了发件人的垃圾邮件文件夹，还是直接被忽略，目前仍不清楚。
他们发送到了您未处理的地址，例如支持邮箱。
在我看来，只有您提到“无收件人”但实际显示有收件人的情况，看起来可能是一个 bug。一种可能性是，这与他们使用了某些过时且存在问题的邮件客户端有关。
我检查了一些此类（Email::Receiver::BadDestinationAddress）案例，其中许多看起来是客户的合法回复，收件人地址格式为：replies+longidentifier@discourse.site.com。Discourse 发送给发件人的警报邮件提示，他们的邮件是从与相关主题关联地址不同的地址发送的，这可能是原因。但在类似情况下，我仍然希望通知工作人员。
这确实看起来像是一个 bug，虽然我希望能修复它，但我认为这类情况总会发生。因此，除了追查可能的邮件解析 bug 外，向工作人员发送警报邮件也能让我们在此期间提供及时的支持。
我也是这么想的。下次再遇到这种情况时，我会询问客户他们使用的是哪种邮件客户端。
我想表达的观点是，当邮件被拒收时，有时只是用户在寻求支持，并非恶意行为。
当然，Discourse 拒绝的部分邮件确实应该被拒收，但我们不想冒漏掉任何支持邮件的风险，因此只能不断轮询被拒收列表。
与此同时，困惑的发件人被迫寻找其他方式联系我们，例如通过我们网站上的联系表单。
对于大型站点来说，邮件拒收警报可能数量过多而难以处理，但对我们而言，处理这些警报远比应对愤怒的客户要容易得多。
此外，虽然 Discourse 会向发件人发送包含潜在有用信息的拒收邮件，但我认为这些邮件有时会被归入垃圾邮件文件夹，从而进一步让受影响的客户感到困惑。
这确实很麻烦。我认为解决其中一些问题的一种方法可能是 https://meta.discourse.org/t/imap-support-for-group-inboxes/160588。
不过，我不确定如何解决“从错误的邮箱回复”的问题。（而且，我真的很讨厌联系表单——无论我站在哪一边！）
如果用户从一个与邮件发送地址不同的地址进行回复，这是预期行为。
如果我们允许从其他电子邮件地址回复这些邮件，就会使账户容易受到滥用，例如他人冒充其他用户通过电子邮件进行攻击。我们自己的支持消息在 meta 上有时也会遇到这个问题。
如果使用联系邮箱表单，它们通常从某个邮箱发送并设置 Reply-To 头，这意味着我们会遇到与上述相同的问题。
我个人不太确定有什么完美的解决方案——也许团队中的其他人有想法。
是的，正如我所说，拒绝这些回复是有道理的。但我仍然希望在此类情况发生时收到通知。
我之所以提到联系表单，是因为当客户无法通过我们由 Discourse 处理的支援邮箱地址联系我们时，他们被迫寻找其他途径，这并非理想状况。
我不太确定具体该如何实现。你可以关注 /admin/email/rejected，但要获得实际的通知，目前你需要安装一个插件。
我也不确定，所以我才将其作为功能请求发布。
是的，明白了。但每隔几分钟就访问该页面并刷新，似乎效率很低。
插件也可以，但我不明白为什么不能直接将此功能添加到 Discourse 中。在我看来，这似乎是显而易见的。Discourse 已经向站点管理员和工作人员发送各种警报。将设置（邮件拒绝时发出警报）默认设为禁用，我想这对许多站点来说应该适用。
呃，是的。抱歉。
另一个例子：一位客户向支持邮箱发送电子邮件，报告其购买过程中遇到的问题。Discourse 拒绝了该邮件：[Email::Receiver::InactiveUserError]。
我理解 Discourse 拒绝来自非活跃用户的邮件是合理的，但如果我们的支持人员能同时收到警报，他们就可以立即联系客户，解释发生的情况以及可以采取的解决措施。
否则，除非我们频繁轮询被拒绝列表，否则客户将面临两个问题，这两个问题都是由自动化系统导致的，而我们的支持人员对此一无所知。在此阶段的人工干预非常重要，但响应时间可能会出现延迟，因为我们仍然依赖手动检查被拒绝列表。
是否存在某些技术原因，导致管理员无法收到邮件被拒绝的警报？
如果通过电子邮件回复的内容过短（例如“好的”），会导致向用户发送错误的错误提示邮件，我已在此处报告该问题：Wrong Error Message for too short replies for Reply-by-Email
此外，此类拒绝记录并未在 /admin/email/rejected 下显示。如果能在某处记录这些拒绝信息将会更好。