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.