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 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.
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.
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
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.
 This is why I spent some effort on dynamically creating groups
of recipients to minimize the number of retries when I implemented
per-recipient content filters for qpsmtpd.
 Well, maybe not for them, but for me, dealing with spammers.
_ | Peter J. Holzer | Der eigene Verstand bleibt gefühlt messer-
|_|_) | | scharf. Aber die restliche Welt blickt's
| | | hjp(_at_)hjp(_dot_)at | immer weniger.
__/ | http://www.hjp.at/ | -- Matthias Kohrs in desd
Description: Digital signature
ietf-smtp mailing list