[apps-discuss] Pete Resnick's Yes on draft-ietf-appsawg-malformed-mail-10: (with COMMENT)

["Pete Resnick" <[e-mail]>]

Pete Resnick has entered the following ballot position for
draft-ietf-appsawg-malformed-mail-10: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-appsawg-malformed-mail/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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