Skip to main content

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

Request Review of draft-ietf-lamps-e2e-mail-guidance
Requested revision No specific revision (document currently at 16)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2024-02-19
Requested 2024-02-05
Authors Daniel Kahn Gillmor , Bernie Hoeneisen , Alexey Melnikov
I-D last updated 2024-02-17
Completed reviews Dnsdir Last Call review of -14 by Johan Stenstam (diff)
Artart Last Call review of -14 by Bron Gondwana (diff)
Opsdir Last Call review of -14 by Sarah Banks (diff)
Genart Last Call review of -14 by Paul Kyzivat (diff)
Secdir Last Call review of -14 by Charlie Kaufman (diff)
Dnsdir Telechat review of -15 by Scott Rose (diff)
Assignment Reviewer Paul Kyzivat
State Completed
Request Last Call review on draft-ietf-lamps-e2e-mail-guidance by General Area Review Team (Gen-ART) Assigned
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/0KhEz_45KintpKV6yWoeAgFHf_4
Reviewed revision 14 (document currently at 16)
Result Ready w/nits
Completed 2024-02-17
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?