I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments. 

Please find some review comments for your consideration, which I hope you find useful and clear.

Ready with Nits (or Minor Issues)

In general, this document seems to adequately cover the Operational areas listed in Appendix A of RFC 5706. Deployment, coexistence, migration, and defaults covered. One area that perhaps deserves more explicit mention of fault and error condition reporting and notification. Attributes such as indications to a user are useful tools in the context of this operational review.

Minor Issues and Nits:

I was fairly confused, which could be just an issue on my end, about the use of  lower and uppercase derivations of the word "recommend". For example, is this in the Intro non-normative? "In brief, this memo now recommends that:".
There is a total of 17 instances of "recommend" and two of "RECOMMEND". 

Idnits complains about:
https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-uta-email-deep-09.txt

   The specific means employed for deprecation of cleartext Mail Access
   Services and Mail Submission Services MAY vary from one MSP to the
   next in light of their user communities' needs and constraints. 

Does this MAY denote a requirement, or a statement of fact?

   Also, users previously authenticating with passwords sent as
   cleartext SHOULD be required to change those passwords when migrating
   to TLS, since the old passwords were likely to have been compromised.

How does the editor quantify the likelihood or otherwise extrapolates on passwords being compromised?

   All DNS records advertised by an MSP as a means of aiding clients in
   communicating with the MSP's servers, SHOULD be signed using DNSSEC.

As struggle a bit with finding this recommendation within scope, as set up in the Abstract of the document.

   o  MUAs SHOULD be configurable to require a minimum level of
      confidentiality for any particular Mail Account, and refuse to
      exchange information via any service associated with that Mail
      Account if the session does not provide that minimum level of
      confidentiality.  (See Section 5.2.)

Can this refusal to exchange information cause a user-experience black-hole? In other words, are there requirements for UI and logging of error conditions here?


   o  MUAs SHOULD provide a prominent visual indication of the level of
      confidentiality associated with an account configuration (for
      example, indications such as "lock" icons or changed background
      colors similar to those used by some browsers), at appropriate
      times and locations in order to inform the user of the
      confidentiality of the communications associated with that
      account.  

Why are "visual" indications only required? And why color-based indication levels are exemplified only? These do not seem friendly to color-blind people, and not useful for visually impaired users, or interfaces that prioritize other channels. I'd generalize this, and exemplify with icons or colors or...

I hope you find these useful. 

Thank you,

-- Carlos Pignataro.