System.Net.Mail creando correos inválidos y archivos eml? Insertar puntos extra en nombres de host

Parece que el SmtpClient de .NET está creando correos electrónicos con un punto extra en los nombres de los hosts si el punto apareciera al comienzo de una línea codificada MIME (por ejemplo, test.com algunas veces aparece como test..com). Código de ejemplo:

[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:" +" https://test.com/: "; smtpClient.PickupDirectoryLocation = "C:\\temp\\"; smtpClient.DeliveryMethod = System.Net.Mail.SmtpDeliveryMethod.SpecifiedPickupDirectory; smtpClient.Send(mail); } 

Esto crea un archivo .eml que se ve así:

X-Sender: test@test.com

X-Receiver: Test@test.com

Versión MIME: 1.0

De: test@test.com

Para: Test@test.com

Fecha: 6 de julio de 2011 15:55:28 -0400

Asunto: Prueba

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

Content-Transfer-Encoding: cotizado-imprimible

Hola, esta es una breve prueba del problema: https: // test =

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

Al enviar el archivo, o abrir en Outlook (o cualquier otro progtwig), aparecen los puntos dobles (es decir, test..com). Tenga en cuenta que si elimino el espacio extra (en “es una”), ese test.com se muestra correctamente ya que el punto ya no aparece al comienzo de la línea.

Esto causa un problema cuando intentamos enviar direcciones de sitios web, y recibimos llamadas de clientes que dicen que no pueden hacer clic en nuestros enlaces.

Alguien más ha experimentado esto? ¿Cómo podemos resolver este problema que no sea escribir nuestra propia encoding?

Esto es en realidad por RFC 2821 (Transparencia 4.5.2)

Antes de enviar una línea de texto de correo, el cliente SMTP verifica el primer carácter de la línea. Si se trata de un período, se inserta un período adicional al comienzo de la línea.

.Net solo almacena el archivo en el modo “listo para transmitir”, lo que significa que no tiene que simular el correo electrónico antes de enviarlo, sino que puede transmitirlo tal como está. Lamentablemente, este formato no es 100% el mismo que aparentemente el formato EML de Outlook Express. Debería poder establecer la encoding en UTF-8 (o algo similar) y eso activará la encoding de Base-64 por usted.

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

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

Parece que está envolviendo el texto en cierta longitud de caracteres por línea. Recuerdo vagamente que había un problema en .Net 2.0 donde, de forma predeterminada, no hace esto, lo que puede causar problemas con los filtros de correo no deseado.

De hecho, boost el tamaño del mensaje da lo siguiente en .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: https://test.com/:=20 

Parece un error.

Una solución podría ser cambiar BodyEncoding a algo distinto de ASCII.

En cuanto al código fuente de .NET 4, tal vez lo que estás experimentando tiene algo que ver con el método MailWriter.WriteAndFold. También en la clase MailWriter hay

 static int writerDefaultLineLength = 76 

variable, es decir, recuento de caracteres por línea. Tal vez porque eliminaste un personaje de espacio extra, comenzó a funcionar.