[Top] [All Lists]

Re: [ietf-smtp] SMTP server reply extensions

2020-04-10 13:19:21
On 10. Apr 2020, at 18.43, Ned Freed <ned(_dot_)freed(_at_)mrochek(_dot_)com> 

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 
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 
use, but there are enough values that it's difficult to get excited about

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

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.

ietf-smtp mailing list