Bug in System.Net.Mail? (.NET 4) RRS feed

  • Question

  • After upgrading to .NET 4, our users started getting really weird errors with attachments. It seems that if the name of the attachment contains characters that forces it to be encoded (like åäö) AND the name is long (say 30-40 characters), the attachment is corrupt (since the mail client can't identify it properly. It becomes a txt-file with a garbled name and the BASE64-encoded content inside..

    We've tried different name-encodings for the attachments, but it doesn't seem to do much good.

    When I take a look at the mail source the attachment-part starts like this:

    Content-Type: application/octet-stream;

    Content-Transfer-Encoding: base64
    Content-Disposition: attachment


    Can anyone think of a solution, or a workaround? I'd prefer not to switch to another mail component, but we might have to :/

    Thursday, April 29, 2010 12:18 PM

All replies

  • Anyone?
    Thursday, May 6, 2010 2:01 PM
  • Hi,


    I am receiving the exact same error. It seems like all attachments that have special norwegian characters in the filename end up having this weird encoded attachment name that leads to these problems.


    I have tried setting Attachment.NameEncoding=Encoding.UTF8 and Attachment.ContentType.CharSet="UTF-8", but without much success.


    Has anyone found a solution to this problem?



    Friday, June 25, 2010 1:11 PM
  • I'll give myself (and William) a bump, since this really is a problem
    Tuesday, July 20, 2010 6:09 AM
  • Hey Anders.  Yes we are aware of this problem and have already addressed it for future releases.  To verify that we have correctly addressed your specific issue could you please provide the original attachment name used to generate the above output?

    In .NET 4.0 SmtpClient now implements the RFC line length limits (76 chars).  This required extensive changes to the encoding process and we have uncovered a few issues like the one you describe.

    In your case, yes, there is an issue with non-ascii attachment names that would be encoded to more than 41 utf-8 bytes (Encoding.UTF8.GetByteCount(fileName);).  In this scenario the names are encoded twice and may have extra line breaks in them.  The only known workaround is to limit the length of non-ascii file names.

    However, in testing, the problem was limited to file names only, while the attachment content was fine.  Now that I go back and test even longer names on the original code, I do see potential issues where the extra line breaks in the name may cause the receiving mail client to not properly decode the attachment body.  This is no longer a problem in the corrected code.

    These issues have been corrected for future a release.  In the meantime if shorter attachment names are not an option please contact Microsoft Support directly for additional support. (http://support.microsoft.com)

    Friday, July 23, 2010 5:23 PM
  • Hi,

    You can find a workaround below. The text is in german (but the code is not ;-)


    BTW: Here's what RFC 2045 states:

    The Quoted-Printable encoding REQUIRES that encoded lines be no more than 76 characters long.  If longer lines are to be encoded with the Quoted-Printable encoding, "soft" line breaks must be used.  An equal sign as the last character on a encoded line indicates such a non-significant ("soft") line break in the encoded text.



    Monday, July 26, 2010 1:45 PM
  • This is still a big Issue
    Thursday, March 1, 2012 5:13 PM
  • It seems like the issue is fixed in .NET 4.5 but I would really like to know if its going to be applied to  .NET 4.0 as well without needing to install a hotfix on all the servers that currently runs 4.0.

    Any ideas? Havent been able to find any information about it.
    • Edited by Wendelstam Wednesday, September 12, 2012 12:36 PM
    Wednesday, September 12, 2012 12:35 PM