Milter-greylist

Hello,

i found by chance a strange phenomenon in my logfile: after three "rcpt 
to" to existing(!) addresses, which are marked with

"milter=greylist, action=rcpt, reject=451 4.7.1 Greylisting in action, 
please come back later"

as they are not yet known by milter-greylist, sendmail will respond with 
"Possible SMTP RCPT flood, throttling" if throtteling is enabled with 
"define(`confBAD_RCPT_THROTTLE',`3')dnl"

Somehow, greylisting seems to be evaluated as "bad recipient" by 
confBAD_RCPT_THROTTLE, which seems to be wrong in this case.

Ciao
Marcus

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

> Somehow, greylisting seems to be evaluated as "bad recipient" by 
> confBAD_RCPT_THROTTLE, which seems to be wrong in this case.

You can throttle with milter-greylist, see ratelimit clauses in the man
page.

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

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.

Ciao
Marcus

> i found by chance a strange phenomenon in my logfile: after three "rcpt to"
> to existing(!) addresses, which are marked with
> 
> "milter=greylist, action=rcpt, reject=451 4.7.1 Greylisting in action, please
> come back later"
> 
> as they are not yet known by milter-greylist, sendmail will respond with
> "Possible SMTP RCPT flood, throttling" if throtteling is enabled with
> "define(`confBAD_RCPT_THROTTLE',`3')dnl"
> 
> Somehow, greylisting seems to be evaluated as "bad recipient" by
> confBAD_RCPT_THROTTLE, which seems to be wrong in this case.
> 

Probable explanation is: for the sendmail to decide what recipient is valid or not,
it takes into account the return from the milters as well: 
2xx code means valid recipient, 4xx and 5xx are invalid.

My theory could be verified via reading the source code of sendmail.

"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.