Yes, this is what I was really trying to say. The functionality of PRDR
depends so critically on everyone else having it that it's basically
impossible
to justify implementation without everybody else on board. Think of it as the
IPv6 of SMTP extensions, if you like. :)
Except that isn't true. As I pointed out previously, there's substantial
benefit and limited downside to implementing a user filter option with "reject
at SMTP time if possible, otherwise discard" semantics. Given the existence of
that option, server side implementation of PRDR becomes a win, and given that
so does client side implementation.
I think it's a shame that LMTP left SMTP behind in this regard. It never
seemed to bother people then. Ironically LMTP is now more "In vogue" than
ever
(many LDA now support it natively, or can be patched to do it) so an obvious
implementation choice for PRDR would simply be in translating LMTP into PRDR.
That's actually a significant problem with the current PRDR proposal - its
semantics are different from those of LMTP, and worse, substantially more
complex. Had this been a simple tweak to reuse LMTP support I would have
implemented it years ago. But it isn't.
Ned
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp