주제의 무상 CRLF : line-왜 존재하며 합법적입니까?

NAGIOS 시스템에서 인기있는 이메일 -SMS 서비스로 이메일을 보내는 데 문제가 있습니다. email-to-SMS 서비스는 텍스트가있는 이메일을 필드에 Subject:인코딩 된 휴대폰 번호로 보냅니다 To:. 여태까지는 그런대로 잘됐다. 슬프게도, 센드 메일 (그리고 그 전에 후위)는 (반드시 긴)에 무상 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와 사이에 절반 정도 아래로 (굵게 + 기울임 꼴로 표시됨) CRLF가 삽입 된 것을 볼 수 있습니다 ( 왼쪽 16 진수 덤프, 오른쪽 일반 텍스트).601234567Subject:0x0d 0x0a..

수신 MTA는 이것을 후 처리하는 것이 좋으며 수신 측의 디스크에 저장된 메일을 볼 때 Subject : 행에 LF (0x0a) 만 표시되고 해당 행은 올바르게 구문 분석됩니다. 예를 들어,에 의해 전체, alpine. 그럼에도 불구하고 CRLF는 전 세계에 있으며 저와 (우수한) 이메일 -SMS 지원 담당자 사이에 문제의 원인이 있음을 확인했습니다.

내 질문은 : MTA가 전선에 무의미한 CRLF를 삽입하는 것이 합법적입니까?

그렇다면 증명할 수 있다면 이메일을 SMS로 보내는 집의 문제입니다. 그렇지 않거나 입증 할 수 없다면 문제가되므로 참조 가 있는 대답 이 가장 유용합니다.

편집 : 이제 문제의 이메일-SMS 서비스가 kapow라는 것을 알 수 있습니다. 이 문제에 대해 설명하고 나면 문제를 해결하고 수정 프로그램을 개발 및 테스트하고 수정 프로그램을 배포했습니다. 콜론이있는 긴 제목 줄이 이제 SMS로 올바르게 릴레이됩니다. 나는 일반적으로 SF를 중심으로하지 않는 개별 회사를 트럼펫하지는 않지만 kapow가 올바른 일을했다는 점에 주목할 만하다고 생각했습니다. (면책 조항 : 나는 자신의 문제를 처리하는 방식에 만족하는 유료 고객을 제외하고 kapow와 관련이 없습니다.)

RFC 822를 이해하면 어떤 경우에는 합법적이며 24x80 해상도의 작은 화면 시절의 인공물이라고 생각합니다.

이 섹션은 상당히 명확한 것처럼 보입니다. 과목을 접을 수 있고 접는 것은 CRLF + LWSP (선형 공백) 문자입니다. 접미사가 가능했을 수도 있습니다. 확실한 대답.

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가 RFC2822에 의해 RFC822가 폐기되었다는 효과에 대한 메모를 추가 한 것을 용서해 주길 바랍니다. 그러나 새로운 RFC는 섹션 2.2.3 에서 거의 똑같은 말을 하고 그러한 접힘이 추가 처리가 완료되기 전에 제거하십시오.

각 헤더 필드는 논리적으로 필드 이름, 콜론 및 필드 본문을 포함하는 한 줄의 문자입니다. 그러나 편의상 그리고 라인 당 998/78 문자 제한을 처리하기 위해 헤더 필드의 필드 본문 부분을 여러 줄 표현으로 나눌 수 있습니다. 이것을 "폴딩"이라고합니다. 일반적인 규칙은이 표준이 WSP 문자가 아닌 공백을 접을 수있는 곳이면 WSP 앞에 CRLF를 삽입 할 수 있다는 것입니다. 예를 들어 헤더 필드는 다음과 같습니다.

       Subject: This is a test

다음과 같이 나타낼 수 있습니다.

       Subject: This
        is a test

참고 : 구조화 된 필드 본문은 많은 어휘 토큰 (및 어휘 토큰 중 일부) 내에서 폴딩이 발생할 수있는 방식으로 정의되지만, 폴딩
은 CRLF를 상위 구문 구문 나누기 에 배치하는 것으로 제한해야 합니다. 예를 들어, 필드 본문이 쉼표로 구분 된 값으로 정의 된 경우, 쉼표가 구조화 된 항목을 다른 위치에서 허용하더라도 필드를 접을 수있는 다른 위치보다 우선적으로 분리 한 후에 접는 것이 좋습니다.

헤더 필드의 접힌 여러 줄 표현에서 단일 줄 표현으로 이동하는 과정을 "펼치기"라고합니다. 펼치기는 즉시 WSP 바로 뒤에있는 CRLF를 제거하면됩니다. 각 헤더 필드는 추가 구문 및 의미 평가를 위해 펼쳐진 형태로 처리해야합니다.

이것은 NickW가 내가 알아야 할 것을 정확히 정확하게 지적했다는 사실을 방해하는 것이 아니며, 앞으로이 답변을 우연히 발견 할 사람 에게이 답변을 유지하는 데 도움이됩니다.

Sendmail 서버 (SendMail)는 회선 길이 제한을 부과하지만 훨씬 더 높습니다 (smtp 메일러의 경우 990 바이트 이상).

SendMail! = SendEmail

Nagios는 기본적으로 SendEmail 클라이언트 를 사용하여 이메일을 보냅니다. Nagios에서 사용하는 이메일 클라이언트는 이메일 헤더 / 제목 길이에 "거친"제한을 부과하는 것 같습니다.

commands.cfg구성 파일 에 구성된 이메일 클라이언트를 확인하고보고 하십시오.
( notify-host-by-email및 notify-service-by-email설정).