Milter-greylist

On Mon, Jul 28, 2008 at 04:49:51AM +0200, manu@... wrote:
> Constantine A. Murenin <mureninc@...> wrote:
> 
> > The patch below is supposed to address this behaviour, although it 
> > hasn't been tested in production as of yet.  Does it look all right?
> 
> There is one small problem: if real_rcpt returns tempfail or reject, you
> counted an addicitonnal recipient that does not exist.

Well, that's more of an intended behaviour -- we want to use rcptcount 
to blacklist spammers that send messages to possibly non-existing addresses, 
and not valid cases where the recipients are actually good to go, right? :)

> So your fix may improve the situation, but still contain a bug. I fail
> to understand what logic is to blame: in what situation the counter
> increasse in add_recipient hurts?

Right after the initial set of "acl whitelist" rules, I have 
the following rule:

	acl blacklist rcptcount >= 3 flushaddr msg "sorry, you're flushed"

Yet fgrepping through /var/log/maillog, which averages 30MB a day, 
returns no signs that this rather strict rule has ever matched. 
Looking closer at certain entries in greylist.db and then tracking 
them through /var/log/maillog, or just looking at maillog alone, 
shows that some spambots do indeed try more than 2 addresses 
in a single transaction, yet the rule never clicks.

Example from maillog:

Jul 27 00:06:36 ???? sm-mta[92561]: ruleset=check_relay, arg1=[211.94.125.139], arg2=211.94.125.139, relay=[211.94.125.139], reject=421 4.3.2 Connection rate limit exceeded.
Jul 27 00:06:42 ???? milter-greylist: m6R46eU1092574: addr [77.31.231.216][77.31.231.216] from <yahvarc@...> to <patcassel@???????????.??> delayed for 01:00:00 (ACL 286)
Jul 27 00:06:42 ???? sm-mta[92574]: m6R46eU1092574: Milter: to=<patcassel@???????????.??>, reject=451 4.7.1 Temporary failure, please try again later. (ESMTP spamd IP-based SPAM blocker)
Jul 27 00:06:42 ???? milter-greylist: m6R46eU1092574: addr [77.31.231.216][77.31.231.216] from <yahvarc@...> to <parque-jones@???????????.??> delayed for 01:00:00 (ACL 286)
Jul 27 00:06:42 ???? sm-mta[92574]: m6R46eU1092574: Milter: to=<parque-jones@???????????.??>, reject=451 4.7.1 Temporary failure, please try again later. (ESMTP spamd IP-based SPAM blocker)
Jul 27 00:06:42 ???? milter-greylist: m6R46eU1092574: addr [77.31.231.216][77.31.231.216] from <yahvarc@...> to <parraco@???????????.??> delayed for 01:00:00 (ACL 286)
Jul 27 00:06:42 ???? sm-mta[92574]: m6R46eU1092574: Milter: to=<parraco@???????????.??>, reject=451 4.7.1 Temporary failure, please try again later. (ESMTP spamd IP-based SPAM blocker)
Jul 27 00:06:42 ???? milter-greylist: m6R46eU1092574: addr [77.31.231.216][77.31.231.216] from <yahvarc@...> to <pault2@???????????.??> delayed for 01:00:00 (ACL 286)
Jul 27 00:06:42 ???? sm-mta[92574]: m6R46eU1092574: Milter: to=<pault2@???????????.??>, reject=451 4.7.1 Temporary failure, please try again later. (ESMTP spamd IP-based SPAM blocker)
Jul 27 00:06:42 ???? sm-mta[92574]: m6R46eU1092574: lost input channel from [77.31.231.216] to IPv4 after data
Jul 27 00:06:42 ???? sm-mta[92574]: m6R46eU1092574: from=<yahvarc@...>, size=0, class=0, nrcpts=0, proto=ESMTP, daemon=IPv4, relay=[77.31.231.216]
Jul 27 00:06:59 ???? milter-greylist: m6R46vcS092618: addr bzq-84-109-52-26.red.bezeqint.net[84.109.52.26] from <trnygo@...> to <one4jettn@???????????.??> delayed for 01:00:00 (ACL 286)

Yes, in this example sendmail itself mentions nrcpts=0, but that has 
a different meaning and name than an 'rcptcount' feature in a greylisting 
software, where tempfail is the norm, not the exception.

I do think there's something wrong if I have a rule to flush all the 
tuples from a given IP-address when more than 2 recipients per envelope 
are ever presented, yet milter-greylist wastes my memory by greylisting 
even more tuples from the spambot in question, and I do think that 
my patch indeed solves this problem.

Best regards,
Constantine A. Murenin,
University of Waterloo.