A few points:
1) A sender or intermediate can already send a new message per rcpt-to.
This is an operational issue, and has nothing to do with DKIM. Indeed,
lots of transactional mail already does this so you unsubscribe, etc.
2) In the case of a typical mailing list, for example, the original
rcpt-to will not match the rcpt-to when the list expands the recipients.
I've had a very hard time understanding this draft, but I'm guessing
there must be some consequence for a signature where the rcpt-to is
different than in the signature block. Assuming that it invalidates the
mismatched (typically original) signature, that sure sounds like it
breaks DKIM's mail forwarding survival requirement.
3) Any intermediary along the mail path is completely at liberty to
(re)sign a message already with DKIM.
4) Every hop can already determine whether it thinks something is spam.
I'm not sure what that has to do with anything.
5) I don't understand the supposed cause and effect of how that makes
replay "impossible".
6) As for Bcc, if the rcpt-to is somehow in the email message itself,
you've broken the promise that the message not contain the Bcc'd address.
7) I think Dave made the point in his comments on the draft -- which
deserves a reply -- that an intermediary can already change the
mail-from if it wants bounce messages. I assume that almost all mailing
lists do that so I'm not sure what the problem is.
Mike
On 3/5/25 1:23 PM, Tobias Herkula wrote:
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 <m...@mtcc.com>
Sent: 05 March 2025 22:07
To: ietf-dkim@ietf.org
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 -- 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
