Body encoding not respected when body is null for System.Net.Mail.MailMessage - by le_top

Status : 

  Won't Fix<br /><br />
		Due to several factors the product team decided to focus its efforts on other items.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 776943 Comments
Status Resolved Workarounds
Type Bug Repros 0
Opened 1/18/2013 1:58:40 PM
Access Restriction Public


One function in my application is sending emails.
Only the attachment is needed, there should be no body or an empty body.  However, the recipient requires that the body announces a specific encoding even when empty.

While setting the body encoding to Encoding.GetEncoding("iso-8859-1"), the resulting mail was still encoded in us-ascii with an empty body.
Only when the body is not null and not empty (""), the requested encoding is used and selected as the 'Content-Type'.
Sign in to post a comment.
Posted by Microsoft on 10/9/2014 at 2:10 PM
Thank you for reporting this issue.

As a workaround to this issue, you can fill the body with space or other character. That should result in correct encoding / transmission of the message.


Networking team
Posted by Helen [MSFT] on 1/21/2013 at 12:09 AM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.
Posted by le_top on 1/19/2013 at 2:56 AM
Thank you for the fast feedback - I did not expect that ;-).
This issue basically made us loose 3/4 weeks of calendar time on the project because it is blocking acceptance of the application by the company receiving the mails in its automated system.
As I know have an explication for the bad encoding (i.e., that it only occurs for empty messages), it may be accepted. If it is not, I'll contact support directly as you suggested.

For further information, I kind of had a workaround which did not get accepted as it produces too many boundaries for the target system.
This implied creating an alternate view in which case the encoding wa applied correctly (and no us-ascii encoding appeared):

I added this:
                var plainView = System.Net.Mail.AlternateView.CreateAlternateViewFromString("", Encoding.GetEncoding("iso-8859-1"), "text/plain");
                plainView.TransferEncoding = System.Net.Mime.TransferEncoding.SevenBit;

So I ended up thinking that this was either a limitation of System.Net.Mail or some obscure option that was missing, until I discovered that with a body set to a space, the encoding was correct without adding the alternate view.
Posted by Macy [MSFT] on 1/18/2013 at 2:51 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(