我遇到了NAGIOS系统发送电子邮件到stream行的电子邮件到SMS服务的问题。 电子邮件到短信服务将在Subject:行中接收带有文本的电子邮件，并将其发送到“ To:字段中编码的手机号码。 到现在为止还挺好。 不幸的是，sendmail（和它之前的后缀）似乎是插入一个免费的CRLF到（必然长） Subject:行，这导致我的短信在CRLF被截断当且仅当 Subject:行包含一个或多个冒号通过无偿的CRLF。
我相信这些信息是正确创build的，但是可以肯定的是，这里是我自己创build了一个完全愚蠢的testing信息，
echo "foo" | mail -s "1234567 101234567 201234567 301234567 401234567 501234567 601234567 701234567 801234567 90123456789" [email protected]
请注意，在此Subject:行中没有额外的冒号; 所有我在这里做的是显示一个额外的CRLF插入电线。 这是sudo ngrep -x port 25的结果：
44 61 74 65 3a 20 46 72 69 2c 20 33 31 20 4d 61 Date: Fri, 31 Ma
79 20 32 30 31 33 20 31 30 3a 34 33 3a 35 35 20 y 2013 10:43:55
2b 30 31 30 30 0d 0a 54 6f 3a 20 72 65 61 70 65 +0100..To: reape
72 40 74 65 61 70 61 72 74 79 2e 6e 65 74 0d 0a [email protected]..
53 75 62 6a 65 63 74 3a 20 31 32 33 34 35 36 37 Subject: 1234567
20 31 30 31 32 33 34 35 36 37 20 32 30 31 32 33 101234567 20123
34 35 36 37 20 33 30 31 32 33 34 35 36 37 20 34 4567 301234567 4
30 31 32 33 34 35 36 37 20 35 30 31 32 33 34 35 01234567 5012345
36 37 0d 0a 20 36 30 31 32 33 34 35 36 37 20 37 67 .. 601234567 7
30 31 32 33 34 35 36 37 20 38 30 31 32 33 34 35 01234567 8012345
36 37 20 39 30 31 32 33 34 35 36 37 38 39 0d 0a 67 90123456789..
55 73 65 72 2d 41 67 65 6e 74 3a 20 48 65 69 72 User-Agent: Heir
6c 6f 6f 6d 20 6d 61 69 6c 78 20 31 32 2e 34 20 loom mailx 12.4
37 2f 32 39 2f 30 38 0d 0a 4d 49 4d 45 2d 56 65 7/29/08..MIME-Ve
72 73 69 6f 6e 3a 20 31 2e 30 0d 0a 43 6f 6e 74 rsion: 1.0..Cont
65 6e 74 2d 54 79 70 65 3a 20 74 65 78 74 2f 70 ent-Type: text/p
6c 61 69 6e 3b 20 63 68 61 72 73 65 74 3d 75 73 lain; charset=us
在原始Subject:标题的501234567和601234567之间大约一半的地方（用粗体+斜体标记），您可以看到正在插入的CRLF（ 0x0d 0x0a ，在左边的hex转储， ..在右边手边纯文本）。
接收MTA似乎很乐意后处理这个，当我在接收端查看磁盘上存储的邮件时，我在Subject：行中只看到一个LF（0x0a），并且正确parsing了行例如通过alpine 。 尽pipe如此，CRLF还是存在的，在我和（优秀的）电子邮件到SMS的支持人员之间，我们已经确定这是问题的原因。
所以我的问题是： MTA在电汇上插入一个无偿的CRLF是合法的吗？
如果是的话，我可以certificate这一点，那么这是电子邮件到SMS的问题，因为他们是不容忍的。 如果不是，或者是我不能certificate，那么这就成了我的问题，所以有参考的答案是最有用的。
编辑 ：我现在可以来干净的电子邮件到SMS服务是kapow 。 一旦向他们解释了这个问题，他们就得到了这个问题，与我一起开发和testing一个修复程序，并已经部署了修复程序。 我长长的冒号科目现在被正确地转发到短信。 我通常不会吹嘘个别公司，特别是不会在SF上，但我认为值得注意的是，kapow没有正确的做法。 （免责声明：除了作为一个付费客户，他们对于他们处理问题的方式感到高兴，我和kapow没有任何关系。）
那么，如果我了解RFC 822，它们在某些情况下是合法的，我认为这是从24×80分辨率的小屏幕的时代的神器。
这些部分似乎相当清楚主题可以折叠，折叠是一个CRLF加LWSP（线性空白）字符..它可能已经超过了，Wietse（在后缀列表中）如果你想要知道他的RFC一个明确的答案。
3.1.1. LONG HEADER FIELDS Each header field can be viewed as a single, logical line of ASCII characters, comprising a field-name and a field-body. For convenience, the field-body portion of this conceptual entity can be split into a multiple-line representation; this is called "folding". The general rule is that wherever there may be linear-white-space (NOT simply LWSP-chars), a CRLF immediately followed by AT LEAST one LWSP-char may instead be inserted. Thus, the single line To: "Joe & J. Harvey" <ddd @Org>, JJV @ BBN can be represented as: To: "Joe & J. Harvey" <ddd @ Org>, JJV@BBN and To: "Joe & J. Harvey" <ddd@ Org>, JJV @BBN and To: "Joe & J. Harvey" <ddd @ Org>, JJV @ BBN The process of moving from this folded multiple-line representation of a header field to its single line represen- tation is called "unfolding". Unfolding is accomplished by regarding CRLF immediately followed by a LWSP-char as equivalent to the LWSP-char. Note: While the standard permits folding wherever linear- white-space is permitted, it is recommended that struc- tured fields, such as those containing addresses, limit folding to higher-level syntactic breaks. For address fields, it is recommended that such folding occur between addresses, after the separating comma. 3.1.2. STRUCTURE OF HEADER FIELDS Once a field has been unfolded, it may be viewed as being com- posed of a field-name followed by a colon (":"), followed by a field-body, and terminated by a carriage-return/line-feed. The field-name must be composed of printable ASCII characters (ie, characters that have values between 33. and 126., decimal, except colon). The field-body may be composed of any ASCII characters, except CR or LF. (While CR and/or LF may be present in the actual text, they are removed by the action of unfolding the field.) Certain field-bodies of headers may be interpreted according to an internal syntax that some systems may wish to parse. These fields are called "structured fields". Examples include fields containing dates and addresses. Other fields, such as "Subject" and "Comments", are regarded simply as strings of text. Note: Any field which has a field-body that is defined as other than simply <text> is to be treated as a struc- tured field. Field-names, unstructured field bodies and structured field bodies each are scanned by their own, independent "lexical" analyzers. 3.1.3. UNSTRUCTURED FIELD BODIES For some fields, such as "Subject" and "Comments", no struc- turing is assumed, and they are treated simply as <text>s, as in the message body. Rules of folding apply to these fields, so that such field bodies which occupy several lines must therefore have the second and successive lines indented by at least one LWSP-char.
由提问者编辑 ：我希望NickW原谅我添加一个注释，说明RFC822已经被RFC2822废弃了，但是新的RFC在2.2.3节中说的几乎是一样的，并且明确地确认这样的折叠应该在进行任何进一步处理之前将其移除：
每个标题字段在逻辑上是由字段名称，冒号和字段正文组成的一行字符。 然而，为了方便起见，为了处理每行998/78字符限制，可以将头字段的字段主体部分拆分成多行表示; 这被称为“折叠”。 一般规则是，只要本标准允许折叠空白（不是简单的WSP字符），就可以在任何WSP之前插入CRLF。 例如，标题字段：
Subject: This is a test可以表示为：
Subject: This is a test注意：虽然结构化的字段体被定义为可以在许多词汇标记（甚至在一些词汇标记内）之间进行折叠，但是折叠应该限于
将CRLF放在更高级的句法中断处。 例如，如果将字段主体定义为以逗号分隔的值，则build议在逗号分隔结构化项目之后进行折叠，而不是将字段折叠起来的其他位置进行折叠，即使其他位置允许。从这个标题字段的折叠多行表示移动到其单行表示的过程被称为“展开”。 展开是通过简单地删除紧接着WSP的任何CRLF来完成的。 为了进一步的句法和语义评估，每个标题字段应该以展开的forms对待。
这并不是为了减less这个事实，即NickW毫无疑问地指出了我所需要知道的东西，只是为了帮助这个答案保持与将来偶然发现的任何人的相关性。
Sendmail 服务器 （SendMail）强加线路长度限制，但是它要高得多（对于smtp邮件程序来说，990字节或更多）。
SendMail！= SendEmail
据我了解，Nagios默认使用SendEmail 客户端来发送电子邮件。 看来你使Nagios使用的电子邮件客户端对电子邮件标题/主题行的长度施加了如此“苛刻”的限制。
检查并报告在commands.cfgconfiguration文件中configuration的电子邮件客户端。
（ notify-host-by-email和notify-service-by-email设置）。