In message <01RY347LHNBA0085YQ(_at_)mauve(_dot_)mrochek(_dot_)com>, Ned Freed
<ned(_dot_)freed(_at_)mrochek(_dot_)com> writes
as I observed before -- don't expect much more than a generic statement
(which comes down to "sending N good emails is the most you can expect
to be able to manage") from such systems. Anything which revealed the
current view ("actually, you've pretty much exhausted our patience")
just is not going to happen (IMO)
I don't really understand the concern here,
Some bad senders start by sending good email and then, once their
reputation is established, send bad email. It is generally thought to be
unwise to give any clues whatsoever as to how well this process might be
going... (to what extent the machine learning system has been fooled)
and more importantly, how to address
it.
It is inherent that you cannot -- so mailbox providers who operate in
the space where this is a significant issue are not going to provide any
fine-grained data whatsoever -- just generic values.
That's not what I meant by "address". It's important that standards
discuss all known security issues; and this definitely qualifies.
As such, I'm going to add this text to the Security Considerations:
Use of the Limits extension to provide client-specific information - as
opposed to general server limits - unavoidably provides senders with
feedback about their reputation. Malicious senders can exploit this
in various ways, e.g., start by sending good email and then, once their
reputation is established, sending bad email.
I take Laura's point that good senders can deduce the upper limits --
and hence providing data about those upper limits at the start of the
session has a small amount of value (if only in ensuring that sessions
close smoothly and fewer exception logging event are generated)
Speaking as someone who works on software used for bulk sending, the the value
isn't small, especially when you take the ability to shape subsequent traffic
into account.
Ned
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp