Re[4]: how to block connections at TCP level?

>> Sadly, firewall CAN NOT refuse connection using DNSBL check on
>> originating address.

GAW> Well, "CAN NOT" is I think a little bit strong. It's certainly
GAW> possible, though no doubt not so practical.

>> When you block at this stage, some amount of traffic already
>> passed. Ideally (for me), postfix should refuse connections from, say,
>> dynamically allocated IPs using some blacklist.

GAW> No application can refuse TCP connections with the standard sockets API.

There are a plenty of TCP wrappers of any kind doing this, and they work using standard sockets API and are portable. At least, it is possible to deny (if not to refuse) connection - no answer to connection attempt. If such wrappers can do denial using cidr lists, why not to implement this additionally checking src IP against DNSBL?

Many kind of tcp daemons include this functionality to prevent access from unwished networks or to allow from wished ones. Yes, ok, I realize that this is not directly mail-related functionality, but "in a days of spam and worms" this becomes necessary.

>> Practically, I think,
>> at least some sort of DISCONNECT action in maps can be implemented to
>> reduce traffic amount used by useless connections.

GAW> Disconnecting an active SMTP connection without proper protocol
GAW> interaction will not have the effect you seem to wish it to have -- the
GAW> client will simply try again later (and perhaps not very much later at
GAW> all -- e.g. perhaps only milliseconds later if it's badly misbehaved).

I don't think so. If a spammer's mailer can not see SMTP server, it should go away. Hopefully. :) If it's so misbehaved to be a woody woodpecker, it will try again even if greeted with "554 Go avay, please, please". And will eat traffic (yes, they did).