CRLF gratuit dans Subject: line - pourquoi est-il là, et est-ce légal?

Je rencontre un problème avec un système NAGIOS qui envoie des e-mails à un service e-mail vers SMS populaire. Le service e-mail vers SMS prend les e-mails avec du texte dans la Subject:ligne et les envoie au numéro de téléphone portable encodé dans le To:champ. Jusqu'ici tout va bien. Malheureusement, sendmail (et le suffixe précédent) semblent insérer un CRLF gratuit dans la ligne (nécessairement longue) Subject:, ce qui provoque la troncature de mes SMS au CRLF si et seulement si la Subject:ligne contient un ou plusieurs deux-points après le gratuit CRLF.

Je suis convaincu que les messages sont créés correctement, mais juste pour être sûr, voici que je me crée un message de test complètement noddy, avec une longue Subject:ligne:

echo "foo" | mail -s "1234567 101234567 201234567 301234567 401234567 501234567 601234567 701234567 801234567 90123456789" reaper@teaparty.net

Notez qu'il n'y a pas de deux points supplémentaires dans cette Subject:ligne; tout ce que je fais ici est de montrer qu'un CRLF supplémentaire est inséré sur le fil. Voici le résultat de 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

Environ à mi-chemin (marqué en gras + italique), entre le 501234567et le 601234567dans l' en- Subject:tête d' origine , vous pouvez voir un CRLF inséré ( 0x0d 0x0a, sur le vidage hexadécimal gauche, ..sur le texte brut droit).

Le MTA de réception semble heureux de post-traiter cela, et lorsque je regarde le courrier stocké sur disque à la fin de la réception, je ne vois qu'un LF (0x0a) dans la ligne Subject: et la ligne est analysée correctement et dans son par, par exemple alpine. Néanmoins, le CRLF est là sur le fil, et entre moi et les (excellents) supporteurs d'email vers SMS, nous avons établi que ceux-ci sont la cause du problème.

Ma question est donc: est-il légal pour un MTA d'insérer un CRLF gratuit sur le fil?

Si c'est le cas, et je peux le prouver, alors c'est le problème de la maison de messagerie électronique par SMS, car ils sont intolérants. Si ce n'est pas le cas, ou si c'est le cas, mais je ne peux pas le prouver, alors cela devient mon problème, donc une réponse avec des références serait très utile.

Edit : Je peux maintenant comprendre que le service e-mail vers SMS en question est kapow . Une fois que ce problème leur a été expliqué, ils l'ont compris, ont travaillé avec moi pour développer et tester un correctif et ont déployé le correctif. Mes longues lignes d'objet avec deux points sont désormais correctement relayées dans les SMS. Normalement, je ne trompe pas les entreprises individuelles, surtout pas sur SF, mais je pense qu'il vaut la peine de noter que kapow a fait la bonne chose. (Avis de non-responsabilité: je n'ai aucun lien avec Kapow, sauf en tant que client payant qui est satisfait de la façon dont il a traité son problème.)

Eh bien, si je comprends le RFC 822, ils sont légaux dans certains cas, je pense que c'est un artefact du temps des petits écrans avec des résolutions 24x80 ..

Ces sections semblent être assez claires.Les sujets peuvent être pliés, et le pliage est un caractère CRLF plus LWSP (espace blanc linéaire). une réponse définitive.

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.

Edit by the questioner : J'espère que NickW me pardonnera d'avoir ajouté une note à l'effet que RFC822 a été obsolète par RFC2822, mais le nouveau RFC dit à peu près la même chose dans sa section 2.2.3 , et confirme explicitement qu'un tel pliage devrait être supprimé avant tout traitement ultérieur:

Chaque champ d'en-tête est logiquement une seule ligne de caractères comprenant le nom du champ, les deux points et le corps du champ. Cependant, pour des raisons de commodité et pour faire face aux limitations de 998/78 caractères par ligne, la partie corps de champ d'un champ d'en-tête peut être divisée en une représentation sur plusieurs lignes; c'est ce qu'on appelle le "pliage". La règle générale est que partout où cette norme permet de plier des espaces blancs (pas simplement des caractères WSP), un CRLF peut être inséré avant n'importe quel WSP. Par exemple, le champ d'en-tête:

       Subject: This is a test

peut être représenté comme:

       Subject: This
        is a test

Remarque: Bien que les corps de champ structurés soient définis de manière à ce que le pliage puisse avoir lieu entre de nombreux jetons lexicaux (et même au sein de certains jetons lexicaux), le pliage DEVRAIT se limiter à
placer le CRLF à des ruptures syntaxiques de niveau supérieur. Par exemple, si un corps de champ est défini comme des valeurs séparées par des virgules, il est recommandé que le pliage se produise après la virgule séparant les éléments structurés de préférence à d'autres endroits où le champ pourrait être plié, même s'il est autorisé ailleurs.

Le processus de passage de cette représentation pliée sur plusieurs lignes d'un champ d'en-tête à sa représentation sur une seule ligne est appelé "dépliage". Le dépliage est accompli en supprimant simplement tout CRLF qui est immédiatement suivi par WSP. Chaque champ d'en-tête doit être traité dans sa forme dépliée pour une évaluation syntaxique et sémantique supplémentaire.

Cela ne veut pas nuire au fait que NickW m'a infailliblement pointé à peu près exactement ce que je devais savoir, seulement pour aider cette réponse à rester pertinente pour quiconque pourrait tomber dessus à l'avenir.

Le serveur Sendmail (SendMail) impose des limites de longueur de ligne mais il est beaucoup plus élevé (990 octets ou plus pour les expéditeurs smtp).

SendMail! = SendEmail

Si je comprends bien, Nagios utilise par défaut le client SendEmail pour envoyer des e-mails. Il semble que le client de messagerie que vous utilisez Nagios impose de telles limites "sévères" sur la longueur de l'en-tête / de la ligne d'objet de l'e-mail.

Vérifiez et signalez le client de messagerie configuré dans le commands.cfgfichier de configuration.
( notify-host-by-emailet notify-service-by-emailparamètres).