On 2014-03-05 21:37:46 +0000, Paul Smith wrote:
So, if the sender didn't support PRDR, we'd have to accept the
message, deliver it to the second user, and send a bounce message
back (with risk of backscatter) for the first user.
That's not the only fall-back option, as you noted in another message.
In fairness, it kind of is the only option if you reject outright the idea of
silently discarding messages.
I think the "never discard" approach is far out on the raggedy edge, but
that does not make the approach ipso facto invalid.
In any case, spammers would probably not support PRDR, and that'd
probably be the most common case people would use it, and that would
be the most likely case to cause backscatter from accepting then
sending bounce messages.
I'm not especially worried about spammers. For them, falling back to
"temporary reject and accept one recipient at a time" is acceptable[2].
I'm worried about normal users who send a mail to 100 addresses from
their address book. At normal retry rates such messages could take days
to deliver, which would not be acceptable for the recipients[1].
Bingo. This is part of why the approach of rejecting all but one recipient at
RCPT TO time is a nonstarter.
But the number of organizations which would send a single (non-spam)
message to 100 of your users is probably low. Most importantly, it's
your own (for which simultaneously implementing PRDR on the client and
server side should be possible) and then there are maybe a handful of
partner organizations.
Well, all I have to offer is anecdotal evidence, but I work with around
5 local args, and all of them have mailing lists this large or larger.
So you don't need universal deployment of PRDR to make PRDR with a
fallback to "temporary reject and accept one recipient at a time"
acceptable, just isolated pockets plus (maybe) the large ESPs.
You certainly don't need universal deployment of PRDR for it to be useful,
but that doesn't make temporary RCPT TO reject palatable.
Ned
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp