Re: [ietf-smtp] SMTP server reply extensions

[Timo Sirainen <[e-mail]>]

On 10. Apr 2020, at 18.43, Ned Freed <[e-mail]> 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.