IETF Last Call Review of draft-ietf-mailmaint-messageflag-mailboxattribute-09
review-ietf-mailmaint-messageflag-mailboxattribute-09-secdir-lc-salz-2025-10-06-00

Request Review of draft-ietf-mailmaint-messageflag-mailboxattribute
Requested revision No specific revision (document currently at 11)
Type IETF Last Call Review
Team Security Area Directorate (secdir)
Deadline 2025-10-14
Requested 2025-09-30
Authors Neil Jenkins , Daniel Eggert
I-D last updated 2025-10-21 (Latest revision 2025-10-20)
Completed reviews Secdir IETF Last Call review of -09 by Rich Salz (diff)
Genart IETF Last Call review of -10 by Meral Shirazipour (diff)
Artart IETF Last Call review of -10 by Jiankang Yao (diff)
Assignment Reviewer Rich Salz
State Completed
Request IETF Last Call review on draft-ietf-mailmaint-messageflag-mailboxattribute by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/8pFrG6NWWdtCRueapLMHrwGQdhg
Reviewed revision 09 (document currently at 11)
Result Has nits
Completed 2025-10-06
review-ietf-mailmaint-messageflag-mailboxattribute-09-secdir-lc-salz-2025-10-06-00
I am the SECDIR reviewer for this draft.

I have a question, probably because I am not very familiar with the IMAP
protocol. All my questions could be answered by stating "we're documenting
existing practice" and I am fine with that: Why three bits for `MailFlagN`
instead of a single digit?

The description of the keywords was clear and easy to understand, thank you.

Does the ordering of the keywords in Section 4 match some other IMAP documents?
I would find it easier to read all the simple definitions together, and then
the related words (memo, attachment, subscription).

Sec 4.9: "verified with complete confidence". Please strike the word complete. 
In fact, as a security person, I strongly suggest removing almost all
absolutism from this section: "absolute certainty," "strong signal," etc.

Sec 7 should probably mention that use and interpretation of these keywords,
depends on the client/user ability to trust the IMAP server, and/or also refer
to the security considerations in RFC 9051.