Subject：lineのGratuitous CRLF-なぜそこにあり、合法ですか？

人気のメールからSMSサービスにメールを送信するNAGIOSシステムで問題が発生しています。電子メールからSMSへのサービスは、Subject:行にテキストを含む電子メールを受け取り、To:フィールドにエンコードされた携帯電話番号に送信します。ここまでは順調ですね。悲しいことに、（その前と後置）sendmailが（必ずしも長い）に無償CRLFを挿入するように見えるSubject:ライン、そして私のSMSメッセージが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が挿入されています（左側の16進ダンプ、右側のプレーンテキスト）。601234567Subject:0x0d 0x0a..

受信側MTAはこれを後処理しても問題ないようで、受信側でディスクに保存されたメールを見ると、Subject：行にLF（0x0a）しか表示されず、行は正しく解析され、全体によって、例えばalpine。それにもかかわらず、CRLFはネットワーク上にあり、私と（優秀な）電子メールからSMSをサポートする人々の間で、これらが問題の原因であることを確認しました。

だから私の質問は次のとおりです。MTAが無償のCRLFをワイヤに挿入することは合法ですか？

もしそうであり、私がそれを証明できるなら、それは彼らが不寛容であるので、それは電子メールからSMSへの家の問題です。そうでない場合、またはそれが証明できない場合、それが私の問題になります。したがって、参照のある回答が最も有用です。

編集：問題のメールからSMSへのサービスがkapowであることがわかりました。この問題が彼らに説明されると、彼らはそれを得て、私と協力して修正を開発してテストし、修正を展開しました。コロンを含む私の長い件名の行は、SMSに正しく中継されるようになりました。私は通常、個々の会社、特にSFについてはトランペットしませんが、kapowがThe Right Thingをしたことは注目に値すると思いました。（免責事項：私はカポウとは何の関係もありません。ただし、彼が問題に対処した方法に満足している有料の顧客としてです。）

ええと、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.

質問者による編集：Nick822がRFC822がRFC2822によって廃止されたという効果に注意を追加することを許してくれることを願っていますが、新しいRFCはセクション2.2.3でほぼ同じことを言っており、そのような折りたたみがさらなる処理が行われる前に削除されます：

各ヘッダーフィールドは、論理的には、フィールド名、コロン、およびフィールド本体で構成される1行の文字です。ただし、便宜上、1行あたり998/78文字の制限に対処するために、ヘッダーフィールドのフィールド本体部分を複数行の表現に分割できます。これは「折りたたみ」と呼ばれます。一般的な規則は、この標準が空白（単なるWSP文字ではなく）を折り畳むことを許すところならどこでも、CRLFはWSPの前に挿入されるかもしれないということです。たとえば、ヘッダーフィールド：

       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設定）。