System.Net.Mail creating invalid emails and eml files? Inserting extra dots in host names

Question

It appears that .NET's SmtpClient is creating emails with an extra dot in host names if the dot was to appear at the beginning of a MIME encoded line (e.g. test.com sometimes shows up as test..com). Example code:

[TestMethod]
public void TestEmailIssue()
{
    var mail = new System.Net.Mail.MailMessage();
    var smtpClient = new System.Net.Mail.SmtpClient();

    mail.To.Add("[email protected]");
    mail.Subject = "Test";
    mail.From = new System.Net.Mail.MailAddress("[email protected]");
    mail.Body = "Hello this is  a short test of the issue:"
             +" <a href='https://test.com/'>https://test.com/</a>: ";

    smtpClient.PickupDirectoryLocation = "C:\\temp\\";
    smtpClient.DeliveryMethod = System.Net.Mail.SmtpDeliveryMethod.SpecifiedPickupDirectory;
    smtpClient.Send(mail);
}

This creates an .eml file that looks like this:

X-Sender: [email protected]

X-Receiver: [email protected]

MIME-Version: 1.0

From: [email protected]

To: [email protected]

Date: 6 Jul 2011 15:55:28 -0400

Subject: Test

Content-Type: text/plain; charset=us-ascii

Content-Transfer-Encoding: quoted-printable

Hello this is a short test of the issue: https://test=

..com/'>https://test.com/:=20

When sending the file, or opening in Outlook (or any other program), the double dots show up (i.e. test..com). Note that if I remove the extra space (in "is a"), that test.com shows correctly since the dot no longer appears at the beginning of the line.

This causes a problem when trying to send website addresses, and we get calls from clients saying this they cannot click our links.

Has anyone else experienced this? How can we resolve this issue other than writing our own encoding?

Iridotomy

That's what we thought! Unfortunately it didn't pop up until the week before we roll-out to a larger group of clients, I'm hopeful that there's an easy fix. – Iridotomy

Nothing that I know of off hand. An ugly fix would be to open+parse each outputted file, look for those errors and fix them. Yuk. – Propagate

This extra '.' is happening for a reason. Here is the line from a Wireshark trace between SmtpClient and an Smtp server: "354 Enter message, ending with "." on a line by itself" It seems Smtp servers use this as an indicator for the end of the message – Andresandresen

Yep, that's why we changed the encoding. – Iridotomy

Answer 1

This is actually per RFC 2821 (4.5.2 Transparency)

Before sending a line of mail text, the SMTP client checks the first character of the line. If it is a period, one additional period is inserted at the beginning of the line.

.Net is just storing the file in "ready to transmit" mode which means that it doesn't have to monkey with the email before sending, instead it can transmit it as is. Unfortunately this format isn't 100% the same as Outlook Express's EML format apparently. You should be able to set the encoding to UTF-8 (or something similar) and that will kick in Base-64 encoding for you.

mail.BodyEncoding = System.Text.Encoding.UTF8;

Clinkerbuilt

Is there a way to read these eml files and decode this encoding correctly? (I'd like to create a dashboard for test environments which shows all the emails) – Wateriness

Natively, using built-in MS classes? Probably not, the storage format is just an internal representation that .Net and IIS/Exchange probably agree on. To the best of my knowledge there's no official spec for this. You can definitely roll your own, this post has some more on doing that along with a library. – Clinkerbuilt

Answer 2

In .Net 2.0

X-Sender: [email protected]
X-Receiver: [email protected]
MIME-Version: 1.0
From: [email protected]
To: [email protected]
Date: 6 Jul 2011 21:29:04 +0100
Subject: Test
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Hello this is  a short test of the issue: <a href=3D'https://test.com/'>https://test.com/</a>:=

It looks like it is wrapping the text at a certain character length per line. I vaguely remember there was an issue in .Net 2.0 where by default it doesn't do this which can cause problems with spam filters.

In fact increasing the size of the message gives the following in .Net 4.0:

X-Sender: [email protected]
X-Receiver: [email protected]
MIME-Version: 1.0
From: [email protected]
To: [email protected]
Date: 6 Jul 2011 21:34:21 +0100
Subject: Test
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Hello this is  a short test of the sssssssssssssssssissue: <a hre=
f=3D'https://test.com/'>https://test.com/</a>:=20

Seems like a bug.

A workaround might be to change the BodyEncoding to something other than ASCII.

Counterpoise

+1 for comparing .Net 2.0 and .Net 4.0 to identify the problem – Graphics

Answer 3

Looking at .NET 4 source code, maybe what you are experiencing has something to do with MailWriter.WriteAndFold method. Also in MailWriter class there is

static int writerDefaultLineLength = 76

variable, meaning character count per line. Maybe because you removed one extra space character, it started working.

Liner