Gratuitous CRLF in Subject: line - why is it there, and is it legal?
Well, if I understand RFC 822, they are legal in certain cases, I think it's an artifact from the days of small screens with 24x80 resolutions..
These sections seem to be fairly clear Subjects can be folded, and folding is a CRLF plus LWSP(linear white space) character.. it's possible they've been supeseded, Wietse (on the postfix lists) knows his RFCs inside out if you want a definitive answer.
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>, [email protected] and To: "Joe & J. Harvey" <[email protected] 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.
Edit by the questioner: I hope NickW will forgive me for adding a note to the effect that RFC822 has been obsoleted by RFC2822, but the new RFC says pretty much the same thing in its section 2.2.3, and explicitly confirms that such folding should be removed before any further processing is done:
Each header field is logically a single line of characters comprising the field name, the colon, and the field body. For convenience however, and to deal with the 998/78 character limitations per line, the field body portion of a header field can be split into a multiple line representation; this is called "folding". The general rule is that wherever this standard allows for folding white space (not simply WSP characters), a CRLF may be inserted before any WSP. For example, the header field:
Subject: This is a test
can be represented as:
Subject: This is a test
Note: Though structured field bodies are defined in such a way that folding can take place between many of the lexical tokens (and even within some of the lexical tokens), folding SHOULD be limited to
placing the CRLF at higher-level syntactic breaks. For instance, if a field body is defined as comma-separated values, it is recommended that folding occur after the comma separating the structured items in preference to other places where the field could be folded, even if it is allowed elsewhere.
The process of moving from this folded multiple-line representation of a header field to its single line representation is called "unfolding". Unfolding is accomplished by simply removing any CRLF that is immediately followed by WSP. Each header field should be treated in its unfolded form for further syntactic and semantic evaluation.
This is not to detract from the fact that NickW unerringly pointed me at pretty much exactly what I needed to know, only to help this answer stay relevant for anyone who might stumble across it in the future.
Sendmail server (SendMail) imposes SMTP line length limits but it is much higher (990 bytes or more for smtp mailers).
SendMail != SendEmail
As I understand Nagios uses by default SendEmail client to send emails. It seems that email client you make Nagios use imposes such "harsh" limits on length of email header/subject line.
Check and report email client configured in
commands.cfg configuration file.