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.
But that's the entire point of what I'm saying here - by intentionally
making the behavior inconsistent, you end up in a better place.
I also disagree that this is terribly hard to implement. Anyone who
has done LMTP or Sieve ereject - and lots of people have - has the necessary
code mostly in place. It would be better if this were identical
to LMTP in terms of response codes though.
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?
Not even close. An obvious problem is that this tickles spam filters
differently. A less obvious problem is unnecessary duplicates. Once split, it's
very difficult to recombine messages that travel different paths. So splitting
leads to duplicates. And while these may not bother you, it bothers other
people a *lot*, to the point wher it becomes a support call generator.
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.
That might be true were it not for LMTP. But a client with LMTP support can
accomodate PRDR pretty easily.
Ned
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp