Re: [ietf-smtp] SMTP server reply extensions

Ned Freed <ned.freed@mrochek.com> Fri, 10 April 2020 15:58 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 855743A0440 for <ietf-smtp@ietfa.amsl.com>; Fri, 10 Apr 2020 08:58:56 -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 lY4r9z_2ZiWI for <ietf-smtp@ietfa.amsl.com>; Fri, 10 Apr 2020 08:58:55 -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 3A15B3A0433 for <ietf-smtp@ietf.org>; Fri, 10 Apr 2020 08:58:55 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RJJBJ54I1C005T25@mauve.mrochek.com> for ietf-smtp@ietf.org; Fri, 10 Apr 2020 08:55:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1586534113; bh=wNkZpHIE/Xud8AvZt/7e3xV0a2lLXhftsO5k9a6udak=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=UJjp1XNnYk6ghnHz9NiFB0e6fBL8JsV5pvgAYEdSAEdSUDoyKN2mU8YyI55Xc/hJ9 mS7n97cu05KlPbrE79mwel6GdATsFLndoENYWnlsOVv4Osq2Ymfh2iQV/JrhiVqmsC ENpxEqMc/ipuDrVP9jRwxMIMjiOgV4Bvmg2Tp9tc=
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 <01RIHLDFQH34000058@mauve.mrochek.com>; Fri, 10 Apr 2020 08:55:10 -0700 (PDT)
Cc: ietf-smtp@ietf.org
Message-id: <01RJJBJ305QW000058@mauve.mrochek.com>
Date: Fri, 10 Apr 2020 08:43:51 -0700 (PDT)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Fri, 10 Apr 2020 15:45:45 +0300" <63ED9C33-EE62-48FD-B176-E698C7D609B9@sirainen.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>
To: Timo Sirainen <timo@sirainen.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-smtp/9X-_eFiuAqmB9D6EaEqi_-85n9I>
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 15:58:57 -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.

Of course it makes sense to reuse existing structured syntax when possible. As
for reusing existing enhanced status code, I'm really not on board with that -
I think new values are the right way to do it, and that once again we've been
guilty of integer-hoarding. (We really should have reserved a range for private
use, but there are enough values that it's difficult to get excited about
this.)

FWIW, we have the same redirect/referral issue in our software when a user has
been moved, but the LMTP server only knows it's the wrong place for a given
recipient. So what we do is signal that fact using a special private reply
code.

As for data deduplication, we do that with store hashes independent of
ownership, so no need for anything at this level.

				Ned