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
что означает количество символов в строке. Возможно, потому, что вы удалили лишний символ пробела, он начал работать.
