On Tue, Mar 25, 2025, 7:21 a.m. Alessandro Vesely <ves...@tana.it> wrote:
> On Mon 24/Mar/2025 14:13:01 +0100 Richard Clayton wrote: > > In message <04daef5f-46a1-4393-8f42-677d2d375...@tana.it>, Alessandro > Vesely <ves...@tana.it> writes > > > >>Accommodating multiple recipients in the signature would have the added > value > >>of confirming to whom a message is destined. There are companies that > need to > >>certify to each recipient who the other recipients of a message are. A > real > >>case, for example, is described here: > >>https://sourceforge.net/p/courier/mailman/message/16554252/ > > > > that case describes a company that chooses to reveal who the other > > recipients are by eschewing the use of Bcc: > > > > "need to certify" is way too strong a description of what is going on > > > > also -- all they will be doing is putting all the recipients in a cc: > > header field (or in To:, comes to the same thing) [and then there's no > > actual guarantee that all of the purported messages were sent...] > > > > You can do that as well with DKIM2 ... you just cannot combine > > deliveries by using multiple RCPT TO when running the SMTP protocol > > > >>An MTA may want to offer this capability as a feature. > > > > what feature is that ? and why is an MTA going to be offering features > > relating to the cc: field ?? > > > Dunno, but it's frustrating when there are messages to a dozen or so > recipients > one of which is invalid. The message bounces to the author only. All > other > participants who hit reply-all are bound to get a similar bounce in turn. > If > someone finds a remedy for this, a protocol forcing single recipient mode > might > not help. > I don't think we're changing the state of things here by requiring a single recipient. If a message is delivered in N transactions, transactions prior to the one containing the failed recipient (potentially at different MTAs) would not know that this happened. There would need to be some post-transaction status signalling, and if that exists I don't see any reason why it would depend on transaction sizes greater than one. This seems more like a MTA feature that suppresses bounces for recipients of replies if the message being replied to wasn't delivered successfully. I'd question the utility of such a feature since other thread participants should probably know that their mail wasn't delivered. > > > >>A receiver only needs to check that the envelope value(s) are /included/ > in the > >>signed rt=. It is not much more difficult than comparing single values. > > > >>The only drawback, AFAICS, is that when a message with multiple > recipients is > >>forwarded by a non-DKIM2 agent, or replayed, the final recipient cannot > >>determine which one of the signed recipients is the culprit. > > > > also if it forwarded by a DKIM2 aware system then the recipient of that > > forwarded email has rather more work to do in order to avoid replay. > > It can validate the chain by checking that the forwarder is legit: > > r = 2nd sig's mf= > for x in 1st sig's rt= > if x =~ r > legit = true > break > > When the 1st signature contains a single recipient, the loop terminates > immediately. If rt= MUST be single recipient, you can remove the for loop > altogether. The difference seems negligible to me. > I don't see the value of this at all if looking for a subset. You don't have the property that being listed in rt= means they got a copy, and also don't have the property that not being listed in rt= means they didn't get a copy. > Best > Ale > -- > > > > > _______________________________________________ > Ietf-dkim mailing list -- ietf-dkim@ietf.org > To unsubscribe send an email to ietf-dkim-le...@ietf.org >
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
