感叹号以大约1000个字符的标记插入到电子邮件中


9

有一个.NET程序,该程序使用System.Net.Main命名空间通过SMTP发送电子邮件。

它在客户站点上,因此从那里到达目的地之前,它将经过(一系列?)SMTP中继服务器。

目前,我没有有关此smtp重放/电子邮件基础结构的信息(并且很难获得该信息)。

沿行的某个地方,从行的开头开始,在电子邮件的长网址中插入了一个感叹号,大约100个字符。

编辑-实际上已经在其中找到了大约1000个字符

在测试系统或其他数百个站点上不会发生这种情况。

我确信这与转义代码有关,可以将长行分开。

任何人有任何想法吗?


发现其链接中未包含100个字符,消息中包含约1000个字符。这提供了更多信息,但仍然是一个谜,为什么只有一位客户报告。也许某些SMTP服务器比其他服务器更能容忍?systemwebmail.com/faq/4.4.5.aspx
Ryan

Answers:


11

自己被打中。

如果您正在构建没有返回任何回车符的html消息,则可能会在1000个字符标记附近出现错误。

解决方案是添加一些\ r \ n字符,以使每行小于1000(如果不计算\ r \ n字符,则为988)。

参见2.1.1节。有关更多详细信息,请参阅RFC 2822的行长度限制:

2.1.1。行长限制

此标准对一行中的字符数有两个限制。每行字符不得超过998个字符,并且应不超过78个字符(不包括CRLF)。


谢谢-另请参阅有关此帖子的讨论-systemwebmail.com/faq/4.4.5.aspx
Ryan

RFC-2822-2.1.1似乎是更多的指导和建议,而不是强制性的规则。前景似乎受到影响。其他一些电子邮件客户端不受此影响。
YoYo

@YoYo我要说的是,每行字符必须不超过998个字符,但应该不超过78个字符,这将是更多的指导和建议,而不是规则。
sgmoore

是的,措辞不允许这种灵活性。我必须同意。
悠悠球'18

0

包装一定数量的字符通常是一个客户端问题。如果您没有在其他站点或测试机上看到它,则认为它不是您的代码。看看您是否无法确定正在使用哪个客户端来接收消息,这可能是一些老旧的东西,它会自动包装一定数量的字符。


0

如果在运行相同代码的许多其他站点上没有发生此问题,这听起来好像不是.Net应用程序引起了该问题。问题站点是否在某种可能正在监视smtp流的应用程序防火墙或反垃圾邮件设备后面?如果是这样,可能会有一条关于截断长URL的规则,该规则将被触发,从而导致电子邮件中的URL缩短。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.