CRLF gratuito no Assunto: line - por que existe e é legal?

Estou com um problema no sistema NAGIOS enviando emails para um serviço popular de email para SMS. O serviço de email para SMS recebe emails com texto na Subject:linha e os envia para o número de celular codificado no To:campo. Por enquanto, tudo bem. Infelizmente, o sendmail (e o postfix antes dele) parecem estar inserindo uma CRLF gratuita na linha (necessariamente longa) Subject:, e isso está fazendo com que minhas mensagens SMS sejam truncadas na CRLF se e somente se a Subject:linha contiver um ou mais dois pontos depois da gratuidade CRLF.

Estou confiante de que as mensagens estão sendo criadas corretamente, mas só para ter certeza, aqui estou eu criando uma mensagem de teste completamente indecorosa para mim, com uma longa Subject:linha:

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

Observe que não há dois pontos extras nesta Subject:linha; Tudo o que estou fazendo aqui é mostrar que um CRLF extra está inserido no fio. Aqui está o resultado 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

Na metade do caminho (marcado em negrito + itálico), entre o cabeçalho 501234567e o 601234567no Subject:cabeçalho original , você pode ver um CRLF sendo inserido ( 0x0d 0x0a, no despejo hexagonal do lado esquerdo, ..no texto sem formatação do lado direito).

O MTA de recebimento parece feliz em pós-processar isso e, quando olho para as mensagens armazenadas no disco na extremidade de recebimento, vejo apenas um LF (0x0a) na linha Assunto: e a linha é analisada corretamente e em sua por, por exemplo alpine,. No entanto, o CRLF está presente e, entre mim e o (excelente) pessoal de suporte de email para SMS, estabelecemos que essa é a causa do problema.

Portanto, minha pergunta é: é legal para um MTA inserir um CRLF gratuito no fio?

Se for, e eu posso provar, é o problema da casa de email para SMS, porque eles estão sendo intolerantes. Se não é, ou é, mas não posso provar, o problema se torna meu, portanto, uma resposta com referências seria muito útil.

Edit : Agora posso ficar claro que o serviço de email para SMS em questão é kapow . Depois que esse problema foi explicado, eles conseguiram, trabalharam comigo para desenvolver e testar uma correção e implantaram a correção. Minhas longas linhas de assunto com dois pontos agora são retransmitidas corretamente em SMS. Normalmente, eu não trompo em empresas individuais, especialmente no SF, mas achei digno de nota que kapow fez a coisa certa. (Isenção de responsabilidade: não tenho conexão com a kapow, exceto como um cliente pagador que está feliz com a maneira como lidou com o problema.)

Bem, se eu entendo o RFC 822, eles são legais em certos casos, acho que é um artefato dos dias de telas pequenas com resoluções 24x80.

Essas seções parecem bastante claras. Os assuntos podem ser dobrados e dobrar é um caractere CRLF mais LWSP (espaço em branco linear). É possível que eles tenham sido substituídos, Wietse (nas listas de postfix) conhece seus RFCs de dentro para fora, se você quiser uma resposta definitiva.

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.

Editar pelo questionador : Espero que o NickW me perdoe por adicionar uma nota no sentido de que o RFC822 foi obsoleto pelo RFC2822, mas o novo RFC diz praticamente a mesma coisa na seção 2.2.3 e confirma explicitamente que essa dobra deve ser removido antes que qualquer outro processamento seja concluído:

Cada campo de cabeçalho é logicamente uma única linha de caracteres que compreende o nome do campo, os dois pontos e o corpo do campo. Por conveniência, porém, e para lidar com as limitações de 998/78 caracteres por linha, a parte do corpo do campo de um campo de cabeçalho pode ser dividida em uma representação de várias linhas; isso é chamado de "dobrável". A regra geral é que sempre que esse padrão permitir dobrar espaços em branco (não apenas caracteres WSP), um CRLF poderá ser inserido antes de qualquer WSP. Por exemplo, o campo do cabeçalho:

       Subject: This is a test

pode ser representado como:

       Subject: This
        is a test

Nota: Embora os corpos de campo estruturados sejam definidos de tal maneira que o dobramento possa ocorrer entre muitos dos símbolos lexicais (e mesmo dentro de alguns dos símbolos lexicais), o dobramento DEVE limitar-se a
colocar o CRLF em intervalos sintáticos de nível superior. Por exemplo, se um corpo de campo for definido como valores separados por vírgula, é recomendável que a dobra ocorra após a vírgula que separa os itens estruturados, de preferência a outros locais onde o campo pode ser dobrado, mesmo que seja permitido em outro lugar.

O processo de passar dessa representação de várias linhas dobrada de um campo de cabeçalho para sua representação de linha única é chamado "desdobramento". O desdobramento é realizado simplesmente removendo qualquer CRLF que é imediatamente seguido pelo WSP. Cada campo de cabeçalho deve ser tratado em sua forma desdobrada para posterior avaliação sintática e semântica.

Isso não diminui o fato de que NickW me apontou, sem hesitação, exatamente o que eu precisava saber, apenas para ajudar essa resposta a permanecer relevante para qualquer um que possa se deparar com ela no futuro.

O servidor Sendmail (SendMail) impõe limites de comprimento de linha, mas é muito maior (990 bytes ou mais para os usuários de email smtp).

SendMail! = SendEmail

Pelo que entendi, o Nagios usa por padrão o cliente SendEmail para enviar e-mails. Parece que o cliente de email que você usa o Nagios impõe limites "severos" ao comprimento do cabeçalho / assunto do email.

Verifique e relate o cliente de email configurado no commands.cfgarquivo de configuração.
( notify-host-by-emaile notify-service-by-emailconfigurações).