Re: [PATCH proxmox] fix #7814: send-mail: normalize LF line endings to CRLF endings

["Shannon Sterz" <s.sterz@proxmox.com>]

On Tue Oct 20, 2026 at 11:50 AM CEST, Samuel Rufinatscha wrote:
> On 10/20/26 9:56 AM, Shannon Sterz wrote:
>> On Mon Oct 19, 2026 at 5:49 PM CEST, Samuel Rufinatscha wrote:
>>> Hi Shannon,
>>>
>>> I ran some additional tests, which passed. One note/question regarding
>>> the base64 path:
>>>
>>> Removing \r before base64 encoding changes an valid \r\n into \n after
>>> decoding but if I understand correctly previously it would have
>>> preserved \r\n (as of no normalization).
>>>   From the commit message I understand that removing CR before encoding
>>> is intentional but is changing valid CRLF intentional here too?
>>
>> i deemed a reasonable trade-off as stripping only if no \n follows would
>> have increased complexity quite a bit. note that i can't do the
>> `replace("\n", "\r\n")` trick there as that would transform bare `\n` to
>> CRLF. bare `\n` was extensively tested across multiple MUAs and free
>> mail providers (gmail, outlook, etc.), though, so i wanted to err on the
>> side of caution. since this was reported bug i wanted to give a
>> solution that should work sooner than later.
>>
>> however, since this has been dragged out already, i can eventually get
>> around to do another round of testing with just replace LF with CRLF
>> too. if you are aware of an rfc or best practice on what to do in these
>> cases, i'd appreciate any input, though.
>>
>> i can also provide a commit message that is a bit more telling when it
>> comes to this case in particular.
>>
>
> thanks for the explanation Shannon, make sense to me!
>
> according to RFC 2045 [0] (see 6.8 on page 25), if we would strictly
> follow that, it seems line breaks must be converted to CRLF before
> base64 encoding:
>
> "In particular, text line breaks must be converted into CRLF sequences
> prior to base64 encoding"
>
> i understand keeping the existing LF behavior for compatibility is
> good, also since this behavior is tested. so it makes sense for me to
> preserve this.
>
> regarding CRLF to LF before encoding, i think it would make sense
> to preserve CRLF too, as this was carried over previously and was in
> line with the RFC. alternatively, if I think for now it would be
> sufficient to note this case in the commit message.
>
> [0] https://www.rfc-editor.org/rfc/rfc2045#section-6.8

seems i missed, that so this clarifies how to handle this for the body
of mime messages at least. i'll send a patch that normalizes according
to that rfc then. imo, being standards compliant is preferable as it
usually gives the widest set of compatibility. thanks!

for headers it seems that 2047 only specifies that the encoding should
be identical to 2045 [1]. so I suppose `.replace("\r",
"").replace("\r\n", "")` should be fine there too. i'll update the patch
and add a test for these.

thanks for noticing and the input! :)

[1]: https://www.rfc-editor.org/info/rfc2047/#section-4.1