Umlaute? „Fünktionört“ es „wärklich?“

[Raketenwilli]

https://datatracker.ietf.org/doc/html/rfc5321#section-2.3.9

führt zu:

https://datatracker.ietf.org/doc/html/rfc2045#section-2.7

2.7.  7bit Data

   "7bit data" refers to data that is all represented as relatively
   short lines with 998 octets or less between CRLF line separation
   sequences [RFC-821].  No octets with decimal values greater than 127
   are allowed and neither are NULs (octets with decimal value 0).  CR
   (decimal value 13) and LF (decimal value 10) octets only occur as
   part of CRLF line separation sequences.


2.8.  8bit Data

   "8bit data" refers to data that is all represented as relatively
   short lines with 998 octets or less between CRLF line separation
   sequences [RFC-821]), but octets with decimal values greater than 127
   may be used.  As with "7bit data" CR and LF octets only occur as part
   of CRLF line separation sequences and no NULs are allowed.

…

2.10.  Lines

   "Lines" are defined as sequences of octets separated by a CRLF
   sequences.  This is consistent with both RFC 821 and RFC 822.
   "Lines" only refers to a unit of data in a message, which may or may
   not correspond to something that is actually displayed by a user
   agent.

RFC 2821 führt zu RFC 2048, die zu RFC 2049 führt…

https://datatracker.ietf.org/doc/html/rfc2049#section-3

3. Guidelines for Sending Email Data
…

(3) Many systems may elect to represent and store text data
          using local newline conventions.  Local newline
          conventions may not match the RFC822 CRLF convention --
          systems are known that use plain CR, plain LF, CRLF, or
          counted records.  The result is that isolated CR and LF
          characters are not well tolerated in general; they may
          be lost or converted to delimiters on some systems, and
          hence must not be relied on.

Auszug: „The result is that isolated CR and LF characters are not well tolerated in general“

... „das they may … converted to delimiters on some systems“ hab ich mit Outlook-Clients durch… die machen aus jedem <CR> oder <LF> beim Antworten immer <CRLF>, was ziemlich lustig ist, weil beim gegenseitigen Antworten dadurch wachsende Leerräume enstehen.

Du schreibst jetzt:

wenn man den erzwungenen Umbruch (gemäß SMTP-Spec übrigens nicht \r\n, sondern nur \r) mit einem Backslash am Ende der Zeile maskiert.

"\r" wäre jetzt doch <CR>. Ich glaube Du verwirrst mich und kannst mir sicher zeigen, wo das mit dem erzwungenem Umbruch als gültige Lösung steht.