Re: [PATCH proxmox 1/1] sendmail: add additional header map

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

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.