[secdir] sec-dir review of draft-ietf-eai-rfc5336bis-14.txt
Derek Atkins <derek@ihtfp.com> Thu, 20 October 2011 13:58 UTC
Return-Path: <derek@ihtfp.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF5721F8BAB; Thu, 20 Oct 2011 06:58:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.988
X-Spam-Level:
X-Spam-Status: No, score=-101.988 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdWyOOCOIuGh; Thu, 20 Oct 2011 06:58:36 -0700 (PDT)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by ietfa.amsl.com (Postfix) with ESMTP id 356B121F8B9C; Thu, 20 Oct 2011 06:58:36 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 815552602A6; Thu, 20 Oct 2011 09:58:35 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 28573-10; Thu, 20 Oct 2011 09:58:34 -0400 (EDT)
Received: from mocana.ihtfp.org (IHTFP-DHCP-158.IHTFP.ORG [192.168.248.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (not verified)) by mail2.ihtfp.org (Postfix) with ESMTPS id 4D82D26002E; Thu, 20 Oct 2011 09:58:34 -0400 (EDT)
Received: (from warlord@localhost) by mocana.ihtfp.org (8.14.5/8.14.5/Submit) id p9KDwS0x031504; Thu, 20 Oct 2011 09:58:28 -0400
From: Derek Atkins <derek@ihtfp.com>
To: iesg@ietf.org, secdir@ietf.org
References: <sjmfwinyesz.fsf@mocana.ihtfp.org>
Date: Thu, 20 Oct 2011 09:58:27 -0400
In-Reply-To: <sjmfwinyesz.fsf@mocana.ihtfp.org> (Derek Atkins's message of "Thu, 20 Oct 2011 09:26:36 -0400")
Message-ID: <sjmty73wyrg.fsf@mocana.ihtfp.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Virus-Scanned: Maia Mailguard 1.0.2a
Cc: yaojk@cnnic.cn, eai-chairs@tools.ietf.org, maowei_ietf@cnnic.cn
Subject: [secdir] sec-dir review of draft-ietf-eai-rfc5336bis-14.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Oct 2011 13:58:37 -0000
Sorry, that previous email was a review of draft-ietf-eai-rfc5336bis-14.txt. I appologize for any confusion. -derek Derek Atkins <derek@ihtfp.com> writes: > Hi, > > 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 document specifies an SMTP extension for transport and delivery > of email messages with internationalized email addresses or header > information. > > The security considerations sections lists a number of issues to > consider with this document, and presents the issues well. It does > not go into particular depth about what could happen if those issues > are not addressed. > > For example, 3.7.2 mentions "surprising rejections" but doesn't go > into any depth beyond that nor does it explain what other failures can > happen. > > Operationally it might be hard to make sure that all or none of the MX > servers support UTF8SMTPbis, especially if the MX servers might MX for > multiple domains, or be under different operational control. What are > the situations where mixed-MX support will work or fail? Should MX > servers need the ability to turn on or off support for this protocol > on a per-domain basis to protect against these types of failures? > > Thanks, > > -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant
- [secdir] sec-dir review of draft-ietf-roll-of0-15… Derek Atkins
- [secdir] sec-dir review of draft-ietf-roll-of0-15… Derek Atkins
- [secdir] sec-dir review of draft-ietf-eai-rfc5336… Derek Atkins