I think the current idea is to have dedicated unique signatures for every mail-from/rcpt-to combination and that's the reason for going down to a single RCPT-TO. A spammer therefore cannot reuse a message and "replay" it to other recipients. And it's not about single transaction vs multiple transactions, it's about single a single RCPT-TO per transaction vs multiple RCPT-TOs per transaction. It's still totally fine to send multiple emails with the help of RSET on a single open connection. This will also not break any forwarding, as the second idea is that every hop also signs with a new signature for every unique mail-from/rcpt-to combination that comes out of a forward configuration. This will essentially create a signed forward path that allows every involved hop to determine if they think the message is spam. This makes "replay" "impossible" as a side effect. But it also makes it possible to bounce back via the recorded return path to the last hop and therefore solves the privacy issue that exists today, as we would prevent "bouncing" to the initial mail-from and therefore disclosing forwards to the initial sender.
BCC is also not an issue as this does not impact the handling. As the initial mail-from is known to BCC recipients anyway and the rcpt-to is now limited to one and would also only contain the individual BCCed recipient. Tobias Herkula Senior Product Owner Mail Security Product Management Mail Transfer & Mail Security 1&1 Mail & Media GmbH ________________________________________ From: Michael Thomas <[email protected]> Sent: 05 March 2025 22:07 To: [email protected] Subject: [Ietf-dkim] Re: New drafts published On 3/5/25 12:29 PM, Tobias Herkula wrote: > I'm part of that SMTP audience and I'm looking forward to reducing the number > of RCPT-TOs in a transaction to one. I also think of the joy of having a > cryptographic signature that covers MAIL-FROM and RCPT-TO in addition to the > already covered headers and the body of an email. Bringing up privacy risks > for a protocol like SMTP is a lame excuse as, while SMTP is stable, there is > a lack of any privacy related functionality in the base protocol that were > only solved by additions over time. > > The re-chartering of the DKIM WG comes from a lot of frustrations Mailbox > Providers have in the current ecosystem that we (at least I) want to solve > with the involvement of the community and not by side stepping it and coming > around with a finished and polished solution. So you can see this as another > addition to the SMTP world that will hopefully solve the problems that are > still around. Problems that were perhaps lightheartedly described in the > charter but are real problems that at least for me as a Mailbox Provider I > have to fight every single day. > > The only argument I find in your comments are, “I don’t want this to change > and therefore I am against this change.“ I don’t think that this is a proper > way to go forward in an ever changing environment. > I've been reading the draft mentioned in the charter re: replay and rcpt-to and don't understand why that changes anything wrt replay. If there is a message that a spammer has discovered passes a recipient's spam filter, what difference does it make if it's a single smtp transaction or multiple transactions? If the idea is that it is somehow bound to the original rcpt-to, that breaks a significant amount of use cases in the email architecture (forwarding) so I sure hope it's not that. The draft does sort of imply that a Bcc'd address will end up in the signature block, which completely defeats the purpose of Bcc which sounds like a really bad idea. Mike _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected] _______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
