ietf-smtp
[Top] [All Lists]

Re: [ietf-smtp] Per-Recipient Data Responses

2014-03-12 05:49:24
On Tue 11/Mar/2014 19:31:51 +0100 Ned Freed wrote:
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.

Not invalid sounds a bit weak, considering that the fall-back of
choice is going to be the server workhorse, at least until PRDR is not
widely deployed.  It is the only way that a server can allow
per-recipient configurations that are meaningful independently of the
technical capabilities of the sender.

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.

Right, done that way it makes no sense.  However, it is possible to
split recipients into two groups, say, those who whitelisted the
message based on the envelope, and those who wanted to examine the
content before making a choice.  Normal rates do provide for a few
quick retries in a row.

For the spammers vs. normal users distinction, I read papers that work
out some kind of score by analyzing how recipients are related to one
another and to the sender.  I never saw an actual how-to for
production servers, though.  Perhaps, the normal spam threshold can be
lowered if the recipients are not well clustered.  Then, the first
recipient of the second group will decide whether to accept the
message also on behalf of the others.  The rationale is that overall
email consistency is improved by honoring CC directives.  Could such
reasoning be refined into a fall-back recommendation?

Ale


_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp