Des points d'exclamation sont insérés dans les e-mails à environ 1000 caractères


9

Avoir un programme .NET qui utilise l'espace de noms System.Net.Main pour envoyer un e-mail via SMTP.

C'est sur un site client, donc à partir de là, il passera par une (série de?) Serveurs relais SMTP avant d'atteindre sa destination.

Pour le moment, je n'ai aucune information sur cette infrastructure de relecture / messagerie smtp (et obtenir ces informations va être difficile).

Quelque part le long de la ligne, un point d'exclamation est inséré dans les URL longues dans l'e-mail, environ 100 caractères à partir du début d'une ligne.

EDIT- En fait, ont trouvé ses environ 1000 caractères dans

Cela ne se produit pas sur un système de test ou sur des centaines d'autres sites.

Je suis sûr que cela doit être lié aux codes d'échappement pour rompre les longues files d'attente.

Quelqu'un a une idée?


Trouvé ses pas 100 caractères dans un lien, ses environ 1000 caractères dans le message. Cela donne plus d'informations mais reste mystérieux pourquoi seulement rapporté par un client. Peut-être que certains serveurs smtp sont plus tolérants que d'autres? systemwebmail.com/faq/4.4.5.aspx
Ryan

Réponses:


11

J'ai été frappé par ça moi-même.

Si vous créez un message html sans aucun retour chariot, vous pouvez obtenir des erreurs quelque part autour de la marque de 1000 caractères.

La solution consiste à ajouter quelques caractères \ r \ n pour que chaque ligne soit inférieure à 1000 (ou 988 si vous ne comptez pas les caractères \ r \ n).

Voir section 2.1.1. Limites de longueur de ligne de RFC 2822 pour plus de détails:

2.1.1. Limites de longueur de ligne

Il y a deux limites que cette norme place sur le nombre de caractères dans une ligne. Chaque ligne de caractères NE DOIT PAS dépasser 998 caractères et DEVRAIT ne pas dépasser 78 caractères, à l'exclusion du CRLF.


Merci - voir aussi les discussions sur ce post - systemwebmail.com/faq/4.4.5.aspx
Ryan

La RFC-2822-2.1.1 semble être davantage une orientation et des conseils qu'une règle appliquée. Les perspectives semblent être affectées. Certains autres clients de messagerie ne sont pas concernés par cela.
YoYo

@YoYo Je dirais que chaque ligne de caractères NE DOIT PAS être plus de 998 caractères serait une règle, mais et NE DEVRAIT PAS être plus de 78 caractères, serait plus d'orientation et de conseils plutôt qu'une règle.
sgmoore

Oui, le libellé ne permet pas cette flexibilité. Je suis d'accord.
YoYo

0

Habiller à un certain nombre de caractères est généralement un problème client. Si vous ne le voyez pas sur vos autres sites, ou sur une machine de test, je ne pense pas que ce soit votre code. Voyez si vous ne pouvez pas savoir quel client est utilisé pour recevoir le message - cela pourrait être une vieille chose cruelle qui s'emballe automatiquement avec un certain nombre de caractères.


0

Il ne semble pas que l'application .Net soit à l'origine du problème si le problème ne se produit pas sur de nombreux autres sites où le même code s'exécute. Le site à problème se cache-t-il derrière une sorte de pare-feu d'application ou de dispositif anti-spam qui pourrait surveiller le flux smtp? Si tel est le cas, il se peut qu'une règle de tronçonnage des URL longues soit déclenchée, ce qui entraîne la réduction des URL dans l'e-mail.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.