RE: Gen-ART review of draft-ietf-appsawg-malformed-mail-09

"Black, David" <> Thu, 07 November 2013 01:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 51A2121E8198; Wed, 6 Nov 2013 17:01:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.229
X-Spam-Status: No, score=-102.229 tagged_above=-999 required=5 tests=[AWL=0.369, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ztA9+bJr5FOf; Wed, 6 Nov 2013 17:01:41 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B62BA21E80EC; Wed, 6 Nov 2013 17:01:38 -0800 (PST)
Received: from ( []) by (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rA711T70006223 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Nov 2013 20:01:30 -0500
X-DKIM: OpenDKIM Filter v2.4.3 rA711T70006223
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed;; s=jan2013; t=1383786090; bh=WHL2MzeR9v4Tv18YRS5rBy/J180=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=uX8xAJGiaJmjZX524Ox7r4PTO/u9BGkkf2lbwIaB9vUy1s3wrcoXmibrvTd3VCbtV g8NbMhDpgysLDbFVxNNvzf8CA2BSA00pTv5tirepPU9FG2SIcBUKjgRKBYUwMFLbuI 1OlG/eLSXQZ+uLTlqBE0FuFcGqYDc9giF0AHk+Yo=
X-DKIM: OpenDKIM Filter v2.4.3 rA711T70006223
Received: from ( []) by (RSA Interceptor); Wed, 6 Nov 2013 20:01:18 -0500
Received: from ( []) by (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id rA711H4i009904 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Nov 2013 20:01:18 -0500
Received: from ([]) by ([]) with mapi; Wed, 6 Nov 2013 20:01:17 -0500
From: "Black, David" <>
To: "Murray S. Kucherawy" <>
Date: Wed, 06 Nov 2013 20:01:16 -0500
Subject: RE: Gen-ART review of draft-ietf-appsawg-malformed-mail-09
Thread-Topic: Gen-ART review of draft-ietf-appsawg-malformed-mail-09
Thread-Index: Ac7bUydFVQjFko0GRkSYwd3I4YhRegAACcGQ
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_8D3D17ACE214DC429325B2B98F3AE712026AAEC093MX15Acorpemcc_"
MIME-Version: 1.0
X-RSA-Classifications: public
Cc: "" <>, "" <>, "" <>, "General Area Review Team (" <>, "" <>, "Barry Leiba (" <>, "Black, David" <>
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 07 Nov 2013 01:01:46 -0000

> I think I'm going to request creation of my own private Directorate.  David seems to get all my Gen-ART reviews,
> and we could possibly do some optimizing here.  :-)

Luck of the draw :).

All of your suggestions are fine, and in Section 7.1.*, picking a single word for "usually", "reasonably" and "should" will definitely suffice - I might suggest scanning the rest of section 7 for consistent use of terminology to express levels of recommendations.


From: Murray S. Kucherawy []
Sent: Wednesday, November 06, 2013 7:49 PM
To: Black, David
Cc:;; General Area Review Team (; Barry Leiba (;;
Subject: Re: Gen-ART review of draft-ietf-appsawg-malformed-mail-09

I think I'm going to request creation of my own private Directorate.  David seems to get all my Gen-ART reviews, and we could possibly do some optimizing here.  :-)

On Fri, Nov 1, 2013 at 6:32 PM, Black, David <<>> wrote:

Nits/editorial comments:

The word "naked" is used a few times to refer to something that occurs in
isolation, without enclosure in another construct, e.g., a naked CR.  This
idiomatic use of "naked" should be explained before it is used.

Fixed; just used "isolated" again.

In Section 1.1, I have always heard Postel's law as:
        - Be conservative in what you send, and
        - Be liberal in what you accept.
The change from "do" in this draft to "send" (above) seems useful, as
it should help focus the discussion in the second paragraph of Section
1.1 - Postel's law, as I have understood it, has never blessed anything
remotely resembling there being "no limits to the liberties that a
sender might take."

There are a bunch of versions.  See:
Some of them say "do", some say "send".  Perhaps the most authoritative one is here, in Section 1.1.2:
It says "send".  I'll make that a reference and adjust.
I concur that the Law doesn't bless the extremes, but I believe the email community has (deliberately or through ignorance) gone there, which is largely the point of this work.

Section 5's section title "Mail Submission Agents" doesn't seem to be
connected to its MHS and MTA content.  It would be useful to add a
sentence to remind readers, including this one ;-), of what Mail
Submission Agents are.

The final sentence of that paragraph specifies what it does, but I see your point about the disconnect in terminology.  Will adjust to tie it all together.

Sections 7.1.* offers degrees of advice qualified by "safely", "usually",
"reasonably" and "should".  There appear to be only two concepts:
        - "safely": Do this all the time.
        - "usually", "reasonably", "should": This is the recommended course
                of action, but there may be exceptions.
While RFC 2119 is not intended for Informational documents, this is an
example of the sort of sloppiness that RFC 2119 is intended to clean up.
At the very least, the use of three words for essentially the same concept
is poor form, and RFC 2119 can be used in an Informational document when
appropriate caveats are provided in the terminology section that references

Earlier versions of this draft looked roughly like an applicability statement, and thus had RFC2119 language throughout.   We decided that, as you point out, it's mostly advice, and not a way of establishing a capability within Internet Mail, which would be more like what an applicability statement is for.
I'm thus inclined not to backtrack, but merely satisfy your "At the very least" clause.

In Section 7.1.4, "Likewise" is not a good way to associate the second
example with the first, because it handles the missing parenthesis in a
rather different fashion (adds quotes instead of inserting the missing
parenthesis character).


In Section 7.7, the first use of "8bit" occurs in "8bit material" but some of
the subsequent occurrences omit the word "material" - that word should be
used with all occurrences.


idnits 2.13.00 generated a couple of warnings about obsolete references:

  -- Obsolete informational reference (is this intentional?): RFC 1113 (ref.
     'PEM') (Obsoleted by RFC 1421)

  -- Obsolete informational reference (is this intentional?): RFC  733
     (Obsoleted by RFC 822)

In both cases, the reference appears to be intentional, and the warning
should be ignored.

Correct; I'll make sure the AD sees this.