On 10. Apr 2020, at 18.43, Ned Freed <ned(_dot_)freed(_at_)mrochek(_dot_)com>
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.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp