[pbs-devel] [PATCH proxmox 1/4] sendmail: add sendmail crate

[Shannon Sterz]

On Mon Dec 2, 2024 at 1:11 PM CET, Lukas Wagner wrote:
> On  2024-12-02 12:02, Shannon Sterz wrote:
> >> In the most common case, a notification mail might go to the members of an infra team of
> >> a organization, where the identities of other team members is not really sensitive information.
> >> I'd actually go as far and say that the info "who else was notified" is actually quite valuable
> >> and useful to have.
> >>
> >> Then again, I can see the benefits of masking, e.g. in the case of PBS datastore notifications,
> >> which might go to non-admin users (e.g. when PBS is offered as a service a la Tuxis).
> >>
> >> I don't care that much whether this is opt-in or opt-out at the crate level, but at the
> >> 'sendmail target' level I'd make this configurable and opt-in (gut feeling and to not
> >> change the current behavior, I'd be happy to be convinced for another way :) )
> >>
> >> What are your thoughts about this?
> >
> > making this configurable sounds reasonable to me. i'd tend towards
> > making the masking opt-out, though. at least on a crate level. my
> > use-case for this crate is to send mails to all participants of a
> > training, so there disclosing the mail addresses of other participants
> > could be really bad (even legally actionable, afaict). i can see the
> > value of this information in a notification scenario. however, i think
> > the implications of forgetting to disclose this in some scenarios is
> > much less detrimental than doing so in scenarios where we don't want to
> > disclose them.
> >
>
> I don't think we have to decide it for proxmox-notify's targets now.
> I'd suggest making masking default at the crate level with some way to disable it in the
> builder. In proxmox-notify, I'd opt-out for now to keep the current behavior.
> In the future we can easily add configuration parameter to the sendmail target config to
> configure this; then we can also reevaluate what a sane default would be at the target level.
> At the same time we can add the same behavior to smtp targets then so that
> the behavior is consistent with the sendmail target.

yup, that sounds sensible and is what i am currently work on, will
send a v2 later today.