From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 946F21FF141 for ; Tue, 16 Jun 2026 11:26:23 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id EF14637837; Tue, 16 Jun 2026 11:26:21 +0200 (CEST) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Tue, 16 Jun 2026 11:26:17 +0200 Message-Id: To: "Nicolas Frey" , Subject: Re: [PATCH proxmox 1/1] sendmail: add additional header map X-Mailer: aerc 0.20.0 References: <20260615092015.101174-1-n.frey@proxmox.com> <16fb3b78-3c77-4567-a09d-f4106c372533@proxmox.com> In-Reply-To: <16fb3b78-3c77-4567-a09d-f4106c372533@proxmox.com> From: "Shannon Sterz" X-Bm-Milter-Handled: 55990f41-d878-4baa-be0a-ee34c49e34d2 X-Bm-Transport-Timestamp: 1781601922594 X-SPAM-LEVEL: Spam detection results: 0 AWL 0.108 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DMARC_MISSING 0.1 Missing DMARC policy KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment 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: YYAUPY7IMOGPORKZAOX26HVQCZJAXOHA X-Message-ID-Hash: YYAUPY7IMOGPORKZAOX26HVQCZJAXOHA 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 VE development discussion List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On Mon Jun 15, 2026 at 4:01 PM CEST, Nicolas Frey wrote: > > > On 6/15/26 3:20 PM, Shannon Sterz wrote: >> On Mon Jun 15, 2026 at 11:20 AM CEST, Nicolas Frey wrote: >>> with corresponding methods to add them. >>> >> >> generally i like the idea of allowing callers to specify additional >> headers, but i wonder if this is a bit too lenient. usually, we try to >> handle all encoding and formatting for the caller here, so we can deal >> with being in compliance with all rfcs and mail related conventions here >> instead of all call-sites. >> > > Yeah I think it would be best to restrict in such a way that the > caller does not really care about encoding/formatting and it's all > done on the proxmox-sendmail site. Perhaps I should have sent it as an > RFC, because I was very unsure how lax we wanna be here/who needs to > deal with encoding/formatting the headers. maybe, doesn't make too much of a difference now tho ;) >> also this would allow setting headers that are set by proxmox-sendmail >> anyway twice. that's probably not ideal either. > > I did have a draft where it just removes those already set somewhere > else, but that felt a bit clunky, so also not ideal hm that feels like it could easily lead to misunderstanding by the caller on what takes priority. i don't think that's ideal either. >> >> so imo, we should either: >> >> * expose at least the formatting helpers here publically so callers can >> use them. >> * allow only a limitted set of headers, maybe we an enum. we can then >> handle formatting for the caller be seeing which enum type was >> provided >> >> what do you think? >> > > My initial goal was to make it so adding additional headers would not > need another crate bump in the future. Regardless of that, I think a > limited set of headers could work pretty well. I'll try the enum > approach and send a V2 if it looks good, thanks! fair enough. in that case we could consider a "generic" enum variant that gives the caller no guarantees for formatting or (de-)duplication as an escape hatch. in that case it is then at least clear to the caller that they are talking full responsibility for the "correctness" of adding such a header. tho i think starting without such an escape hatch and only adding it once we need it is probably preferable.