Re: [arch-d] deprecating Postel's principle- considered harmful

S Moonesamy <sm+ietf@elandsys.com> Thu, 09 May 2019 08:18 UTC

Return-Path: <sm@elandsys.com>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7AC120108; Thu, 9 May 2019 01:18:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=opendkim.org header.b=30K4qXLP; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com header.b=Cr1c/RkB
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hIfdkRgxoy_e; Thu, 9 May 2019 01:18:43 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E58E1200F9; Thu, 9 May 2019 01:18:42 -0700 (PDT)
Received: from DESKTOP-K6V9C2L.elandsys.com ([197.224.145.167]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id x498IK3C003736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 May 2019 01:18:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1557389916; x=1557476316; bh=W9Ss90W8eWAVJlNtox5HDey/XiaumsDGpxq+C87VUyw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=30K4qXLPu+FYGMqUBstRE99Bd4Upnlvtx9rqKjnDP23xYFw8Eg8TNp+MVDEkhto6a Py4fu3uErnPFruBwEJFfE9hyiH/rZ/oXtufd4QhBcbvyeiK6nagh12+uU1yQH4hPhI le8P+PnxTB/XD6EKisdMH+sWnuLXtRVg1upAMhC4=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1557389916; x=1557476316; i=@elandsys.com; bh=W9Ss90W8eWAVJlNtox5HDey/XiaumsDGpxq+C87VUyw=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Cr1c/RkBDUUl4HDJE9F327OfL909QLfNtORAmBccB+vGwZJxErVzTRDzoDqNrYIZf Jfn0RzsUeqlq167cCtpD1aD5Jysqeir/tAX1SN6BK8PN/X4mYvEXGjSsh9FtsSw1Zz xEoZOaUj+XcQpbmdgwJxkaFrlnLXb1jJC46+subU=
Message-Id: <6.2.5.6.2.20190509002546.1016db88@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Thu, 09 May 2019 01:14:49 -0700
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, architecture-discuss@ietf.org
From: S Moonesamy <sm+ietf@elandsys.com>
Cc: Barry Leiba <barryleiba@computer.org>, ietf@ietf.org
In-Reply-To: <53a9c16c-163c-a18a-371a-f8aa8697af15@cs.tcd.ie>
References: <F64C10EAA68C8044B33656FA214632C89F024CD3@MISOUT7MSGUSRDE.ITServices.sbc.com> <CALaySJJDHg5j9Z7+noS=YXoNROqdsbJ6coEECtLtbJ6fWJ3xsQ@mail.gmail.com> <53a9c16c-163c-a18a-371a-f8aa8697af15@cs.tcd.ie>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/Xc1zpPnznx8LPJ0YVXxHuYSLaZQ>
Subject: Re: [arch-d] deprecating Postel's principle- considered harmful
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 May 2019 08:18:45 -0000

Hi Stephen,

[Cc trimmed]

At 01:38 PM 07-05-2019, Stephen Farrell wrote:
>Question for ya on that Barry - do you think that MUA
>and mail server implementers would actually bounce
>messages as strictly as Martin's document might call
>for? I'm not one of those implementers, so I don't know,
>but I'd not be surprised to hear that in fact they'd
>continue to prioritise mail delivery (for non spam)
>over protocol purity.

My guess is that the implementer would continue to prioritise mail 
delivery by default.  There is some guidance in RFC 1123 (Section 
1.2.2) about the general rule.  I'd say that the rule is about 
handling error conditions gracefully while not replicating the error 
throughout the network.

Regards,
S. Moonesamy