From: "Lukas Wagner" <l.wagner@proxmox.com>
To: "Shannon Sterz" <s.sterz@proxmox.com>, <pve-devel@lists.proxmox.com>
Subject: Re: [PATCH proxmox] fix #7814: send-mail: normalize LF line endings to CRLF endings
Date: Wed, 29 Jul 2026 10:18:06 +0200 [thread overview]
Message-ID: <DKAWO5F5IHBR.KOBD71LSM08S@proxmox.com> (raw)
In-Reply-To: <20260714084719.68076-1-s.sterz@proxmox.com>
Hi Shannon,
sorry for the delay in getting to review this. Some notes inline.
For what it's worth, this seems to work as advertised. Code also looks
okay to me in its current form. If you decide to act upon my feedback,
I'll quickly go over it again and send another R-b for that as well.
Tested-by: Lukas Wagner <l.wagner@proxmox.com>
Reviewed-by: Lukas Wagner <l.wagner@proxmox.com>
On Tue Jul 14, 2026 at 10:47 AM CEST, Shannon Sterz wrote:
> RFC5321 Section 2.3.8 requires that mails do not contain bare CR or LF
> bytes. this patch normalizes unix style LF line endings to CRLF line
> endings. it also removes bare CR bytes.
>
> when text would be base64 encoded anyway, CR bytes will be dropped, to
> keep the behavior for encoded and non-encoded text aligned. however,
> since this code was already extensively tested against multiple MUAs,
> encoded LF line endings are kept as-is.
>
> also adds tests to encode this behavior.
>
> Signed-off-by: Shannon Sterz <s.sterz@proxmox.com>
> ---
> proxmox-sendmail/src/lib.rs | 246 ++++++++++++++++++++++++++++++++----
> 1 file changed, 220 insertions(+), 26 deletions(-)
>
> diff --git a/proxmox-sendmail/src/lib.rs b/proxmox-sendmail/src/lib.rs
> index b3ff56e5..a73e8eb7 100644
> --- a/proxmox-sendmail/src/lib.rs
> +++ b/proxmox-sendmail/src/lib.rs
> @@ -50,7 +50,10 @@ fn encode_base64_formatted<T: AsRef<[u8]>>(raw: T) -> String {
> }
>
> fn encode_filename_formatted(filename: &str) -> String {
> - let encoded = format!("UTF-8''{}", utf8_percent_encode(filename, RFC5987SET));
> + let encoded = format!(
> + "UTF-8''{}",
> + utf8_percent_encode(&filename.replace('\r', ""), RFC5987SET)
> + );
>
> let format_prefix = |l| {
> if let Some(l) = l {
> @@ -63,6 +66,18 @@ fn encode_filename_formatted(filename: &str) -> String {
> format_encoded_text(&encoded, format_prefix, ";", 0, true)
> }
>
> +/// Strip bare CR bytes, than base64 encode. This is useful to make sure we treat encoded (header)
nit: should be 'then' instead of 'than'
> +/// values the same as non-encoded one. Stripping CR bytes is necessary according to RFC 5321 Section
> +/// Section 2.3.8 (https://datatracker.ietf.org/doc/html/rfc5321#section-2.3.8).
> +fn strip_cr_base64<T: AsRef<[u8]>>(raw: T) -> String {
> + let normalized: Vec<u8> = raw
> + .as_ref()
> + .iter()
> + .filter_map(|b| (*b != b'\r').then_some(*b))
> + .collect();
> + proxmox_base64::encode(&normalized)
> +}
> +
> /// Helper function used to format text to not exceed line limits imposed by standards such as RFC
> /// 2045 Section 6.8 that specifies that Base64 content transfer encoded text "must be represented
> /// in lines of no more than 76 characters each". It also allows taking into account any necessary
> @@ -166,11 +181,7 @@ impl Recipient {
> fn format_recipient(&self) -> String {
> if let Some(name) = &self.name {
> if !name.is_ascii() {
> - format!(
> - "=?utf-8?B?{}?= <{}>",
> - proxmox_base64::encode(name),
> - self.email
> - )
> + format!("=?utf-8?B?{}?= <{}>", strip_cr_base64(name), self.email)
> } else {
> format!("{name} <{}>", self.email)
> }
> @@ -199,7 +210,7 @@ impl Attachment<'_> {
> if self.filename.is_ascii() {
> let _ = write!(attachment, "{}", &self.filename);
> } else {
> - let encoded = proxmox_base64::encode(&self.filename);
> + let encoded = strip_cr_base64(&self.filename);
> let prefix_fn = |line| {
> if Some(0) == line {
> "=?utf-8?B?"
> @@ -451,7 +462,10 @@ impl<'a> Mail<'a> {
>
> /// Forwards an email message to a given list of recipients.
> ///
> - /// `message` must be compatible with ``sendmail`` (the message is piped into stdin unmodified).
> + /// `message` must be compatible with ``sendmail``. The message is piped into `stdin`
> + /// unmodified. One exception is stripping bare CR bytes and normalizing LF line endings to
> + /// CRLF line endings in accordance with RFC 5321 Section 2.3.8
> + /// (https://datatracker.ietf.org/doc/html/rfc5321#section-2.3.8).
> #[cfg(feature = "mail-forwarder")]
> pub fn forward(
> mailto: &[&str],
> @@ -485,11 +499,27 @@ impl<'a> Mail<'a> {
> .spawn()
> .with_context(|| "could not spawn sendmail process")?;
>
> + let capacity = message.iter().fold(0, |acc, e| match *e {
> + b'\r' => acc,
> + b'\n' => acc + 2,
> + _ => acc + 1,
> + });
No hard feelings, this is not a hot code path after all, but I guess you
could just multiply message.len() with some constant factor (e.g. 2) to
get the initial capacity and avoid the double iteration. The message is
likely not going to be larger than a couple hundred bytes or a few
kilobytes, so the extra memory does not matter IMO.
> +
> + let mut normalized_message: Vec<u8> = Vec::with_capacity(capacity);
> +
> + for byte in message {
> + match byte {
> + b'\r' => continue,
> + b'\n' => normalized_message.extend_from_slice(&[b'\r', b'\n']),
> + b => normalized_message.push(*b),
> + }
> + }
> +
> sendmail_process
> .stdin
> .take()
> .unwrap()
> - .write_all(message)
> + .write_all(&normalized_message)
> .with_context(|| "couldn't write to sendmail stdin")?;
>
> sendmail_process
> @@ -520,7 +550,9 @@ impl<'a> Mail<'a> {
> write!(mail, "\n--{file_boundary}--")?;
> }
>
> - Ok(mail)
> + // normalize line endings from `\n` to `\r\n` and drop bare `\r` according to RFC 5321
> + // 2.3.8: https://datatracker.ietf.org/doc/html/rfc5321#section-2.3.8
> + Ok(mail.replace('\r', "").replace('\n', "\r\n"))
> }
>
> fn format_header(
> @@ -561,7 +593,7 @@ impl<'a> Mail<'a> {
> writeln!(
> header,
> "Subject: =?utf-8?B?{}?=",
> - proxmox_base64::encode(&self.subject)
> + strip_cr_base64(&self.subject)
> )?;
> } else {
> writeln!(header, "Subject: {}", self.subject)?;
> @@ -571,7 +603,7 @@ impl<'a> Mail<'a> {
> writeln!(
> header,
> "From: =?utf-8?B?{}?= <{}>",
> - proxmox_base64::encode(&self.mail_author),
> + strip_cr_base64(&self.mail_author),
> self.mail_from
> )?;
> } else {
> @@ -606,17 +638,15 @@ impl<'a> Mail<'a> {
> header.push_str("Auto-Submitted: auto-generated;\n");
>
> for (key, value) in &self.headers {
> - // Strip CR/LF so an interpolated key or value cannot inject extra header lines.
> - let key = key.replace(['\r', '\n'], "");
> - let value = value.replace(['\r', '\n'], "");
> + // Strip LF so an interpolated key or value cannot inject extra header lines. Bare CR
> + // will be stripped for non-ASCII text before encoding and for ASCII text globally
> + // before finishing formatting.
> + let key = key.replace('\n', "");
> + let value = value.replace('\n', "");
I wonder whether it would be better to just return errors if there are
control characters in Subject, headers, recipient... what do you think?
next prev parent reply other threads:[~2026-07-29 8:18 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-14 8:47 [PATCH proxmox] fix #7814: send-mail: normalize LF line endings to CRLF endings Shannon Sterz
2026-07-28 15:32 ` Shannon Sterz
2026-07-29 8:18 ` Lukas Wagner [this message]
2026-07-30 14:00 ` Shannon Sterz
2026-07-30 14:02 ` Shannon Sterz
-- strict thread matches above, loose matches on Subject: below --
2026-07-30 14:01 Shannon Sterz
2026-07-30 14:02 ` Shannon Sterz
2026-07-31 6:54 ` Lukas Wagner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DKAWO5F5IHBR.KOBD71LSM08S@proxmox.com \
--to=l.wagner@proxmox.com \
--cc=pve-devel@lists.proxmox.com \
--cc=s.sterz@proxmox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.