From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate001.proxmox.com (gate001.proxmox.com [IPv6:2a0f:8001:1:32::40]) by lore.proxmox.com (Postfix) with ESMTPS id 430931FF0AA for ; Tue, 20 Oct 2026 12:23:24 +0200 (CEST) Received: from gate001.proxmox.com (localhost.localdomain [127.0.0.1]) by gate001.proxmox.com (Proxmox) with ESMTP id A1FFD2156F; Tue, 20 Oct 2026 12:23:23 +0200 (CEST) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Tue, 20 Oct 2026 12:23:16 +0200 Message-Id: Subject: Re: [PATCH proxmox] fix #7814: send-mail: normalize LF line endings to CRLF endings To: "Samuel Rufinatscha" , X-Mailer: aerc 0.20.0 References: <20260730140126.444424-1-s.sterz@proxmox.com> <8e9a15bd-c981-4e74-b751-3e7a5683f056@proxmox.com> In-Reply-To: From: "Shannon Sterz" X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1792491796181 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.779 Adjusted score from AWL reputation of From: address DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment (newer systems) RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/, medium trust SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Message-ID-Hash: 7KKQ233WR5TYDOZIU3QGDLJ5IFMLVEK4 X-Message-ID-Hash: 7KKQ233WR5TYDOZIU3QGDLJ5IFMLVEK4 X-MailFrom: s.sterz@proxmox.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list List-Id: Proxmox Backup Server development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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