On Mar 6, 2014, at 12:27 PM, Ned Freed <ned(_dot_)freed(_at_)mrochek(_dot_)com>
wrote:
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.
Sure, lets say there is.
Given the existence of
that option, server side implementation of PRDR becomes a win,
Perhaps. But the complexity of doing it is significant, especially
if you want similar user visible behaviour whether or not the client
is playing along or not.
and given that
so does client side implementation.
The client side can get all the advantages today, without server side support
and without any new code needed, just by sending one body per recipient,
I think?
If so, there’s very little benefit to a client in adding the complexity of
supporting
PRDR at all. If it’s functionality they want, they can already get it in all
cases,
whether or not the server side supports it.
Other than perhaps non-store-and-forward filtering proxies, I can’t think of a
situation where PRDR would be obviously a sensible thing for a *client* to
deploy.
Cheers,
Steve
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp