我在使用 NAGIOS 系统向流行的电子邮件转短信服务发送电子邮件时遇到了问题。电子邮件转短信服务接收行中包含文本的电子邮件Subject:，并将其发送到字段中编码的手机号码To:。到目前为止一切顺利。遗憾的是，sendmail（以及之前的 postfix）似乎在（必然很长的）行中插入了一个不必要的 CRLF Subject:，这导致我的短信在 CRLF 处被截断当且仅当该Subject:行包含一个或多个冒号过去的无偿的 CRLF。
我确信这些消息是正确创建的，但是为了确保万无一失，下面是我给自己创建的一条完全不经意的测试消息，其中包含一行长行Subject:：
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
大约在一半的位置（以粗体+斜体标记），在原始标题中的501234567和之间，您可以看到插入了 CRLF（，左侧为十六进制转储，右侧为纯文本）。601234567Subject:0x0d 0x0a..
接收 MTA 似乎很乐意对此进行后期处理，当我查看接收端磁盘上存储的邮件时，我只看到主题：行中的 LF (0x0a)，并且该行被正确且完整地解析，例如。alpine尽管如此，CRLF 仍然存在于线路上，在我和（优秀的）电子邮件到短信支持人员之间，我们已经确定这些是问题的原因。
我的问题是：MTA 在线上插入不必要的 CRLF 是否合法？
如果是，而且我可以证明，那么这就是电子邮件转短信公司的问题，因为他们太不宽容了。如果不是，或者虽然是，但我无法证明，那么这就是我的问题，所以答案有参考文献将非常有用。
编辑：我现在可以坦白地说，有问题的电子邮件转短信服务是卡波夫。一旦向他们解释了这个问题，他们就明白了，并与我合作开发和测试了修复程序，并部署了修复程序。我的长主题行带有冒号，现在可以正确地转发到短信中。我通常不会吹捧个别公司，尤其是在 SF 上，但我认为值得注意的是 kapow 做了正确的事情。（免责声明：我与 kapow 没有任何关系，只是作为付费客户，对他们处理他的问题的方式感到满意。）
答案1
好吧，如果我理解了 RFC 822，它们在某些情况下是合法的，我认为这是 24x80 分辨率小屏幕时代的产物。
这些部分似乎相当清楚，主题可以折叠，折叠是一个 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
(i.e., 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 置于更高级别的语法中断处。例如，如果字段主体定义为逗号分隔值，则建议在分隔结构化项目的逗号之后进行折叠，而不是在可以折叠字段的其他位置进行折叠，即使其他地方允许折叠。将标题字段从这种折叠的多行表示转换为单行表示的过程称为“展开”。展开只需删除紧跟 WSP 的任何 CRLF 即可。每个标题字段都应以其展开形式进行处理，以便进行进一步的句法和语义评估。
这并非是为了掩盖 NickW 准确地向我指出了我需要知道的内容这一事实，而只是为了帮助这个答案对未来可能偶然遇到它的任何人来说都保持相关性。
答案2
发送邮件服务器（SendMail）对 SMTP 行长度有限制，但是限制要高得多（对于 smtp 邮件程序来说为 990 字节或更长）。
发送邮件 != 发送电子邮件
据我了解，Nagios 默认使用 SendEmail客户发送电子邮件。您让 Nagios 使用的电子邮件客户端似乎对电子邮件标题/主题行的长度施加了“严格”的限制。
检查并报告commands.cfg配置文件中配置的电子邮件客户端。
（notify-host-by-email和notify-service-by-email设置）。