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 mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp