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

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("Test@test.com");
    mail.Subject = "Test";
    mail.From = new System.Net.Mail.MailAddress("test@test.com");
    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: test@test.com

X-Receiver: Test@test.com

MIME-Version: 1.0

From: test@test.com

To: Test@test.com

Date: 6 Jul 2011 15:5开发者_高级运维5: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?

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;

In .Net 2.0

X-Sender: test@test.com
X-Receiver: Test@test.com
MIME-Version: 1.0
From: test@test.com
To: Test@test.com
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: test@test.com
X-Receiver: Test@test.com
MIME-Version: 1.0
From: test@test.com
To: Test@test.com
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.

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.