Bezpłatne CRLF w temacie: wiersz - dlaczego tam jest i czy jest legalne?

Mam problem z systemem NAGIOS wysyłającym wiadomości e-mail do popularnej usługi e-mail-SMS. Usługa e-mail-SMS pobiera wiadomości e-mail z tekstem w Subject:linii i wysyła je na numer telefonu komórkowego zakodowany w To:polu. Jak na razie dobrze. Niestety, sendmail (i Postfix przed nim) wydają się być wstawienie nieodpłatne CRLF do (niekoniecznie długich) Subject:linii, a to powoduje moje wiadomości SMS mają być obcięte na CRLF wtedy i tylko wtedy, gdySubject: linia zawiera jeden lub więcej średników przeszłości nieodpłatne CRLF.

Jestem przekonany, że wiadomości są tworzone poprawnie, ale dla pewności, oto ja stworzyłem dla siebie całkowicie testową wiadomość z długą Subject:linią:

echo "foo" | mail -s "1234567 101234567 201234567 301234567 401234567 501234567 601234567 701234567 801234567 90123456789" [email protected]

Uwaga: w tym Subject:wierszu nie ma dodatkowego dwukropka ; wszystko, co tu robię, to pokazanie, że dodatkowy CRLF jest wstawiony na drut. Oto wynik 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

O połowie drogi w dół (pogrubienie + kursywa), pomiędzy 501234567oraz 601234567w oryginalnym Subject:nagłówku można zobaczyć CRLF wkładana ( 0x0d 0x0ana lewy bok Hex Dump, ..na prawej bocznej zwykłego tekstu).

Odbierający MTA wydaje się szczęśliwy, że może to przetworzyć, a kiedy patrzę na pocztę przechowywaną na dysku po stronie odbierającej, widzę tylko LF (0x0a) w wierszu Temat: i wiersz jest analizowany poprawnie i w jego całość, np alpine. Niemniej jednak CRLF jest na linii i między mną a (świetnymi) osobami obsługującymi e-maile-SMS, ustaliliśmy, że to one są przyczyną problemu.

Moje pytanie brzmi zatem: czy MTA może wstawić nieuzasadniony CRLF na drut?

Jeśli tak, i mogę to udowodnić, to jest problem z domem wysyłającym e-maile na SMS, ponieważ są nietolerancyjni. Jeśli nie jest lub jest, ale nie mogę tego udowodnić, staje się to moim problemem, więc odpowiedź z referencjami byłaby najbardziej przydatna.

Edycja : Mogę teraz wyczyścić, że dana usługa e-mail-SMS to kapow . Po wyjaśnieniu im tego problemu, dostali go, pracowali ze mną, aby opracować i przetestować poprawkę oraz wdrożyli poprawkę. Moje długie linie tematyczne z dwukropkami są teraz poprawnie przekazywane do SMS-ów. Zwykle nie trąbię pojedynczych firm, szczególnie nie na SF, ale pomyślałem, że warto zauważyć, że kapow Did The Right Thing. (Oświadczenie: Nie mam żadnego związku z kapow, z wyjątkiem tego, że jestem płatnym klientem, który cieszy się z tego, jak poradzili sobie z jego problemem).

Cóż, jeśli rozumiem RFC 822, są one w niektórych przypadkach legalne, myślę, że to artefakt z czasów małych ekranów o rozdzielczości 24x80.

Te sekcje wydają się dość jasne. Tematy można składać, a składanie to CRLF plus LWSP (liniowa biała spacja) .. możliwe, że zostały one usunięte, Wietse (na listach po poprawce) zna jego RFC na wylot, jeśli chcesz ostateczna odpowiedź.

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.

Edytuj przez pytającego : Mam nadzieję, że NickW wybaczy mi dodanie uwagi o tym, że RFC822 został przestarzały przez RFC2822, ale nowy RFC mówi prawie to samo w sekcji 2.2.3 i wyraźnie potwierdza, że ​​takie składanie powinno zostać usunięte przed dalszym przetwarzaniem:

Każde pole nagłówka jest logicznie pojedynczym wierszem znaków zawierającym nazwę pola, dwukropek i treść pola. Jednak dla wygody i w celu ograniczenia ograniczeń 998/78 znaków na linię, część pola pola nagłówka może być podzielona na reprezentację wielu linii; nazywa się to „składaniem”. Ogólna zasada jest taka, że ​​wszędzie tam, gdzie ten standard zezwala na składanie białych znaków (nie tylko znaków WSP), przed dowolnym WSP można wstawić CRLF. Na przykład pole nagłówka:

       Subject: This is a test

może być reprezentowany jako:

       Subject: This
        is a test

Uwaga: Chociaż strukturyzowane ciała pól są zdefiniowane w taki sposób, że składanie może odbywać się między wieloma tokenami leksykalnymi (a nawet w obrębie niektórych tokenów leksykalnych), składanie MUSI ograniczać się do
umieszczania CRLF na łamach składniowych wyższego poziomu. Na przykład, jeśli treść pola jest zdefiniowana jako wartości rozdzielane przecinkami, zaleca się, aby składanie następowało po przecinku oddzielającym elementy ustrukturyzowane zamiast innych miejsc, w których pole można złożyć, nawet jeśli jest to dozwolone w innym miejscu.

Proces przejścia od złożonej reprezentacji wieloliniowej pola nagłówka do reprezentacji jednowierszowej nazywa się „rozwijaniem”. Rozkładanie odbywa się po prostu usuwając wszelkie CRLF, po których następuje bezpośrednio WSP. Każde pole nagłówka należy traktować w rozwiniętej formie w celu dalszej oceny składniowej i semantycznej.

Nie powinno to umniejszać faktu, że NickW bezbłędnie wskazał mi prawie dokładnie to, co musiałem wiedzieć, tylko po to, aby ta odpowiedź pozostała istotna dla każdego, kto może natknąć się na nią w przyszłości.

Serwer Sendmail (SendMail) nakłada limity długości linii, ale jest znacznie wyższy (990 bajtów lub więcej dla mailerów smtp).

SendMail! = SendEmail

Jak rozumiem, Nagios domyślnie używa klienta SendEmail do wysyłania wiadomości e-mail. Wygląda na to, że klient poczty e-mail, którego używasz w Nagios, nakłada takie „ostre” ograniczenia długości nagłówka / tematu wiadomości.

Sprawdź i zgłoś klienta poczty e-mail skonfigurowanego w commands.cfgpliku konfiguracyjnym.
( notify-host-by-emaili notify-service-by-emailustawienia).