Last Call Review of draft-ietf-lamps-e2e-mail-guidance-14
review-ietf-lamps-e2e-mail-guidance-14-genart-lc-kyzivat-2024-02-17-00

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-lamps-e2e-mail-guidance-14
Reviewer: Paul Kyzivat
Review Date: 2024-02-17
IETF LC End Date: 2024-02-19
IESG Telechat date: ?

Summary:

This draft is basically ready for publication, but has nits that should 
be fixed before publication.

NITS: 5

(I also have included some questions at the end that I don't think 
qualify as issues.)

1) NIT: Section 9.7.2:

In the following:

"If such a proxy handles certificate discovery in inbound messages (see 
Appendix A.2.1), it will also need to communicate the results of that 
discovery process to its corresponding proxy for message composition 
(see Section 9.7.1)."

I think there is a problem here with "... proxy ... communicate ... to 
... proxy". Shouldn't it communicate to the MUA?

2) NIT: Section 2.2

s/Implmenters/Implementers/

3) NIT: Section 8.1.1

s/rFC822Name/RFC822Name/

4) NIT: Section 9.5

s/(e.g. and IMAP mailbox)/(e.g. an IMAP mailbox)/

5) NIT: IdNits:

IdNits reports many things, most of them bogus. A couple of them look to 
me like they deserve consideration:

   -- Obsolete informational reference (is this intentional?): RFC 3501
      (Obsoleted by RFC 9051)

   -- Duplicate reference: draft-ietf-openpgp-crypto-refresh,
      mentioned in 'I-D.ietf-openpgp-crypto-refresh', was also
      mentioned in 'I-D.ietf-openpgp-crypto-refresh-13'.


Other Comments/Questions:

I found this document very informative. I wasn't aware how many issues 
there are with this feature. The work required to make an MUA comply 
with this document seems daunting. Is it expected that this will happen 
for popular MUAs?

Also, do you consider web server based implementations of email clients 
(such as gmail) to be proxies? If so it might be good to say so 
explicitly. If not, then should they be discussed separately?

When composing a reply a user may find that desired parts of a 
replied-to message have not been quoted by the MUA. (Due to the rules in 
5.4.) Such user is likely to curse and then simply copy/paste the 
desired text. Is the MUA expected to detect this behavior and discourage it?