Re: [Emailcore] Proposed ESMTP keyword RCPTLIMIT

> In message <[email protected]>, Ned Freed
> <[email protected]> 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