The LIMITS SMTP Service Extension
draft-freed-smtp-limits-07
Yes
Francesca Palombini
Murray Kucherawy
(Andrew Alston)
No Objection
Erik Kline
Jim Guichard
John Scudder
(Martin Duke)
Note: This ballot was opened for revision 07 and is now closed.
Francesca Palombini
Yes
Murray Kucherawy
Yes
Paul Wouters
Yes
Comment
(2023-10-25)
Sent for earlier
I see that SIZE was a "limit" handled previously in RFC1870. However, when reading that limit, I don't see any language as present in this document about new SIZE limits after authentication. Is that something appropriate to add to this document? I don't see another document that updates 1870 for this? Would it make sense to also fold in SIZE into this new limit syntax in the hopes of perhaps obsoleting the SIZE extension as a separate extension a decade from now ?
Erik Kline
No Objection
Jim Guichard
No Objection
John Scudder
No Objection
Roman Danyliw
No Objection
Comment
(2023-10-25)
Sent
** Section 6. Editorial. In the spirit of inclusive language consider s/A man-in-the-middle attack/An on-path attack/ ** Section 6. All that said, decades of operational experience with the SMTP "SIZE" extension [SIZE], which provides servers with the ability to indicate message size, indicates that such abuse is rare and unlikely to be a significant problem. Consider adding that opportunistic encryption/STARTTLS would also help mitigate on-path tampering of these values.
Warren Kumari
No Objection
Comment
(2023-10-25)
Not sent
I would like to echo Rob's thanks to John.
Zaheduzzaman Sarker
No Objection
Comment
(2023-10-26)
Not sent
Thanks for working on this specification, I have no objection from TSV point of views.
Andrew Alston Former IESG member
Yes
Yes
()
Not sent
Martin Duke Former IESG member
No Objection
No Objection
()
Not sent
Robert Wilton Former IESG member
No Objection
No Objection
(2023-10-25)
Sent
John, thank you for shepherding Ned's document through to RFC. I have one very minor nit, which is a typo on 'Regisry' in section 7.1. Regards, Rob