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.
I'm not sure what this is supposed to mean. I was talking about having an
overarching policy of never discarding a message. Aside from a few small
setups, I don't think I've ever seen anyone implement such a policy in the past
decade or so. Like it or not, a lot of mail believed to be spam is silently
dropped more often than not, and mail believed to to be dangerous in someway is
almost always discarded.
As such, I'm not especially worried about how PDRD interacts with a
never-discard policy. I'm much more interested in how it lets us replace
discard with reject.
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.
Sorry, that's not something you can count on. Our implementation retries
partial failures quickly by default but that's not true in general.
And I don't think non-overrideable envelope whitelisting is all that common. In
fact I'm not even sure a lot of implementations support those semantics in any
useful way.
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?
I'm extremely dubious about standardizing use of specific types of data
analytics in the AS/AV space.
Ned
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp