Wietse Venema via Postfix-users wrote in
 <4vstkr2gkhzj...@spike.porcupine.org>:
 |Steffen Nurpmeso via Postfix-users:
 |> Wietse Venema via Postfix-users wrote in
 |>  <4vsq5f6q3nzj...@spike.porcupine.org>:
 |>|Tim Coote via Postfix-users:
 |>  ..
 |>|> SMTP headers are often 'folded' as they flow through MTAs. The
 |>|> standard approach to folding and unfolding is covered in rfcs 5322
 |>  ...
 |>|3) Lines that exceed 998 bytes (not including <CR><LF>) cannot be
 |>|   sent in SMTP. The result of sending such text is UNDEFINED.
 |>  ...
 |>|    When a line is too long, the Postfix SMTP client inserts
 |>|    <CR><LF><SPACE> (controlled by smtp_line_length_limit).  
 |> 
 |> This is a deficit of the entire RFC *822 series that a superficial
 |> whitespace is necessary at that point.  It was simply not on the
 |> table, and i got not even an answer on that in private
 |> communication (but maybe because of my way of speaking things out,
 |> i mean, isn't that just a desaster: this *breaks* the protocol).
 |> (On the other hand the dinosaur nmh just got (partially) proper
 |> line folding in September last year:
 |> 
 |>   http://git.savannah.gnu.org/cgit/nmh.git/commit/?id=542cb12b6d0646b7117\
 |>   72ee97c1e2aacf2bada86
 |> 
 |> and they will fail for the artificial case as i said in
 |> 
 |>   https://lists.nongnu.org/archive/html/nmh-workers/2023-08/msg00010.html
 |>   [https://lists.nongnu.org/archive/html/nmh-workers/2023-08/msg00011.htm\
 |>   l])
 |> 
 |>|    Before Postfix inserted <CR><LF><SPACE>, some MTA would insert
 |>|    a line break after ~1024 without adding a space. This would
 |>|    "terminate" the message header, destroy the MIME structure, and
 |> 
 |> This is really what they do?  Then .. my "artificial whitespace"
 |> thought of a decade ago would be wrong.  I would have thought they
 |> possibly reformat with RFC 2047 (if they can), as i said in the
 |> msg00011 thing above.
 |
 |Yes this was a real problem.
 |
 |For example, an email message like this:
 |
 |    label: value
 |    label: value-that exceeds-smtp-limit
 |    ...zero or more label: value...
 |    MIME-Version-1.0
 |    Content-type: multipart/mixed, boundary="foobar"
 |    END_OF_PRIMARY_HEADER
 |
 |    This is a multi-part message in MIME format.
 |
 |    --foobar
 |    first body part 
 |     
 |    --foobar
 |     first body part
 |
 |    --foobar--
 | 
 |Was received as:
 |
 |    label: value
 |    label: value
 |    label: first-part-of-value-that-exceeds-smtp-limit
 |    END_OF_PRIMARY_HEADER
 | 
 |    first body line with remainder-of-value-that-exceeds-smtp-limit
 |
 |>From here on all remaining content including headers and MIME
 |boundaries was received as one large non-MIME message body and was
 |displayed to the user in its encoded form includeing MIME boundaries
 |encoded text (quoted-printable or base62 encoded).
 |
 |Why did that happen? Because some MTA's input reader did not know
 |if it was reading a header or body line.

Very interesting.  All i knew until know is that there were quite
some messages without separating empty line in between headers and
body, "we" (the MUA i maintain) do a "find :" dance thus, and in
the worst case add one.  (This MUA comes from the 70s and still
mostly thinks email==(single-message) MBOX.)

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

Reply via email to