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

"Murray S. Kucherawy" <> Thu, 07 November 2013 00:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 238F111E8170; Wed, 6 Nov 2013 16:48:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.54
X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xnuelMJ5JChm; Wed, 6 Nov 2013 16:48:57 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c05::230]) by (Postfix) with ESMTP id 326FC11E816D; Wed, 6 Nov 2013 16:48:57 -0800 (PST)
Received: by with SMTP id ex4so4654026wid.9 for <multiple recipients>; Wed, 06 Nov 2013 16:48:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=LhoXC6rh4G2EAQOENjujQQie8BaMRtRK89lx2CzPRJw=; b=vBAval7/vJg4qXzC6f2BvagkvlIcMgHYVNssX9d0KICruFA7JG2EEqf39BzeN/LkGS 0Yl5Eh8SgGbewPmI2JlUBTTaATQ5WvCstj/aUHrKeLDVrlPa+cWTUCBOzesZH2y6ZO3o F6LCcOxg58noMHn1YMiJdj0shUtC7IBVS7RM52iNV702KR5iC8VOnwDu6vSiAkD6qybu URUun3uH2sSFtvE/XktaxqsJK2I4BQK8zkBPeWBlaWhPnQDxHuyrFc5ho0sPLbb1w5im idcrqlqH/9mfg7a/mRdLuiJR7AryRymBb7FKEROmn33QI+j0Nd0jok3iIAd7X36rnv0+ 6++g==
MIME-Version: 1.0
X-Received: by with SMTP id ld5mr812981wjc.67.1383785336344; Wed, 06 Nov 2013 16:48:56 -0800 (PST)
Received: by with HTTP; Wed, 6 Nov 2013 16:48:55 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Wed, 06 Nov 2013 16:48:55 -0800
Message-ID: <>
Subject: Re: Gen-ART review of draft-ietf-appsawg-malformed-mail-09
From: "Murray S. Kucherawy" <>
To: "Black, David" <>
Content-Type: multipart/alternative; boundary="047d7bb70c586b148c04ea8ba161"
Cc: "" <>, "" <>, "" <>, "General Area Review Team (" <>, "" <>, "Barry Leiba (" <>
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 00:48:59 -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.  :-)

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

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

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.