Hello.
Murray S. Kucherawy wrote in
<cal0qlwbypxnc0agjasrf9pchazo_kmszny8iur7o-c+stif...@mail.gmail.com>:
|On Wed, Mar 5, 2025 at 3:54 PM Steffen Nurpmeso <stef...@sdaoden.eu> wrote:
|
|> But that DKIM2 draft mutilates SMTP to *only* work in this one
|> recipient mode: even if a mailing-list has hundreds of Gmail
|> subscribers, where ACDC would (could) send one message to all of
|> those in a single transaction, DKIM2 sends hundreds!
|
|The argument has been made that the bulk of Internet mail these days is
|single recipient anyway, so the load increase this would cause is
|negligible.
Yes, i think it was Mr. Gondwana when presenting the fact. At
minimum.
|Someone who has data to back up that claim could probably help us out here.
Now extended by Richard Clayton for Yahoo.
But. But it misses the point, too. It misses the point that this
is a snapshot as of today, for two or three american / australian
giants, and maybe, in between the lines, a german one that is
known to be no good to customers (me included -- i confirm this to
a judge; some years passed, however), and it misses the point that
DKIM is a helper of SMTP, it should not put constraints on SMTP
unless there is a pressing need, and in conjunction with the SMTP
people it is agreed there is really no way around doing it, and
then. Else not. Imho.
So there is no need (imho; yes for ACDC), and then, what is for
example with this VERP SMTP extension that i noted in the email to
Richard Clayton before dinner? Ie, simply turn {MAIL FROM,RCPT
TO+} into {(MAIL FROM,RCPT TO+)+}, and then it is possible to send
VERP personalized envelope return addresses to many in a single
transaction, over the wire. This is a 30 seconds thinking, and it
would be made impossible by this DKIM2 draft, not by ACDC. And
that is a thought in 2025 --- what if in 2030 a really good and
important idea comes along? DKIM2 is in the way of SMTP, and that
is not a good thing. ACDC is not. That is a value by itself.
|> ACDC is activated when the receiver announces support.
|> The DKIM subsignature is created for the mailing-list.
|> The mailing-list then distributes further, creating normal
|> signatures and per-receiver-domain subsignatures as necessary.
|> There is no clash.
|
|For everyone else, Steffen appears to be referring to:
|https://datatracker.ietf.org/doc/draft-nurpmeso-dkim-access-control-diff\
|-changes/
Thank you. Well; thank you.
|> One thing is plain: until ACDC or DKIM2 have penetrated the
|> infrastructure, the current mess of DMARC and ARC will have to be
|> dealt with! This IETF has forced all those people to implement
|> this merde, and it likely takes a decade or something until it is
|> iterated away!!
|
|Huh? The IETF hasn't forced anyone to do anything.
Sure it has; it has published those standards, software has been
written, and became desirable and/or even necessary in order to
take part in email communication successfully. There is a deep
penetration with DKIM / ARC / DMARC / SPF in the DNS, and also on
the software side. This installation base exists, and it will
take many years until it has been iterated out; maybe decades.
As an example, your OpenDKIM, even though it does not support the
Ed25519 key (let alone adaed25519), it is in massive use in the
"normal people's infrastructure" (not the giants etc), and most
questions and talks *i* hear regarding DKIM, it is about OpenDKIM,
not dkimpy, or a perl thing, or what; possibly rspamd comes near,
in total only it possibly exceeds OpenDKIM, but it is much more
than only DKIM, is it. And OpenDKIM is not being developed for
ten years! Ten!
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
