Pete Resnick wrote in
<5FEDA01D-9B91-4922-8A02-61EAB9E9463D@xxxxxxxxxxxx>:
|On 2 Nov 2024, at 10:48, Paul Wouters wrote:
...
|> It is not valid to discard these people’s views as “too late in
|> the process”.
|
|But it is valid to discard them if they are outside of the charter of
|the WG, which is a determination that the chairs and AD must make. The
|important text in our charter is:
|
|"This working group will conduct a limited review and revision to the
|base
|email specifications, and will publish new versions of these documents
|at
|Internet Standard status, per RFC 6410. The limited review is restricted
|to corrections and clarifications only, with a strong emphasis on
|keeping
|these minimal and avoiding broader changes to terminology or document
...
And this is exactly why i did not say anything in the past, and
was even corrected if i recall correctly once i said anything,
which was not about STARTTLS/Implicit TLS, however.
I take this opportunity to apologise for that "nonsense argument"
i said in response to the "40 year old protocol" statement of
Dave Crocker.
Nonetheless, SMTP is a very vital protocol, and therefore
i repeat it but with different vocabulary.
Take for example the wonderful Russian car Lada Niva, which is
even older than SMTP, even its short-time preprocessor, with only
mild optical changes. Once the EU published its newest and still
current exhaust directive it only took merely weeks until this
wonderful car was ready to stand it, not less than two years --
and this is nothing but the truth! -- before practically all other
manufacturers (Volkswagen, Mercedes-Benz etc) were "ready" for it;
according to technical data sheets only though, i am no(t)
(longer) with the industry, but self-speaking so or so. Ie you
can do it silently and super quick, or you are a slowly moving
hydrocephalus.
Even though John Klensin spoke against this in a private email
i continue to wonder why a short and simple addition like
Real mail security lies only in end-to-end methods involving the
message bodies, such as those that use digital signatures (see
RFC 1847 [26] and, e.g., Pretty Good Privacy (PGP) in RFC 4880
[50] or Secure/ Multipurpose Internet Mail Extensions (S/MIME)
in RFC 8551 [46])
<<.
>>
as well as DKIM(6376) host signatures.
Making use of encrypted transport channels(3207)
reduces the risk of malicious actors breaking such signatures,
or totally avoids it in one hop message transfer.
Upon graceful DNSSEC(4033,4034,4035) and DANE(6698; also 7250)
coverage risk reduction of encrypted channels will be very high,
or at least expose malicious actors more easily.
Using encrypted channels is therefore RECOMMENDET.
and/or a short "SMTP Extensions" table as is present in the
SUBMISSION RFC 6409 section 7, and that despite the differences of
which targets SMTP and SUBMISSION address, would be short enough
to nonetheless fit in such a "purifying RFC rewrite", or, like
i said on October 28th,
Really, like i already said i think here, bare protocol description
back or forth, i personally do not truly understand why RFC 9051
can talk about STARTTLS and "Implicit TLS", but 5321 cannot.
|organization. In addition to processing existing, verified errata and
|errata marked as "held for document update", the WG may address
|newly-offered errata. However, no new protocol extensions or amendments
|will be considered for inclusion into 5321bis and 5322bis documents,
|unless they are already published as IETF Stream RFCs and are at
|sufficient maturity level to move to Internet Standard."
STARTTLS/Implicit TLS, for sure.
|As I said, whether any given review constitutes "corrections and
|clarifications", and not "new protocol extensions or amendments" is a
|determination for the chairs and the AD.
|
|While it's always frustrating to receive unexpected feedback during
|Last-Call, this discussion really shouldn't be about the timing. It's
|about whether the comments are in charter.
|
|pr
|--
|Pete Resnick https://www.episteme.net/
|All connections to the world are tenuous at best
|
|--
|Emailcore mailing list -- emailcore@xxxxxxxx
|To unsubscribe send an email to emailcore-leave@xxxxxxxx
--End of <5FEDA01D-9B91-4922-8A02-61EAB9E9463D@xxxxxxxxxxxx>
--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)
|
|And in Fall, feel "The Dropbear Bard"s ball(s).
|
|The banded bear
|without a care,
|Banged on himself fore'er and e'er
|
|Farewell, dear collar bear
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
