smtp.office365.com 主题编码问题 [英] smtp.office365.com subject encoding issues

问题描述

我尝试使用我的专用 office365 帐户发送电子邮件，但主题编码有问题 - 我的所有特殊字符都被替换为?".

I try to send emails with my dedicated office365 account but I have issues with subject encoding - all my special characters are replaced with "?".

我使用的代码非常简单，适用于 smtp-mail.outlook.com 上的不同测试帐户.

Code I use is pretty simple and works fine with different test account at smtp-mail.outlook.com.

using (var mailMsg = new MailMessage(sender, recipient))
{
    mailMsg.IsBodyHtml = true;
    mailMsg.Subject = "Hello world żółćąź";
    mailMsg.Body = body;

    using (var smtpClient = new SmtpClient())
    {
        smtpClient.Credentials = new NetworkCredential("email", "password");
        smtpClient.EnableSsl = true;
        smtpClient.Host = "smtp.office365.com";
        smtpClient.Port = 587;

        await smtpClient.SendMailAsync(mailMsg);
    }
}

我试图设置所有可能的主题编码，但没有运气.同样将主题字符串转换为 Base64String 也不起作用.还尝试设置 Content-Type 标头字符集...我发现的所有分辨率都没有帮助我.也许这是一些仅与 office365 相关的特定 SmtpClient 问题?

I tried to set all possible subject encoding with no luck. Also converting subject string to Base64String also don't work. Also tried to set Content-Type header charset... All of the resolutions I found didn't help me. Maybe this is some specific SmtpClient issue realated only with office365?

而且设置正文编码也没有帮助

And also setting the body encoding did not help

mailMsg.BodyEncoding = Encoding.UTF8;

推荐答案

我的公司帐户遇到了同样的问题.以下是我目前的发现:

I had the same issue with my company's account. Here are my findings so far:

它看起来像 Office365 e- 邮件服务器在几个月前启用了 SMTPUTF8 扩展，这将 System.Net.Mail.SmtpClient 类的行为更改为发送不同的 SMTP 命令和一个不同的数据负载.

It looks like the Office365 e-mail servers enabled the SMTPUTF8 extension a few months ago which changes the behavior of the System.Net.Mail.SmtpClient class into sending different SMTP commands and a different DATA payload.

在我的情况下，邮件在发送到另一个 Office365 帐户时总是可以正常到达，但对于其他帐户，我们收到了来自远程 SMTP 服务器的电子邮件退回通知，该服务器接受了来自 Office365 的中继电子邮件.该错误类似于收到无效数据，预期为 7 位安全字符".因此，我可以想象来自 OP 的远程 SMTP 服务器可能会用问号默默地替换低 7 位范围之外的所有字符.

In my case the message would always arrive fine when sent to another Office365 account but for other accounts we received e-mail bounce notices from the remote SMTP server which accepted the relayed e-mail message from Office365. The error was something like "Invalid data received, expected 7-bit-safe characters". I could thus imagine that the remote SMTP server from the OP might silently replace all characters outside the low 7-bit range with a question mark.

通过 GMail(也有 SMTPUTF8 扩展激活)发送没有问题.

Sending through GMail (which also has the SMTPUTF8 extension active) had no problems.

到目前为止，我还没有调试 SmtpClient 参考源以查看发送到 Office365 服务器的内容.因此，根本原因可能是 SmtpClient 发送了一个好消息，Office365 在中继之前损坏"了该消息，而 GMail 发送的消息没有问题；或 SmtpClient 构建一个坏消息/SMTP 会话，Office365 静默接受并转发到远程 SMTP 服务器，但 GMail 会在中继之前即时接受并修复该会话.

So far I haven't debugged the SmtpClient reference sources yet to see what gets sent to the Office365 server. The root cause could thus either be that SmtpClient sends a good message which Office365 "corrupts" before relaying and which GMail sends on without issue; or SmtpClient builds a bad message / SMTP session which Office365 silently accepts and forwards to remote SMTP servers but which GMail accepts and fixes on the fly before relaying.

不管怎样，我都加入了 MailKit 和 MimeKit 库使用 NuGet 并使用它们来发送我的电子邮件.这些提供 SMTP 协议日志记录以解决问题，并通过正确发送 RFC 6531 中定义的 SMTPUTF8 和 8BITMIME 标志来解决所述问题.它确实需要额外的工作来从通常的 Web.config 或 App.config 位置读取配置，但库可以完成这项工作.

Either way, I pulled in the MailKit and MimeKit libraries using NuGet and use those instead to send my e-mails. These offer SMTP protocol logging to troubleshoot issues and appear to solve the stated problem by properly sending the SMTPUTF8 and 8BITMIME flags as defined in RFC 6531. It does take extra work to read configuration from the usual Web.config or App.config location but the libraries do the job.

如果您想继续使用 SmtpClient，那么您应该联系 Microsoft(这是他们的服务和他们的 .NET Runtime)，或者运行您自己的私有 SMTP 服务器，而无需 SMTPUTF8> 中继到远程服务器的扩展.在后一种情况下，SmtpClient 应正确编码所有标头和有效负载(尽管这确实意味着您可能无法将 International 值用于 DeliveryFormat> 属性，当您想发送给具有国际化电子邮件地址的人时).

If you want to keep using SmtpClient then you should either contact Microsoft (it's their service and their .NET Runtime), or run your own private SMTP server without the SMTPUTF8 extension which relays to remote servers. In the latter case SmtpClient should properly encode all headers and payload (though it does mean that you might be unable to use the International value for the DeliveryFormat property when you want to send to people with an internationalized e-mail address).

这篇关于smtp.office365.com 主题编码问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！