Hi Tim,
On 11/27/2024 6:12 PM, Tim Wicinski wrote:
Emails often flow indirectly through multiple systems, undergoing
redirection, expansion into multiple copies via aliases and
mailing lists, as well as rewriting and filtering before
eventually arriving at a mailbox or being processed by a
receiving software agent.
The opening sentence sets a stage that matches many end-user
experience views of email, but misses the basic technical
distinction that is the essence of the enhancement being sought.
*As described in that sentence, email is delivered more than once,
before it is 'finally' delivered.*
So instead, perhaps:
It is common for an email to go through multiple
posting/delivery sequences, before eventually arriving at a
'final' mailbox or being processed by a 'final' receiving
software agent. Examples of such 'indirect' flow include
redirection through an alis, expansion into multiple copies
via an alias or a mailing list, as well as rewriting and
filtering before eventually arriving at a mailbox or being
processed by a receiving software agent.
...
I can see the distinction on the "final destination" of a message.
Are you wanting to say every time an email is processed - redirected,
expanded via an alias, etc that the message is 'delivered' ? then
we'll want to be very explicit how "delivered" is defined -
temporarily delivered before final/permanent delivered
It's not that I'm saying it, it's that it is what is happening. I did
not create this view. It is was the SMTP specification provides. (It
provides lots of other commentary, but if you restrict your reading to
the part that is actually the SMTP protocol, that is what it does.)
SMTP has a posting, followed by one or more 'direct' deliveries (or
failures, of course.) Relaying through MTAs is part of this. That is,
really, all an SMTP session does.
And it does not include going through translation gateways, mailing
lists, or the like.
An 'intermediary' might have the task of taking a delivered message and
then sending it farther on. It does this by _re-posting_ the message --
possibly in highly modified form -- which then eventually gets a fresh
delivery. This is exactly what happens for mailing lists.
My own view is that it is also is what happens for aliasing, but there's
been disagreement with some other email folk.
Note that a message sent to a mailing list is addressed to a mailing
list. It is not addressed to the 'final' recipients. That additional
addressing is done by the mailing list, not the original author. This is
a rather stark demonstration that the intermediary has taken delivery
and then re-posted the message.
Not surprisingly, I refer to RFC 5598 about such things, since the IETF
email community spent 5 years developing it. Again, for some reason,
some folk prefer to ignore it.
It will be necessary for any new design to work in parallel with
the existing mechanisms, and have a clear upgrade path.
If it is parallel, it is independent. So I don't know what it
means 'to work' in parallel. And I don't know what it means to
not work in parallel.
To achieve its goals, this work requires a wide scope. The design
may supersede, modify, or replace many parts of the current email
infrastructure and associated reporting mechanisms - while
retaining the ability to support existing use-cases.
Oh. In parallel with existing /email/. You want to replace the
current Internet Mail infrastructure. Gosh...
Forgive me, but, again, this is something for the IRTF, not the IETF.
I don't believe anyone here will claim that DKIM2 will replace the
current email delivering mechanisms. They will complement them,
hoping to show a better way forward. But email, like other
technologies, have a very long tail.
Please re-read their text, because that is exactly what it implies.
And if it isn't what that text means, then I don't know what it does mean.
At the least, then, the language needs to be a lot clearer about what is
meant.
* Mechanism document draft(s) adopted: Mar 2025
Only two more months for a stable specification effort? Really?
* Experiments and updated drafts: Apr 2025 - Nov 2025
* Implementation guide adopted: Nov 2025
* Group of documents sent to IESG: Dec 2025
Richard already mentioned most working groups have given up putting
delivering dates, and I agree with this. What the WG will deliver
seems logical.
They put dates in. I reacted to those estimates.
btw, I heard similar rumors about IETF desires to refrain from putting
dates in. Given history, it's an understandable view.
However given project management realities, the problem is failure to
take dates seriously and manage to them. Hence we constantly have
working groups lingering forever.
Removing dates eliminates a symptom, but does nothing about the disease.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
*** bluesky: @dcrocker.bsky.social ***
mast: @dcrocker@mastodon.social
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
