Re: [ietf-smtp] SMTP server reply extensions

Timo Sirainen <> Fri, 10 April 2020 18:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1DC9E3A0C63 for <>; Fri, 10 Apr 2020 11:18:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NiOY4Hg7OXW9 for <>; Fri, 10 Apr 2020 11:18:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7B7553A0C2D for <>; Fri, 10 Apr 2020 11:18:48 -0700 (PDT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 5B5582B3C8B; Fri, 10 Apr 2020 18:18:47 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.\))
From: Timo Sirainen <>
In-Reply-To: <>
Date: Fri, 10 Apr 2020 21:18:46 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <578702286F283486C2F8D7B0@PSB> <> <>
To: Ned Freed <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [ietf-smtp] SMTP server reply extensions
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\]" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 10 Apr 2020 18:18:57 -0000

On 10. Apr 2020, at 18.43, Ned Freed <> wrote:
> 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.

Sure, I was just hoping to find a way to avoid designing a horribly non-SMTP like extension, even if it was a private one.

> 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.)

So you are recommending not using the 551 code for the redirection purpose?

Hmm. Now thinking further about this, I'm not sure 551 would be enough for my purposes either. I think I'm going to need multiple different things returned in the reply. So maybe I'll do it with a new private response code also. Any recommendations what private codes to use? Maybe x.y.100 and over?

> 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.

Until now Dovecot's proxies have been responsible for knowing which backend is correct and backends haven't done any extra verifications. But I'm now doing some redesigning of how clustering works and this extra information in replies can be useful in some situations.