System.Net.Mail создает недействительные электронные письма и файлы eml? Вставка дополнительных точек в имена хостов

Похоже, что .NET SmtpClient создает электронную почту с дополнительной точкой в ​​именах хостов, если точка должна появляться в начале строки с кодировкой MIME (например, test.com иногда появляется как test..com). Пример кода:

[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);
}

Это создает файл .eml, который выглядит следующим образом:

X-Sender: [email protected]

X-Receiver: [email protected]

MIME-Version: 1.0

От: [email protected]

Кому: [email protected]

Дата: 6 июл 2011 15:55:28 -0400

Тема: Тест

Content-Type: text/plain; Charset = US-ASCII

Content-Transfer-Encoding: quoted-printable

Здравствуйте, это короткий тест проблемы: https://test =

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

При отправке файла или открытии в Outlook (или любой другой программе) появляются двойные точки (т.е. test..com). Обратите внимание: если я удалю лишнее пространство (в "is a" ), testsite будет правильно отображаться, поскольку точка больше не появляется в начале строки.

Это вызывает проблему при попытке отправить адреса веб-сайтов, и мы получаем звонки от клиентов, говорящих, что они не могут нажимать на наши ссылки.

Кто-нибудь еще испытал это? Как мы можем решить эту проблему, кроме написания нашей собственной кодировки?

Ответ 1

Это фактически за RFC 2821 (4.5.2 Прозрачность)

Перед отправкой строки текста почты клиент SMTP проверяет первый символ строки. Если это период, в начале строки вставлен еще один период.

.Net просто сохраняет файл в режиме "готов к передаче", что означает, что ему не нужно обезьяну с электронной почтой перед отправкой, вместо этого он может передавать его как есть. К сожалению, этот формат на 100% не отличается от формата Outlook Express EML. Вы должны быть в состоянии установить кодировку в UTF-8 (или что-то подобное), и это будет означать для вас кодировку Base-64.

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

Ответ 2

В .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>:=

Похоже, что он обертывает текст определенной длиной символа в строке. Я смутно помню, что проблема была в .Net 2.0, где по умолчанию она не делает этого, что может вызвать проблемы со спам-фильтрами.

Фактически увеличение размера сообщения дает следующее в .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

Похоже на ошибку.

Обходным решением может быть изменение BodyEncoding на нечто иное, чем ASCII.

Ответ 3

Глядя на исходный код .NET 4, возможно, то, что вы испытываете, имеет какое-то отношение к методу MailWriter.WriteAndFold. Также в классе MailWriter есть

static int writerDefaultLineLength = 76

что означает количество символов в строке. Возможно, потому, что вы удалили лишний символ пробела, он начал работать.