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
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
- [ietf-smtp] SMTP server reply extensions Timo Sirainen
- Re: [ietf-smtp] SMTP server reply extensions Jeremy Harris
- Re: [ietf-smtp] SMTP server reply extensions John C Klensin
- Re: [ietf-smtp] SMTP server reply extensions Tony Finch
- Re: [ietf-smtp] SMTP server reply extensions Valdis Kl ē tnieks
- Re: [ietf-smtp] SMTP server reply extensions Timo Sirainen
- Re: [ietf-smtp] SMTP server reply extensions Timo Sirainen
- Re: [ietf-smtp] SMTP server reply extensions Ned Freed
- Re: [ietf-smtp] SMTP server reply extensions Ned Freed
- Re: [ietf-smtp] SMTP server reply extensions Timo Sirainen
- Re: [ietf-smtp] SMTP server reply extensions Ned Freed