On Thu 13/Mar/2014 02:51:17 +0100 Ned Freed wrote:
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'm sorry I garbled that paragraph.
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.
Indeed, RFC 5321 says:
As discussed in Section 7.8 and Section 7.9 below, dropping mail
without notification of the sender is permitted in practice.
I do so for viruses, thanks to the extremely low false-positive rate.
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.
Yes, but you can only do so if the client supports it. That may give
rise to the long-winded road to adoption that was discussed last week:
Servers avoid discarding when that creates more problems than it
solves. Rejecting works better, so it allows more room for anti-spam
solutions. Per-recipient settings individually allow more room too,
but thus far that implies discarding. So it seems one can improve
along one of two orthogonal directions only. Is that the reason why
many spammers send to multiple recipients?
I'm extremely dubious about standardizing use of specific types of
data analytics in the AS/AV space.
We don't need to "standardize" them, so long as it's clear what we're
talking about. The case of a server facing a large number of RCPT TO
commands is also in Section 7.8 of RFC 5321. Since that is the meat
of PRDR, it ought to elaborate on that topic a little bit more, IMHO.
Ale
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp