У меня проблема с системой NAGIOS, отправляющей электронные письма популярной службе электронной почты в SMS. Служба преобразования электронной почты в SMS принимает сообщения электронной почты с текстом в Subject: линии, и отправляет их на мобильный номер, закодированный в To: поле. Все идет нормально. К сожалению, sendmail (и postfix до него), похоже, вставляют бесплатный 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 и 601234567 в оригинале Subject: заголовок, вы можете увидеть, что CRLF вставляется (0x0d 0x0a, на левой шестигранной дампе, .. справа обычный текст).
Принимающий MTA, кажется, счастлив постобработать это, и когда я смотрю на сохраненную на диске почту на принимающей стороне, я вижу только LF (0x0a) в строке Subject :, и эта строка анализируется правильно и в ее целиком, например, alpine. Тем не менее, CRLF находится на связи, и между мной и (превосходными) людьми из службы поддержки электронной почты в SMS мы установили, что они являются причиной проблемы.
Итак, мой вопрос: Законно ли для MTA вставлять безвозмездный CRLF в провод?
Если это так, и я могу это доказать, то это проблема электронной почты в SMS, потому что они нетерпимы. Если это не так, или это так, но я не могу это доказать, тогда это становится моей проблемой, поэтому ответ со ссылками было бы очень полезно.
редактировать: Теперь я могу сказать, что рассматриваемая услуга преобразования электронной почты в SMS Капов. Как только им объяснили эту проблему, они ее поняли, вместе со мной разработали и протестировали исправление и развернули исправление. Мои длинные строки темы с двоеточиями теперь правильно передаются в SMS-сообщения. Я обычно не трублю об отдельных компаниях, особенно о НФ, но я подумал, что стоит отметить, что kapow Did The Right Thing. (Отказ от ответственности: я не связан с kapow, кроме как платный клиент, который доволен тем, как они справились с его проблемой.)
Что ж, если я понимаю RFC 822, в некоторых случаях они законны, я думаю, что это артефакт времен маленьких экранов с разрешением 24x80 ...
Эти разделы кажутся довольно четкими. Субъекты можно складывать, а складывание - это символ CRLF плюс LWSP (линейный пробел) ... возможно, они были заменены, Витсе (в списках постфиксов) знает свои 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), CRLF может быть вставлен перед любым WSP. Например, поле заголовка:
Subject: This is a testможно представить как:
Subject: This is a testПримечание: хотя тела структурированных полей определены таким образом, что сворачивание может происходить между многими лексическими токенами (и даже внутри некоторых лексических токенов), сворачивание СЛЕДУЕТ ограничивать
размещение CRLF в синтаксических разрывах более высокого уровня. Например, если тело поля определено как значения, разделенные запятыми, рекомендуется, чтобы сворачивание происходило после запятой, разделяющей структурированные элементы, вместо других мест, где поле может быть свернуто, даже если это разрешено в другом месте.Процесс перехода от этого свернутого многострочного представления поля заголовка к его однолинейному представлению называется «разворачиванием». Развертывание выполняется простым удалением любого CRLF, за которым сразу следует WSP. Каждое поле заголовка следует обрабатывать в развернутом виде для дальнейшей синтаксической и семантической оценки.
Это не умаляет того факта, что NickW безошибочно указал мне в значительной степени именно на то, что мне нужно было знать, только чтобы помочь этому ответу оставаться актуальным для всех, кто может наткнуться на него в будущем.
Отправить почту сервер (SendMail) накладывает ограничения на длину строки SMTP, но она намного выше (990 байт или более для почтовых программ smtp).
SendMail! = SendEmail
Насколько я понимаю, Nagios по умолчанию использует SendEmail клиент для отправки электронных писем. Кажется, что почтовый клиент, который вы заставляете использовать Nagios, накладывает такие «жесткие» ограничения на длину заголовка / темы письма.
Проверить и сообщить почтовый клиент, настроенный в commands.cfg Файл конфигурации.
(notify-host-by-email и notify-service-by-email настройки).