What's new in System.Net.Mail

What’s new in System.Net.Mail

We’ve made a number of enhancements to our SMTP support for .NET 4.0, mostly in the area of Unicode support and increased standards compliance, which is an important aspect in ensuring that legitimate emails do not get flagged as spam, as well as a few other useful features.  In this post I’ll go over these enhancements and what they mean to you as a developer.

Decreased likelihood of being accidentally flagged as spam

Many spammers don’t bother to follow the SMTP protocol correctly in sending their spam, so standards violations tend to be a major factor in calculating spam scores.  In .NET 4.0, we’ve made some significant improvements in how we encode headers and fold long lines of text in order to better comply with the SMTP protocol to reduce the likelihood that your legitimate emails will accidentally be caught by an overzealous spam filter.  You don’t need to change a thing in your code to take advantage of this since it’s all internal to System.Net.Mail.

Increased Unicode support

You can now include Unicode in your custom headers thanks to a new property to the MailMessage class called HeadersEncoding, which allows you to specify what Unicode encoding that custom headers are using so that they can be sent correctly (the default is UTF-8).  HeadersEncoding only affects custom headers that you add; the subject, body, and email address display names can have different encodings that are controlled by other properties in the MailMessage and MailAddress classes.

Clarification on setting header values

While MailMessage allows you direct access to the headers collection some headers being malformed could cause the email message to become corrupted.  The following is a list of headers that you should not set via the headers collection; any values you set for these headers will be silently discarded or overwritten when the message is sent (use the appropriate properties of MailMessage to control these headers):

Bcc, Cc, Content-ID, Content-Location, Content-Transfer-Encoding, Content-Type, Date, From, Importance, MIME-Version, Priority, Reply-To, Sender, Subject, To, X-Priority

Note: if you do not specify an X-Sender header, we will create one for you however we will not overwrite an X-Sender that you set. 

Multiple Reply-To addresses with the new property ReplyToList

We’ve added another new property to MailMessage called ReplyToList that allows you to add multiple Reply-To addresses to an email.  The ReplyTo property has been obsoleted.

Content Disposition time zones

We’ve received some feedback on how ContentDisposition does not allow you to specify time zones in the character formats dictated by RFC 822, such as “GMT” or “PST.”  This functionality was actually obsolete by RFC 2822, which replaces RFC 822, and dictates that an email time should always contain the offset for a timezone (e.g. “-0800” or “+0000”).  However, we will now accept RFC 822 time zone formats and convert them to their semantically equivalent offsets.  Whenever we are unable to determine the correct semantically equivalent offset, it is converted to “-0000” meaning that the time zone is unknown.  This affects strings passed to the constructor or Parameters collection of ContentDisposition.

Mail Address formats

We’ve improved our ability to parse email address strings in the MailAddress class.  Display names that contain Unicode cases and quoted local parts in the address will now be accepted correctly in most circumstances.  If an address does contain an invalid character, the exception message will inform you of what character was invalid.  Remember, you should format your email addresses as “displayname” <local@domain>. 

Authentication

Some legacy clients do not advertise their AUTH mechanisms correctly.  Normally, in the EHLO reply you would expect to see something like AUTH LOGIN NTLM advertising that this server supports LOGIN and NTLM authentication.  Some legacy servers will instead reply with AUTH=LOGIN NTLM which is a violation of the RFC, however we have added support to SmtpClient for these legacy servers so authentication will work correctly should you encounter one.

We hope that you find this new and improved functionality useful for your applications and, as always, feel free to drop us a line if you have any feedback on these features or anything else you would like to see!

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS