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.
Of course.
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.
You're missing the point. I'm not talking about servers that avoid discard. As
I've said several times now, most servers I'm aware of have a never-reject
policy. Never-discard (or sometimes-discard) policies are the rare exception.
PRDR support lets a server reject messages it would otherwise discard,
providing more information to senders about false positives than they would
otherwise get. That alone makes it advantagous for servers to implement,
because now they can say that it's up to the client to do something if they
want more information.
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.
The current draft is nowhere near ready for standardization. This is
but one of many details that need to be looked at.
The concern now isn't whether the draft is up to snuff, but rather whether this
idea is worth pursuing. I originally thought it wasn't, but it coupled with a
new handling for suspected spam changes things for me.
Ned
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp