CRLF ที่ไม่พอใจในหัวเรื่อง: line - ทำไมจึงมีและถูกกฎหมาย?

ฉันกำลังประสบปัญหากับระบบ NAGIOS ที่ส่งอีเมลไปยังบริการอีเมลถึง SMS ยอดนิยม บริการ email-to-SMS จะรับอีเมลพร้อมข้อความในSubject:บรรทัดและส่งไปยังหมายเลขโทรศัพท์มือถือที่เข้ารหัสในTo:ฟิลด์ จนถึงตอนนี้ดีมาก น่าเศร้าที่ sendmail (และ postfix ก่อนที่มันจะ) ดูเหมือนจะแทรก 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และ601234567ในSubject:ส่วนหัวดั้งเดิมคุณสามารถเห็น CRLF ที่ถูกแทรก ( 0x0d 0x0aในการถ่ายโอนข้อมูลฐานสิบหกด้านซ้าย..บนข้อความธรรมดาด้านขวา)

MTA ที่ได้รับดูเหมือนจะมีความสุขที่จะทำการโพสต์สิ่งนี้และเมื่อฉันดูจดหมายที่เก็บไว้บนแผ่นดิสก์เมื่อสิ้นสุดการรับฉันเห็นเฉพาะ LF (0x0a) ในบรรทัดหัวเรื่อง: และบรรทัดจะถูกวิเคราะห์อย่างถูกต้องและอยู่ในนั้น alpineโดยครบถ้วนเช่น อย่างไรก็ตาม CRLF อยู่ในสายและระหว่างฉันกับผู้สนับสนุนทางอีเมลถึง SMS ที่ยอดเยี่ยมเราได้พิสูจน์แล้วว่าสิ่งเหล่านี้เป็นสาเหตุของปัญหา

ดังนั้นคำถามของฉันคือ: มันถูกต้องตามกฎหมายหรือไม่สำหรับ MTA ที่จะแทรก CRLF เปล่า ๆ บนสาย?

หากเป็นเช่นนั้นและฉันสามารถพิสูจน์ได้ว่านั่นเป็นปัญหาของเฮ้าส์เมลเป็น SMS เพราะพวกเขาทนไม่ได้ หากไม่ใช่หรือเป็น แต่ฉันไม่สามารถพิสูจน์ได้มันจะกลายเป็นปัญหาของฉันดังนั้นคำตอบที่มีการอ้างอิงจะมีประโยชน์มากที่สุด

แก้ไข : ตอนนี้ผมสามารถมาทำความสะอาดที่บริการอีเมลการส่ง SMS ในคำถามคือKapow เมื่อปัญหาเหล่านี้ได้รับการอธิบายพวกเขาพวกมันก็ทำงานกับฉันเพื่อพัฒนาและทดสอบการแก้ไขและปรับใช้การแก้ไข หัวเรื่องที่มีความยาวของฉันที่มีเครื่องหมายโคลอนในตอนนี้ได้รับการถ่ายทอดอย่างถูกต้องใน SMSes โดยปกติฉันไม่ได้ทรัมเป็ตแต่ละ บริษัท โดยเฉพาะอย่างยิ่งไม่ได้อยู่ใน SF แต่ฉันคิดว่ามันควรค่าที่จะทราบว่า kapow ทำสิ่งที่ถูกต้อง (ข้อจำกัดความรับผิดชอบ: ฉันไม่มีส่วนเกี่ยวข้องกับ kapow ยกเว้นในฐานะลูกค้าที่ชำระเงินซึ่งมีความสุขกับวิธีที่พวกเขาจัดการกับปัญหาของเขา)

ถ้าฉันเข้าใจ RFC 822 พวกมันถูกกฎหมายในบางกรณีฉันคิดว่ามันเป็นสิ่งประดิษฐ์ตั้งแต่สมัยของหน้าจอขนาดเล็กที่มีความละเอียด 24x80 ..

ส่วนเหล่านี้ดูเหมือนจะค่อนข้างชัดเจนหัวเรื่องสามารถถูกพับเก็บได้และการพับเป็นอักขระ CRLF บวก LWSP (พื้นที่สีขาวแบบเส้นตรง) .. เป็นไปได้ว่าพวกเขาถูกยกเลิกแล้ว Wietse (ในรายการ postfix) รู้ RFC ของเขาหากคุณต้องการ คำตอบที่ชัดเจน

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 จะยกโทษให้ฉันสำหรับการเพิ่มบันทึกย่อถึงผลกระทบที่ RFC822 ถูกล้าสมัยโดย RFC2822 แต่ RFC ใหม่บอกว่าเหมือนกันมากในส่วนที่ 2.2.3และยืนยันอย่างชัดเจนว่าการพับดังกล่าวควร ถูกลบออกก่อนที่จะดำเนินการต่อไป:

แต่ละฟิลด์ส่วนหัวเป็นอักขระบรรทัดเดียวที่มีเหตุผลซึ่งประกอบด้วยชื่อฟิลด์โคลอนและเนื้อความฟิลด์ อย่างไรก็ตามเพื่อความสะดวกและเพื่อจัดการกับข้อ จำกัด ของอักขระ 998/78 ต่อบรรทัดส่วนเนื้อหาของฟิลด์ของฟิลด์ส่วนหัวสามารถแบ่งออกเป็นการแสดงหลายบรรทัด สิ่งนี้เรียกว่า "การพับ" กฎทั่วไปคือทุกที่ที่มาตรฐานนี้อนุญาตให้มีพื้นที่สีขาวแบบพับได้ (ไม่ใช่แค่ตัวอักษร WSP), CRLF อาจถูกแทรกก่อน WSP ใด ๆ ตัวอย่างเช่นฟิลด์ส่วนหัว:

       Subject: This is a test

สามารถแสดงเป็น:

       Subject: This
        is a test

หมายเหตุ: แม้ว่าร่างฟิลด์ที่มีโครงสร้างจะถูกกำหนดในลักษณะที่การพับสามารถเกิดขึ้นระหว่างโทเค็นศัพท์หลาย ๆ คำ (และแม้กระทั่งภายในโทเค็นคำศัพท์บางส่วน) การพับ SHOULD จะถูก จำกัด ให้
วาง CRLF ในระดับสูงกว่า ตัวอย่างเช่นหากมีการกำหนดเนื้อหาของฟิลด์เป็นค่าที่คั่นด้วยเครื่องหมายจุลภาคขอแนะนำให้การพับเกิดขึ้นหลังจากเครื่องหมายจุลภาคคั่นรายการที่มีโครงสร้างในการตั้งค่าไปยังสถานที่อื่นที่สามารถพับฟิลด์ได้แม้ว่าจะอนุญาตไว้ที่อื่น

กระบวนการย้ายจากการแสดงหลายบรรทัดแบบพับนี้ของฟิลด์ส่วนหัวไปยังการแสดงบรรทัดเดียวเรียกว่า "การแฉ" การคลายออกสามารถทำได้โดยเพียงแค่ลบ CRLF ใด ๆ ที่ตามมาทันทีด้วย WSP ฟิลด์ส่วนหัวแต่ละฟิลด์ควรได้รับการปฏิบัติในรูปแบบที่เปิดออกเพื่อการประเมินทางวากยสัมพันธ์และความหมายเพิ่มเติม

นี่ไม่ใช่การเบี่ยงเบนจากข้อเท็จจริงที่ว่า NickW ชี้ไปที่ฉันโดยไม่รู้ตัวว่าฉันต้องการรู้อะไรเพียงเพื่อช่วยให้คำตอบนี้ยังคงเกี่ยวข้องกับทุกคนที่อาจสะดุดในอนาคต

เซิร์ฟเวอร์ Sendmail (SendMail) กำหนดขีดจำกัดความยาวบรรทัด แต่สูงกว่ามาก (990 ไบต์ขึ้นไปสำหรับ smtp mailers)

SendMail! = SendEmail

ตามที่ฉันเข้าใจ Nagios ใช้โดยค่าเริ่มต้นไคลเอนต์ SendEmail เพื่อส่งอีเมล ดูเหมือนว่าไคลเอนต์อีเมลที่คุณใช้ Nagios จะใช้ข้อ จำกัด "รุนแรง" เช่นความยาวของบรรทัดหัวเรื่อง / หัวเรื่องอีเมล

ตรวจสอบและรายงานอีเมลไคลเอ็นต์ที่กำหนดค่าในcommands.cfgไฟล์กำหนดค่า
( notify-host-by-emailและnotify-service-by-emailการตั้งค่า)