From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <pbs-devel-bounces@lists.proxmox.com> Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id DA4D61FF15F for <inbox@lore.proxmox.com>; Mon, 2 Dec 2024 13:11:36 +0100 (CET) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id D5CDA16726; Mon, 2 Dec 2024 13:11:41 +0100 (CET) Message-ID: <7c1af4a8-acc4-432a-bf5f-6a02d9aad915@proxmox.com> Date: Mon, 2 Dec 2024 13:11:38 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird To: Proxmox Backup Server development discussion <pbs-devel@lists.proxmox.com>, Shannon Sterz <s.sterz@proxmox.com> References: <20241129105321.143877-1-s.sterz@proxmox.com> <47c2f30e-1676-4acf-a55e-ba2b55660eb6@proxmox.com> <D615X0MIPMMY.3JB37Q4Q4W897@proxmox.com> Content-Language: de-AT, en-US From: Lukas Wagner <l.wagner@proxmox.com> In-Reply-To: <D615X0MIPMMY.3JB37Q4Q4W897@proxmox.com> X-SPAM-LEVEL: Spam detection results: 0 AWL 0.009 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 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_NONE 0.001 SPF: HELO does not publish an SPF Record SPF_PASS -0.001 SPF: sender matches SPF record Subject: Re: [pbs-devel] [PATCH proxmox 1/4] sendmail: add sendmail crate X-BeenThere: pbs-devel@lists.proxmox.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Proxmox Backup Server development discussion <pbs-devel.lists.proxmox.com> List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pbs-devel>, <mailto:pbs-devel-request@lists.proxmox.com?subject=unsubscribe> List-Archive: <http://lists.proxmox.com/pipermail/pbs-devel/> List-Post: <mailto:pbs-devel@lists.proxmox.com> List-Help: <mailto:pbs-devel-request@lists.proxmox.com?subject=help> List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel>, <mailto:pbs-devel-request@lists.proxmox.com?subject=subscribe> Reply-To: Proxmox Backup Server development discussion <pbs-devel@lists.proxmox.com> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: pbs-devel-bounces@lists.proxmox.com Sender: "pbs-devel" <pbs-devel-bounces@lists.proxmox.com> 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. -- - Lukas _______________________________________________ pbs-devel mailing list pbs-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel