Re: [apps-discuss] Call for adoption of draft-kucherawy-mta-malformed-00.txt as an APPSAWG document

Randall Gellens <> Wed, 06 July 2011 04:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 30ED321F87F8 for <>; Tue, 5 Jul 2011 21:29:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8V+BNMw96bru for <>; Tue, 5 Jul 2011 21:29:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 91FB321F8747 for <>; Tue, 5 Jul 2011 21:29:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=qcdkim; t=1309926589; x=1341462589; h=message-id:in-reply-to:references:x-mailer:date:to:from: subject:cc:mime-version:content-type:x-random-sig-tag: x-originating-ip; z=Message-ID:=20<> |In-Reply-To:=20<>|References: =20<>=20<4E0D3FA5.8060504@gmail .com>=0D=0A=20<>|X-Mailer:=20Eu dora=20for=20Mac=20OS=20X|Date:=20Tue,=205=20Jul=202011 =2021:25:04=20-0700|To:=20Alexey=20Melnikov=20<alexey.mel>,=20Mykyta=20Yevstifeyev=0D=0A=09<evnikit>,=20Murray=20S=20Kucherawy=20<msk@cloudmark. com>|From:=20Randall=20Gellens=20<> |Subject:=20Re:=20[apps-discuss]=20Call=20for=20adoption =20of=20=0D=0A=20draft-kucherawy-mta-malformed-00.txt=20a s=20an=20APPSAWG=20document|CC:=20<> |MIME-Version:=201.0|Content-Type:=20text/plain=3B=20char set=3D"us-ascii"=3B=20format=3Dflowed|X-Random-Sig-Tag: =201.0b28|X-Originating-IP:=20[]; bh=LRqVbFvZQZyM+dKIxB2msKp28V/ipyZWdrOJJvxM6nA=; b=TKfJG+Jr+HIC8kN4rGYrYsnINBGO9mAb+emys7iNMg6xg6/FqVrJCEn6 AtlYtQV95+uKludhU6ek2BH5VDBlk1ZkggG3p6XutYSRepLEUhNT/byyW sQt+hvin7KIS0QfAwElsuAIQ0dwsqvBO6oHeWaa+yUoLJmFQsi2l+qRYE c=;
X-IronPort-AV: E=McAfee;i="5400,1158,6398"; a="101825747"
Received: from ([]) by with ESMTP; 05 Jul 2011 21:29:48 -0700
X-IronPort-AV: E=Sophos;i="4.65,482,1304319600"; d="scan'208";a="154994091"
Received: from ([]) by with ESMTP/TLS/AES128-SHA; 05 Jul 2011 21:29:45 -0700
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.1.323.0; Tue, 5 Jul 2011 21:29:44 -0700
Message-ID: <>
In-Reply-To: <>
References: <> <> <>
X-Mailer: Eudora for Mac OS X
Date: Tue, 5 Jul 2011 21:25:04 -0700
To: Alexey Melnikov <>, Mykyta Yevstifeyev <>, Murray S Kucherawy <>
From: Randall Gellens <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Random-Sig-Tag: 1.0b28
X-Originating-IP: []
Subject: Re: [apps-discuss] Call for adoption of draft-kucherawy-mta-malformed-00.txt as an APPSAWG document
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: General discussion of application-layer protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 06 Jul 2011 04:29:50 -0000

This is a nice, short, clearly written draft.

In Section 1.1., the draft says:

    The history of email standards, going back to [RFC822] and beyond,
    contains a fairly rigid evolution of specifications.  But
    implementations within that culture have also long had an
    undercurrent known formally as the robustness principle, but also
    known informally as Postel's Law: "Be conservative in what you do, be
    liberal in what you accept from others."

    In general, this served the email ecosystem well by allowing a few
    errors in implementations without obstructing participation in the
    game.  The proverbial bar was set low.  However, as we have evolved
    into the current era, some of these lenient stances have begun to
    expose opportunities that can be exploited by malefactors.  Various
    email-based applications rely on strong application of these
    standards for simple security checks, while the very basic building
    blocks of that infrastructure, intending to be robust, fail utterly
    to assert those standards.

The robustness principle has had some controversy over the years.  If 
I recall correctly, there was a draft some years back called "Be 
Liberal Considered Harmful" because deployed servers that accepted 
non-compliant messages were responsible for widespread deployment of 
broken clients.  This resulted in "standards creep" where new servers 
were forced to accept common but erroneous messages and protocol, and 
made it harder to develop extensions.

It might be worthwhile to mention some of this immediately following 
the quoted text.  Also, it might be worthwhile to suggest that it's 
good for MSAs fix or reject stuff that is broken (obviously this 
draft can't mandate this).

Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
(If you can't hear me, it's because I'm in parentheses)