Advice for Safe Handling of Malformed Messages
RFC 7103
Yes
No Objection
Note: This ballot was opened for revision 10 and is now closed.
(Barry Leiba; former steering group member) Yes
(Pete Resnick; former steering group member) Yes
Nothing that would stop me from endorsing this document going forward, but please do take the following into consideration: 1.1 - The 5th paragraph seems redundant with previous paragraphs in this section. The last paragraph seems redundant with section 1.2. Suggest striking. 4 - It seems worth pointing out somewhere in this section that the prepending of Received fields is the safest thing to do if changes must be made to the message to pass information between modules. 7.1 - "A message using an obsolete header syntax" You might consider adding a direct reference to 5322 section 4 to define what's meant by "obsolete". 7.1.6 - Why is the second example not obviously better? I have a hard time imagining circumstances where an unterminated quoted-string that contains an angle-bracketed thing that looks like an addr-spec is in fact a local part. 7.4 - "acceptance grammar" is a weird construction, not used in 5322. Suggest "obsolete syntax" (with the reference to section 4) instead. 7.5 - Third paragraph: Reference to DKIM would be useful. Fourth paragraph: I find the word "enacted" a bit weird. I suggest changing "can be enacted" to "can be used" or "strategies can be used" What's the difference between 3 & 4? Or maybe I don't know what "compound instance" means in 3. 7.5.3 - What's the harm in more than one Return-Path? Only one of interest is the top-most. --- Finally, a gedankenexperiment, or maybe fodder for a real experiment: What would happen if, upon receiving a malformed message that was determined to not be otherwise malicious, a receiving SMTP system both returned a 5xx to the message *and* processed and delivered the message (i.e., give the receiver what they want, but push back on folks who generate crap)? Would it help? (I am not asking for a discussion of this in the document. Just an interesting thought.)
(Stephen Farrell; former steering group member) Yes
Thanks for a useful document. I would have loved to have seen text about S/MIME and PGP issues, but I guess that might require another equally long document all by itself. It might well be worth looking though to see if there's a reference to which you could point that has relevant guidance about those. Separately, it might also be worth pointing out that some of the handling guidance you give if applied to some S/MIME or PGP messages is likely to break signatures or make decryption impossible. But those are just suggestions to take or leave, this is already useful enough as-is.
(Benoît Claise; former steering group member) No Objection
(Brian Haberman; former steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
10 appears to have addressed many of the ops reviewers concerns. Thanks!
(Martin Stiemerling; former steering group member) No Objection
(Richard Barnes; former steering group member) No Objection
(Sean Turner; former steering group member) No Objection
I quickly skimmed this draft and it looks fine to me. I'm balloting no objection, but I'm sure it would have been a YES had I had more time to review it - my fault mind you.
(Spencer Dawkins; former steering group member) No Objection
(Stewart Bryant; former steering group member) No Objection
(Ted Lemon; former steering group member) No Objection