Re: [ietf-smtp] SMTP server reply extensions

Ned Freed <ned.freed@mrochek.com> Fri, 10 April 2020 16:13 UTC

Return-Path: <ned.freed@mrochek.com>
X-Original-To: ietf-smtp@ietfa.amsl.com
Delivered-To: ietf-smtp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 008183A079B for <ietf-smtp@ietfa.amsl.com>; Fri, 10 Apr 2020 09:13:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com
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 Yr0938b7B0zG for <ietf-smtp@ietfa.amsl.com>; Fri, 10 Apr 2020 09:13:43 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A852F3A074B for <ietf-smtp@ietf.org>; Fri, 10 Apr 2020 09:13:40 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RJJC0P4RCG004MCF@mauve.mrochek.com> for ietf-smtp@ietf.org; Fri, 10 Apr 2020 09:08:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1586534916; bh=Sl2+vzt0FWCaZJu6VQvJJa57dustixDYQ6wHDoc9p6E=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=Q8lAvPKqPblU/5FMWDAcdUkK+GvRGmLDzYcO2JR0cyyxVajadyw8PUsz1WZzUt33J tymY+TXDr6wSz2gl/lV9tLGW06TwImfBDHerHC6r4BlLO6twgTO0kE8jzETatB8WYk t3iWvLpFl1R5X3xubhu1mBBTN7k5Oy+MLjS7TQPg=
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: TEXT/PLAIN; CHARSET="us-ascii"
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RJJAX8S780000059@mauve.mrochek.com>; Fri, 10 Apr 2020 09:08:32 -0700 (PDT)
Cc: Timo Sirainen <timo@sirainen.com>, ietf-smtp@ietf.org
Message-id: <01RJJC0LTUOG000059@mauve.mrochek.com>
Date: Fri, 10 Apr 2020 09:07:03 -0700
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Fri, 10 Apr 2020 08:43:51 -0700 (PDT)" <01RJJBJ305QW000058@mauve.mrochek.com>
References: <8CF389F4-7BD3-44D0-85F4-91E66120A59B@sirainen.com> <8f52f073-72f1-3813-bd52-217cb2ff4419@wizmail.org> <578702286F283486C2F8D7B0@PSB> <63ED9C33-EE62-48FD-B176-E698C7D609B9@sirainen.com> <01RJJBJ305QW000058@mauve.mrochek.com>
To: Ned Freed <ned.freed@mrochek.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/ffJ6s8fD5QiunVzCCtH4829nMng>
Subject: Re: [ietf-smtp] SMTP server reply extensions
X-BeenThere: ietf-smtp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of issues related to Simple Mail Transfer Protocol \(SMTP\) \[RFC 821, RFC 2821, RFC 5321\]" <ietf-smtp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-smtp/>
List-Post: <mailto:ietf-smtp@ietf.org>
List-Help: <mailto:ietf-smtp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-smtp>, <mailto:ietf-smtp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Apr 2020 16:13:44 -0000

> I guess I'm missing something pretty fundamental here, because I don't see why
> any of this is necessary.

> We have a model for extending SMTP/LMTP that includes private extensions:
> Advertise the extension in the EHLO/LHO response, then enable the extension
> either with a new command or parameter. There's essentially no limit on what an
> extension can do, and it certainly includes enabling the use of structured
> information in certain replies.

I should also note that the use of an enabling command or parameter here
isn't strictly necessary, especially in the case of LMTP: Since reply text
is normally unstructured, all that's needed is an indicator from the server
that it's going to include structured information in some replies. This
has worked just fine in the case of ENHANCEDSTATUSCODES.

				Ned