smtp.office365.com subject encoding issues

问题

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

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);
    }
}

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;

回答1:

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

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.

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.

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

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.

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.

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).

回答2:

Set the encoding of the mail message so one that supports the characters you use, since the default is us-ascii:

mailMsg.BodyEncoding = Encoding.UTF8;

回答3:

We had the same Issue with Office365 SMTP Server, using vmime library. We solved it by disabling SMTPUTF8, thus always encoding non-ascii characters.

As stated above by JBert, the same protocol works with GMail SMTP servers.

来源：https://stackoverflow.com/questions/49818665/smtp-office365-com-subject-encoding-issues

标签

office365

smtpclient

mailmessage