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

Похоже, что SmtpClient .NET создает электронные письма с дополнительной точкой в ​​именах хостов, если точка должна появиться в начале кодированной 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:" +" https://test.com/: "; smtpClient.PickupDirectoryLocation = "C:\\temp\\"; smtpClient.DeliveryMethod = System.Net.Mail.SmtpDeliveryMethod.SpecifiedPickupDirectory; smtpClient.Send(mail); } 

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

X-Sender: [email protected]

X-Receiver: [email protected]

MIME-версия: 1.0

От: [email protected]

Кому: [email protected]

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

Тема: Тест

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

Content-Transfer-Encoding: цитируемый-печатный

Привет, это короткий тест по проблеме: https: // test =

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

При отправке файла или открытии в Outlook (или любой другой программе) появляются двойные точки (т. Е. Test..com). Обратите внимание, что если я удалю лишнее пространство (в «есть»), этот test.com будет отображаться правильно, поскольку точка больше не появляется в начале строки.

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

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

Это фактически соответствует RFC 2821 (4.5.2 Transparency)

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

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

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

В .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: https://test.com/:= 

Похоже, что он обертывает текст с определенной длиной символа на строку. Я смутно помню, что в .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: https://test.com/:=20 

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

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

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

 static int writerDefaultLineLength = 76 

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

Давайте будем гением компьютера.