件名に不要なCRLF：行-なぜそこにあり、合法なのですか？
NAGIOSシステムが人気のあるメールからSMSへのサービスにメールを送信する際に問題が発生しています。 email-to-SMSサービスは、Subject:行にテキストが含まれる電子メールを受け取り、To:フィールドにエンコードされた携帯電話番号に送信します。ここまでは順調ですね。悲しいことに、sendmail（およびその前のpostfix）は、（必要に応じて長い）Subject:行に不必要なCRLFを挿入しているようで、CR =でmy SMSメッセージが切り捨てられますifとifSubject:行に1つ以上のコロンが含まれている場合過去不必要な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ヘッダーの601234567とSubject:の間の約半分（太字と斜体でマーク）に、CRLFが挿入されていることがわかります（0x0d 0x0a、左側の16進ダンプでは、..、右側のプレーンテキスト）。
受信側のMTAはこれを後処理して喜んでいるようです。受信側でディスクに保存されているメールを見ると、Subject：行にLF（0x0a）しかありません。そして、その行はAlpineなどによって正しく完全に解析されます。それでも、CRLFはネットワーク上にあり、私と（優れた）電子メールからSMSへのサポート担当者の間に、これらが問題の原因であることを確認しました。
だから私の質問は：MTAが回線に不必要なCRLFを挿入することは合法ですか？
もしそうなら、そして私がそれを証明することができるなら、それは彼らが不寛容であるので、それはメールからSMSへの家の問題です。そうでない場合、またはそうであるが証明できない場合は、それが私の問題となるため、回答with referencesが最も役立ちます。
編集：問題のemail-to-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がRFC2822によって廃止されているという旨のメモを追加することを私に許してくれることを望みますが、新しいRFCはかなり言っています そのセクション2.2. とほぼ同じであり、さらに処理を行う前に、このような折りたたみを削除する必要があることを明示的に確認します。
各ヘッダーフィールドは、論理的には、フィールド名、コロン、フィールド本文を構成する1行の文字です。ただし、便宜上、1行あたりの998/78文字の制限に対処するために、ヘッダーフィールドのフィールド本体部分を複数行の表現に分割できます。これは「折りたたみ」と呼ばれます。一般的なルールは、この標準で空白の折りたたみが可能な場合（WSP文字だけでなく）、WLFの前にCRLFを挿入することです。たとえば、ヘッダーフィールド：
Subject: This is a test次のように表すことができます：
Subject: This is a test注：構造化フィールド本体は、多くの字句トークン間で（さらにはいくつかの字句トークン内でも）折りたたみが発生するように定義されていますが、折りたたみは、
CRLFをより高いレベルの構文ブレークに配置します。たとえば、フィールド本体がコンマ区切り値として定義されている場合、他の場所で許可されている場合でも、フィールドが折りたたまれている可能性がある他の場所よりも構造化アイテムをコンマで区切った後で折りたたむことをお勧めします。ヘッダーフィールドのこの折りたたまれた複数行表現からその単一行表現に移動するプロセスは、「展開」と呼ばれます。展開は、WSPの直後に続くCRLFを削除するだけで実行できます。各ヘッダーフィールドは、展開された形式で処理して、構文および意味をさらに評価する必要があります。
これは、NickWが間違いなく私が知っておくべきことをほぼ正確に指摘していたという事実を損なうものではなく、将来この問題に出くわす可能性のある人すべてにこの回答が関連し続けるのを助けるためです。
Sendmail server（SendMail）は、SMTP行の長さの制限を課しますが、はるかに高くなります（smtpメーラーの場合は990バイト以上）。
SendMail！= SendEmail
私が理解しているように、NagiosはデフォルトでSendEmail clientを使用してメールを送信します。 Nagiosで使用するメールクライアントは、メールのヘッダー/件名の長さにこのような「厳しい」制限を課しているようです。
commands.cfg構成ファイルで構成された電子メールクライアントを確認して報告します。
（notify-Host-by-emailおよびnotify-service-by-email設定）。