Microsoft Exchange Online 5XX之迷

500

这篇文章一开始是《修修补补，又一年？》的一部分，但是没想到的是我与500段错误的缘分并未到处结束。写完《修修补补，又一年？》之后，突然发现我无法登陆Outlook网页端，错误代码为500，内容为“检测到重复的重定向”。

🔭提示：本文提到的Outlook指的是Microsoft Exchange Online（企业版），与面向消费者的Outlook不同。

不过，幸运的是这次的问题很快的解决了，这是由于账户被赋予了太多的管理权限，二者这些权限互相是有冲突的，只需要删除重复权限即可。

研究到这里，我想不如把之前《修修补补，又一年？》中的"5XX之迷"部分单独成文，对内容进行修订与补充，毕竟Microsoft 365的教程实在是比较少，有很多教程已经过时了，而由于微软的体量过大，产品线较大，许多文档实在是不太清楚（以及“巨硬"奇妙的翻译），于是就有了这篇文章，希望对于使用Microsoft 365的用户提供一些帮助。

550 5.0.350

之前，我让朋友发个邮件，附上goodnotes的apk文件给我，结果邮件没有收到，朋友倒是收到了postmaster的退信（未送达报告 NDR）。

其中退信中附上了错误代码：**550 5.0.350。**众所周知，我的邮箱使用的是微软提供的Exchange Online，于是查看了下Exchange管理中心的邮件跟踪，结果很Amazing啊，还好不是邮箱配置问题，还算好处理。

在拿到详细的Mail Report之后，我明白了大概是附件问题，不过为了严谨点，也是为了更好的确定错误点（之前有一次明明是A的问题，结果我误认为是B的问题，结果白搞一个下午），我简单做了下实验：使用朋友的域名邮箱给我发送不同类型的邮件，并查看结果，以便得出更好的结论。

邮件编号	内容	结果	结论
1	不包含附件，只有文字	正常	邮件正常
2	包含附件（Excel文档）	正常	接收附件正常
3	包含附件（较大文件）	正常	与附件大小相关策略无关
4	包含附件 （上述的Goodnotes apk）	无法送达 （报错550 5.0.350）	/

实验结果如上，可见邮箱功能完整，错误问题或许只有Goodnotes apk有关。接下来，在Exchange Online故障排除文档中找到了关于错误代码550 5.0.350有关的介绍，但似乎没有找到啥可用的具体原因。

《修复 Exchange Online 中的 NDR 错误“550 5.0.350”》
5.0.350 是一种泛型包装器，Exchange Online用于各种通常由收件人的电子邮件组织返回的非特定错误。
但是，如果 NDR 还包含 x-dg-ref header is too long，则这是特定解决方案的特定问题。 如果在 Outlook 邮件中使用 RTF 格式，则会出现此问题。 邮件可能至少包含一个附件，其中一个附件可能是还包含至少一个附加电子邮件的电子邮件。
或者，如果 NDR 还包含 Requested action not taken: policy violation detected (AS345)，这是特定解决方案的另一个特定问题。 如果邮件包含附件 (例如，Word文件) 包含 20 个或更多嵌入文件 (例如 Excel 或 Word 文件) ，则会出现此问题。

走投无路的我，在微软的社区中找到了一个问题**《Can't send emails with attachments: Error Message 550.5.0.350 ...file type not allowed by recipient's organization. I believe this is an issue on my side because I can't send attachments to anybody!》**，其中回答内容指向的因素是附件大小的限制，但是在实验中已经确定与附件大小相关策略无关。

是不是我探求的方向错了呢？我又看了一遍Mail Report，在邮件事件中找到了以下这句话：One or more of the attachments in your email is of a file type that is NOT allowed by the recipient's organization‎.（您电子邮件中的一个或多个附件的文件类型是收件人所在组织不允许的。），看到这句话的同时，我想到或许是因为反恶意软件策略，因为APK文件鱼龙混杂，有时APK文件或许不安全，而微软这种大供应商应该会有相关安全性策略。

顺着这个线索，我找到了一篇不在开发者文档，而在社区的杂志：《Email Protection Basics in Microsoft 365: Anti-malware, Safe Attachments, and Quarantine》（Microsoft 365 中的电子邮件保护基础知识：反恶意软件、安全附件和隔离），在这篇文章中，明确指出了错误代码550 5.0.350在特定情况下会由于反恶意软件策略的触发而激活。

在一顿寻找中，最终发现反恶意软件策略在Microsoft 365 Defender 管理中心（微软的产品线是真的多）。在默认策略中将会拦截包含APK等后缀的邮件，并发送NDR给发送者。但为了保证一定的安全性，我们只需要将该策略中的触发行动从<发送NDR>改为隔离，并设置隔离邮件提示。

535 5.7.139

书接上文，处理完550 5.0.350之后，我就开始计划迁移我的网盘所使用的邮箱。根据《如何设置多功能设备或应用程序以使用 Microsoft 365 或 Office 365 发送电子邮件》，我设置好了Cloudreve的邮件，结果又报错了---错误代码：535 5.7.139。

不过这也说明我的网盘服务器已经连接上了微软Outlook的服务器，但是没有身份认证成功。在Microsoft Entra（通过一系列多云标识和网络访问解决方案保护任何标识以及对任何资源的访问）的监视和健康状况-登录日志中，找到了服务器那条活动详细信息，其中指出了失败原因：**Access has been blocked by Conditional Access policies. The access policy does not allow token issuance.**（条件访问策略阻止了访问。访问策略不允许颁发令牌）。

微软的官方诊断平台给的详细原因是由于客户端尝试使用旧式身份验证协议进行身份验证而被禁止登录

作为确保安全性的最佳做法，建议阻止使用旧式身份验证登录。 旧式身份验证协议（如 POP、SMTP、IMAP 和 MAPI）无法强制执行多重身份验证 (MFA)，这使它们成为攻击者攻击组织的首选入口点。
阻止登录的一个或多个策略：Block all legacy sign-ins that don't support MFA

于是我在条件访问策略中找到了<Block all legacy sign-ins that don't support MFA>。在该策略的应用域（指策略使用范围）中排除了自动化账户Auto，但在问题仍然存在，无法正常进行身份验证。

之后在微软的技术社区中，我找到了一个帖子：《535 5.7.139 Authentication unsuccessful》，其中提出了一种解决方法：使用应用密码登陆。

但是值得一提的是在默认设置中，mysignins系统不会提供生成应用密码的功能，于是我又找到了一个文章**《Allow users to create App Passwords in Office 365 | Multi-factor Authentication》。**在该网站中，提到要通过Microsoft 365控制中心的 multi-factor authentication设置页面中执行MFA，这样就可以在mysignins中生成应用密码了，成功！

总结

本文一共提到了三种不同的错误，他们的诱发原因与解决办法如下表：

错误代码	原因	解决方法
500	账户被赋予了太多的管理权限，二者这些权限互相是有冲突	只需要删除重复权限即可
550 5.0.350	反恶意软件策略的触发	将策略中的触发行动从<发送NDR>改为隔离
535 5.7.139	条件访问策略阻止了访问	使用应用密码