Hi Jim,
Below I removed comments where we are in agreement (or which we already
discussing separately). I will reply to a few remaining comments separately.
On 10/01/2019 19:48, Jim Fenton wrote:
Thanks for your review, Alexey. Responses and a few clarifying questions
below.
On 1/9/19 8:34 AM, Alexey Melnikov wrote:
Hi,
Sorry for the delay in reviewing this. I reviewed it in 2018, but
needed to work on expanding/decoding my notes so that they become
useful for other readers.
The document needs to specify line length increase and whether the
extension is allowed for SMTP Submission and LMTP (I think the answer
is Yes to both).
Specify line length increase: I'm not sure what you mean here;
presumably something having to do with the additional length from the
presence of the REQUIRETLS MAIL FROM parameter?
Yes. This is a generic requirement for specifying SMTP extensions which
extend MAIL FROM or RCPT TO. If neither is extended, saying so would
also be beneficial.
Submission: will add. LMTP: I have never run into it, and it is
informational. Does anyone actually use it?
Yes, it is used. Both by open source (etc least Cyrus, Dovecot, EXIM,
Postfix) and commercial (Oracle, Isode) software.
[snip]
6. The SMTP client SHOULD also require that meaningfully secure
cipher algorithms and key lengths be negotiated with the server.
The choices of key lengths and algorithms change over time, so a
specific requirement is not presented here.
This SHOULD is not implementable as written. The document needs to
provide more details on where this information can be found. (Imagine
that I implement a new MTA that supports this.)
As may be clear from the specification, I struggled with this a bit. I
didn't want to put in a specific requirement because I don't like the
idea of lots of specifications calling out specifics and then having to
be revised as things change. I'd rather point to a BCP, if there is an
appropriate one, that specifies this and changes from time to time. Is
there such a BCP? Or I could perhaps just leave this out, because it's
somewhat obvious and clients shouldn't be accepting insecure lengths and
algorithms anyway.
We have an RFC for this that came from this WG: RFC 7525. It is a BCP.
If problems are found with this document, it will be updated.
So if you say "RFC 7525 or its successor", that would be fine with me.
Best Regards,
Alexey
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
