CRLF miễn phí trong Chủ đề: dòng - tại sao nó ở đó và nó có hợp pháp không?

Tôi đang gặp vấn đề với hệ thống NAGIOS gửi email đến dịch vụ email-to-SMS phổ biến. Dịch vụ email-to-SMS nhận email có văn bản trong Subject:dòng và gửi chúng đến số điện thoại di động được mã hóa trong To:trường. Càng xa càng tốt. Đáng buồn thay, sendmail (và postfix trước khi nó) dường như được chèn một CRLF vu vơ vào (nhất thiết phải dài) Subject:đường, và đó là gây tin nhắn SMS của tôi được rút ngắn tại CRLF khi và chỉ khi các Subject:dòng chứa một hoặc nhiều dấu hai chấm qua những vu vơ CRLF.

Tôi tự tin rằng các tin nhắn đang được tạo chính xác, nhưng để chắc chắn, đây là tôi tạo ra một tin nhắn thử nghiệm hoàn toàn gật đầu với chính mình, với một Subject:dòng dài :

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

Lưu ý rằng không có dấu hai chấm trong Subject:dòng này ; tất cả những gì tôi đang làm ở đây là cho thấy một CRLF bổ sung được chèn vào dây. Đây là kết quả của 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

Khoảng một nửa (được đánh dấu in đậm + in nghiêng), giữa 501234567và 601234567trong Subject:tiêu đề ban đầu, bạn có thể thấy một CRLF được chèn ( 0x0d 0x0a, trên bãi chứa hex bên trái, ..trên văn bản đơn giản bên phải).

MTA nhận có vẻ rất vui khi xử lý hậu kỳ này và khi tôi nhìn vào thư được lưu trên đĩa ở đầu nhận, tôi chỉ thấy một LF (0x0a) trong dòng Tiêu đề: và dòng được phân tích chính xác và trong dòng của nó toàn bộ bởi, ví dụ , alpine. Tuy nhiên, CRLF đang ở trên mạng và giữa tôi và những người hỗ trợ gửi email qua SMS (xuất sắc), chúng tôi đã xác định rằng đây là những nguyên nhân gây ra sự cố.

Vì vậy, câu hỏi của tôi là: một MTA có hợp pháp để chèn một CRLF vô cớ vào dây không?

Nếu đúng như vậy, và tôi có thể chứng minh điều đó, thì đó là vấn đề của nhà gửi email đến SMS, vì họ không khoan dung. Nếu không, hoặc là vậy nhưng tôi không thể chứng minh được thì nó trở thành vấn đề của tôi, vì vậy một câu trả lời với các tài liệu tham khảo sẽ hữu ích nhất.

Chỉnh sửa : Bây giờ tôi có thể làm sạch rằng dịch vụ email-SMS đang được đề cập là kapow . Khi vấn đề này được giải thích cho họ, họ đã giải quyết nó, làm việc với tôi để phát triển và thử nghiệm bản sửa lỗi và đã triển khai bản sửa lỗi. Dòng chủ đề dài của tôi với dấu hai chấm bây giờ được chuyển tiếp chính xác vào SMS. Tôi thường không thổi kèn các công ty riêng lẻ, đặc biệt là không phải trên SF, nhưng tôi nghĩ rằng đáng lưu ý rằng kapow Did The Right Thing. (Tuyên bố miễn trừ trách nhiệm: Tôi không có mối liên hệ nào với kapow ngoại trừ với tư cách là một khách hàng trả tiền, họ hài lòng về cách họ giải quyết vấn đề của mình.)

Chà, nếu tôi hiểu RFC 822, chúng là hợp pháp trong một số trường hợp nhất định, tôi nghĩ đó là một vật phẩm từ thời của màn hình nhỏ với độ phân giải 24x80 ..

Các phần này dường như khá rõ ràng Các chủ đề có thể được gấp lại và gấp lại là một ký tự CRLF cộng với LWSP (khoảng trắng tuyến tính) .. có thể chúng đã được thay thế, Wietse (trong danh sách postfix) biết RFC của anh ấy từ bên ngoài nếu bạn muốn một câu trả lời dứt khoát

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.

Chỉnh sửa bởi người hỏi : Tôi hy vọng NickW sẽ tha thứ cho tôi vì đã thêm một ghi chú vào hiệu ứng RFC822 đã bị RFC2822 làm cho lỗi thời, nhưng RFC mới nói khá nhiều điều tương tự trong phần 2.2.3 , và xác nhận rõ ràng rằng việc gấp như vậy nên được gỡ bỏ trước khi bất kỳ xử lý tiếp theo được thực hiện:

Mỗi trường tiêu đề là một dòng ký tự duy nhất bao gồm tên trường, dấu hai chấm và thân trường. Tuy nhiên, để thuận tiện và để giải quyết các giới hạn ký tự 998/78 trên mỗi dòng, phần thân trường của trường tiêu đề có thể được chia thành một biểu diễn nhiều dòng; cái này được gọi là "gấp". Nguyên tắc chung là bất cứ nơi nào tiêu chuẩn này cho phép gấp khoảng trắng (không chỉ đơn giản là các ký tự WSP), CRLF có thể được chèn trước bất kỳ WSP nào. Ví dụ: trường tiêu đề:

       Subject: This is a test

có thể được biểu diễn dưới dạng:

       Subject: This
        is a test

Lưu ý: Mặc dù các thân trường có cấu trúc được xác định theo cách mà việc gấp có thể diễn ra giữa nhiều mã thông báo từ vựng (và thậm chí trong một số mã thông báo từ vựng), việc gấp NÊN bị giới hạn trong
việc đặt CRLF ở các cú pháp cú pháp cấp cao hơn. Ví dụ: nếu phần thân trường được xác định là giá trị được phân tách bằng dấu phẩy, thì nên thực hiện gập sau khi dấu phẩy phân tách các mục có cấu trúc theo sở thích đến các vị trí khác nơi trường có thể được gấp lại, ngay cả khi được phép ở nơi khác.

Quá trình chuyển từ biểu diễn nhiều dòng gấp này của trường tiêu đề sang biểu diễn một dòng của nó được gọi là "mở ra". Việc mở ra được thực hiện bằng cách đơn giản loại bỏ bất kỳ CRLF nào ngay sau đó là WSP. Mỗi trường tiêu đề phải được xử lý ở dạng mở ra để đánh giá cú pháp và ngữ nghĩa hơn nữa.

Điều này không phải để làm mất đi sự thật rằng NickW đã vô tình chỉ cho tôi khá nhiều chính xác những gì tôi cần biết, chỉ để giúp câu trả lời này phù hợp với bất kỳ ai có thể vấp ngã trong tương lai.

Máy chủ Sendmail (SendMail) áp đặt giới hạn độ dài dòng nhưng cao hơn nhiều (990 byte trở lên đối với người gửi thư smtp).

Gửi thư! = SendEmail

Theo tôi được biết Nagios sử dụng bởi mặc định SendEmail khách hàng để gửi email. Có vẻ như ứng dụng email mà bạn tạo Nagios sử dụng sẽ áp đặt các giới hạn "khắc nghiệt" như vậy đối với độ dài của dòng tiêu đề / tiêu đề email.

Kiểm tra và báo cáo email client được cấu hình trong commands.cfgtập tin cấu hình.
( notify-host-by-emailvà notify-service-by-emailcài đặt).