Advice for Safe Handling of Malformed Messages
draft-ietf-appsawg-malformed-mail-11

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.)

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.