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
