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).
In Section 4.2.1:
RFC 6125 use needs more details, in particular on whether CN-IDs are
allowed, use of wildcards in certificates. I will followup on this
separately.
> 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.)
5.7.x error code needs to be marked for IANA to assign. Please add an
IANA Consideration for it.
In Section 4.2.2:
This section is not clear about when to insert RequireTLS: NO header
field in the message!
At this point in the document it is not even very clear that the
REQUIRETLS MAIL FROM parameter can have multiple values! In fact, the
document has no examples and no ABNF, so I don't even know what the
syntax is!
In Section 5:
> The SMTP client for a REQUIRETLS
> bounce message MUST use an empty MAIL FROM return-path as required by
> [RFC5321].
Don't use RFC 2119 language, as this is already required by RFC 5321. I
suggest you just use non normative language here.
> When the MAIL FROM return-path is empty, the REQUIRETLS
> parameter SHOULD NOT cause a bounce message to be discarded even if
> the next-hop relay does not advertise REQUIRETLS.
Shouldn't this be mentioned in one of 4.X sections?
In Section 8:
> The purpose of REQUIRETLS is to improve communications security for
> email by giving the originator of a message an expectation that it
> will be transmitted in an encrypted form "over the wire". When used,
> REQUIRETLS changes the traditional behavior of email transmission,
> which favors delivery over the ability to send email messages using
> transport-layer security, to one in which requested security takes
> precedence over delivery and domain-level policy.
Is this still true when "RequireTLS: NO" is used?
It looks like RFC 7672 reference should be Normative.
Best Regards,
Alexey
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
