Re: [secdir] secdir review of draft-ietf-eai-mailinglistbis-05

John C Klensin <> Thu, 30 August 2012 18:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 66DE421F85A8; Thu, 30 Aug 2012 11:38:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.588
X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SNYFyRvPowQL; Thu, 30 Aug 2012 11:38:37 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8B0DA21F858E; Thu, 30 Aug 2012 11:38:37 -0700 (PDT)
Received: from [] ( by with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <>) id 1T79dU-000NaI-9L; Thu, 30 Aug 2012 14:38:36 -0400
Date: Thu, 30 Aug 2012 14:38:31 -0400
From: John C Klensin <>
To: Charlie Kaufman <>
Message-ID: <>
In-Reply-To: <>
References: <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Cc:, Joseph Yee <>,,
Subject: Re: [secdir] secdir review of draft-ietf-eai-mailinglistbis-05
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 30 Aug 2012 18:38:38 -0000


As WG Co-chair, let me respond to this on behalf of the WG (and
just to be sure we don't have open loops).  

Your careful review is much appreciated, as is the "no changes
recommended" conclusion.  It is always good to have additional
assurances that nothing important was overlooked.

The issue of a multiple-recipient message that requires SMTPUTF8
capability being undeliverable to some recipients, and hence
misleading to those who do receive it about who else got it, is
endemic in any approach that attempts to permit non-ASCII
local-parts of addresses while preserving rough compatibility
with the existing email infrastructure.  That is the case
whether the list of recipients is determined by the message
originator (e.g., in "To:" or "Cc:" fields) or as part of
distribution list processing.   Of course, such recipient lists
are _never_ guaranteed to be accurate: addresses may become
obsolete or undeliverable for all sorts of reasons and none of
them are reported back to other recipients (or, in the case of
mailing lists that follow the specs, to the message originator).
In that sense, the "None beyond what mailing list agents do now"
statement in this draft is precisely and narrowly correct.

For the specific case of these extensions, many of the issues --
but not the specific one of misleading recipient lists-- are
discussed at length in RFC 6530.  In retrospect, the particular
issue with recipient lists should probably have been called out
in either the Security Considerations section or, more likely,
Section 11 of that document, but it is a little bit late for
that now.  That said, if you (or others) think the Security
Consideration section of this document would be improved by an
explicit pointer to the discussion in RFC 6530, I can't imagine
the WG finding that objectionable.

Thanks again for the review.


--On Wednesday, August 22, 2012 20:45 +0000 Charlie Kaufman
<> wrote:

> I have reviewed this document as part of the security
> directorate's ongoing effort to review all IETF documents
> being processed by the IESG.  These comments were written
> primarily for the benefit of the security area directors.
> Document editors and WG chairs should treat these comments
> just like any other last call comments.
> This Informational document describes "considerations" for the
> design and operations of mailing list expanders not collocated
> with the sender when non-ASCII email addresses are involved.
> It is truly informational in that it does not prescribe how to
> deal with the various problems that one might encounter. It
> simply enumerates the problems, describes the alternatives,
> and the range of behaviors observed in existing
> implementations. It suggests a number of areas where future
> standardization would be helpful.
> The document lists no security considerations. An issue
> discussed in the document that could be considered a security
> issue is that mail recipients that cannot accept non-ASCII
> email addresses might or might not receive messages sent to
> the list (depending on approaches the forwarder takes), and
> generally the original sender is not notified. I don't
> recommend any changes.
>                 --Charlie