Milter-greylist

"Marcus Schopen lists-yahoogroups@... [milter-greylist]"
<milter-greylist@yahoogroups.com> writes:

> Am 7.6.2019 03:00, schrieb yahoo@... [milter-greylist]:
>>> Somehow, greylisting seems to be evaluated as "bad recipient" by
>>> confBAD_RCPT_THROTTLE, which seems to be wrong in this case.
>> 
>> confBAD_RCPT_THROTTLE sets the maximum number of connections permitted
>> per second per sendmail daemon. After this many connections are
>> accepted, sendmail delays further connections.
>> 
>> It does not have anything to do with milter-greylist.
>
> I don't think that's right. From sendmail docs: "If set and more than 
> the specified number of recipients in an envelope are rejected, sleep 
> for one second after each rejected RCPT command."
>
> It's about rejected recipients and not about connections permitted per 
> second. This causes sendmail to react incorrectly to the "reject" of its 
> own milter.

Why do you say it is incorrect?  The milter said that recipients would
not be accepted, and thus they are -- for this smtp session -- temporary
failures.  So sendmail will now sleep for a second between each one, and
that doesn't sound so bad.

Part of the problem is that when milter-greylist returns 4xx, you don't
know:

  1) this is a valid mail to a valid recipient, but it hasn't met
  greylisting delay times yet

  2) this is spam, but it wasn't met greylisting delay times yet

Given that, it's hard to to say that the THROTTLE is wrong.  I think you
are only saying that because you know it is case 1.

Overall, I see no reason to think this is a milter-greylist bug.

If you don't like the THROTTLING, you can probably change the sendmail
code to only count 5xx codes for the purpose of rate limiting.  I would
suggest putting that effort into whitelisting know peer MTAs instead, to
reduce the amount of greylisting on legitimate mail.