Recently came accross this issue with .NET framework. Cost me quite a lot as you can imagine; basically I spammed tons of people. The MailMessage.To.Clear() doesn’t clear.
After googling a bit I found that I’m not the only one with the problem … here a fellow dev describes more issues
- MailMessage.MailAddressCollection.Clear does not clear the corresponding headers. If you want to re-use an existing MailMessage object for different recepients, you will have to remove the recipients headers yourself (e.g. MailMessage.Headers.Remove(“to”));
- Display names of mail addresses that are not all 7bit characters must be encoded. This works fine with every address type except for “to” addresses. “to” addresses will never be encoded, no matter which Encoding parameter is used for a new MailAddress.
- MailMessage.To.ToString() returns the encoded string only after the message was sent. According to the documentation this should be the case no matter whether the message was already sent or not.
- With MailMessage.Headers there is a bug where headers will have white space in an encoded text. This will lead to non-RFC2047 compliant messages, which will increase the SPAM rating of the message.
- Attachments to a mail message must not have white space in the file name, which is neglected by System.Net.Mail.
- Setting the transfer encoding to TransferEncoding.SevenBit turns into a header text “sevenbit”, instead of “7bit”. “sevenbit” is not RFC compliant and causes problems with some mail clients.
- Quoted-Printable encoding is not limited to a maximum of 76 characters in System.Net.Mail. RFC2045 requires that Quoted-Printable encoding encodes 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.
