主题：行中的免费CRLF-为什么在这里，并且它合法吗？

NAGIOS系统在将电子邮件发送到流行的电子邮件到SMS服务时遇到问题。电子邮件到SMS服务接收Subject:行中带有文本的电子邮件，并将其发送到该To:字段中编码的手机号码。到目前为止，一切都很好。可悲的是，sendmail的（和前后缀）似乎将无偿CRLF到（不一定长）Subject:线，而这造成我的短信，以在CRLF被截断，当且仅当该Subject:行包含一个或多个冒号过去没来由CRLF。

我相信消息创建正确，但是可以肯定的是，这是我给我自己写的一条完整的点头测试消息，内容很长Subject:：

echo "foo" | mail -s "1234567 101234567 201234567 301234567 401234567 501234567 601234567 701234567 801234567 90123456789" reaper@teaparty.net

注意，这一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    r@teaparty.net..
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似乎很乐意对此进行后处理，当我在接收方查看光盘上存储的邮件时，在Subject：行中仅看到LF（0x0a），并且该行及其内容均已正确解析整体由，例如alpine。但是，CRLF随时可用，在我和（优秀的）电子邮件到SMS支持人员之间，我们已经确定这些是问题的原因。

所以我的问题是：MTA在电线上插入免费的CRLF是否合法？

如果可以的话，并且我可以证明这一点，那么这就是电子邮件到短信之家的问题，因为它们不容忍。如果不是，或者我无法证明它，那么这将成为我的问题，因此带有引用的答案将是最有用的。

编辑：我现在可以弄清楚问题中的电子邮件到SMS服务是kapow。一旦向他们解释了此问题，他们就知道了，与我一起开发和测试了修订程序，并部署了修订程序。我的带有冒号的长主题行现在可以正确地中继到SMS中。我通常不会吹嘘单个公司，尤其是在SF上，但我认为值得一提的是，kapow做了正确的事。（免责声明：除了作为付费客户（对他们处理他的问题的方式感到满意之外），我与kapow没有任何联系。）

好吧，如果我理解RFC 822，则在某些情况下它们是合法的，我认为这是来自具有24x80分辨率的小屏幕时代的产物。

这些部分似乎很清楚。主题可以折叠，而折叠是CRLF加LWSP（线性空格）字符。明确的答案。

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能够原谅我添加注释，说明RFC8222已淘汰RFC822，但是新RFC在其2.2.3节中说的差不多，并明确确认这种折叠应在进一步处理之前将其删除：

每个头字段在逻辑上都是一行字符，包括字段名称，冒号和字段正文。但是，为了方便起见，并为了处理每行998/78个字符的限制，可以将标头字段的字段正文部分拆分为多行表示；这称为“折叠”。一般规则是，只要该标准允许折叠空白（不只是WSP字符），就可以在任何WSP之前插入CRLF。例如，标头字段：

       Subject: This is a test

可以表示为：

       Subject: This
        is a test

注意：尽管结构化字段主体的定义方式是，可以在许多词汇标记之间（甚至在某些词汇标记内）发生折叠，但折叠应仅限于
将CRLF置于更高级别的句法中断处。例如，如果将字段主体定义为逗号分隔的值，则建议在逗号分隔结构化项目之后优先于可能折叠字段的其他位置进行折叠，即使该字段可以在其他地方使用也是如此。

从标题字段的这种折叠的多行表示形式移动到其单行表示形式的过程称为“展开”。通过简单地删除WSP之后紧随其后的任何CRLF，即可完成展开。每个标题字段都应以其展开的形式处理，以进一步进行语法和语义评估。

这并不是要削弱NickW毫无误地指出我实际上需要了解的事实，而只是为了帮助这个答案与将来可能偶然发现它的人保持联系。

Sendmail 服务器（SendMail）设置了行长度限制，但更高（对于smtp邮件程序，为990字节或更多）。

SendMail！= SendEmail

据我了解，Nagios默认使用SendEmail 客户端发送电子邮件。您让Nagios使用的电子邮件客户端似乎对电子邮件标题/主题行的长度施加了这样的“苛刻”限制。

检查并报告commands.cfg配置文件中配置的电子邮件客户端。
（notify-host-by-email和notify-service-by-email设置）。