Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Closing SMTP connection immediately on blacklisting

3 views
Skip to first unread message

Dietmar Braun

unread,
Aug 30, 2007, 8:08:56 AM8/30/07
to
Hi,

since Monday, we notice a new broken malware which connects to smtpd,
sending HELO and nothing more. This results in wasting all possible
smtpd processes.

Although we moved our blacklist to smtpd_client_restricions, we notice
that Postfix sends the error code/message, but doesn't close the
connection afterwards. This is different to
smtpd_client_connection_count_limit, where the connections is closed
_immediately_ after getting the "too many connections" error.

Is it possible to close the connection immediately after the 5xx
error?

Our config (excerpt):

smtpd_client_restrictions = check_client_access hash:/etc/postfix/access, reject_unknown_reverse_client_hostname
smtpd_delay_reject = no
smtpd_error_sleep_time = 0
smtpd_helo_restrictions = check_helo_access regexp:/etc/postfix/helo_access
smtpd_recipient_limit = 100
smtpd_recipient_restrictions = reject_non_fqdn_recipient, permit_mynetworks, reject_unauth_destination, check_policy_service inet:127.0.0.1:10031
smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/sender, check_recipient_access hash:/etc/postfix/recipients, reject_unknown_sender_domain

Thanks,
Dietmar


Geert Hendrickx

unread,
Aug 30, 2007, 8:41:24 AM8/30/07
to
On Thu, Aug 30, 2007 at 08:29:05AM -0400, Wietse Venema wrote:
> With Postfix 2.3 and later, reply with 421 to hang up immediately.

It would be nice to see a 5xx equivalent of that (I don't want to tell
blacklisted clients to "please try again later"). Could you add that?

Geert

Noel Jones

unread,
Aug 30, 2007, 1:08:48 PM8/30/07
to
At 07:48 AM 8/30/2007, Wietse Venema wrote:
>Geert Hendrickx:
>As if the ratware cares.

I've been experimenting for several weeks now with sending 421
response to clients that look like zombies, and results have been
impressive so far - rejects per day have dropped significantly. But
I'm a long way from actually recommending this.

The trick is don't hang up on real mail servers since they will
continue to resend.

I anyone wants to try, here's some ideas...
(intentionally incomplete examples. Not recommended for beginners).

- use check_client_access and/or check_helo_access maps that look for
KNOWN dynamic address space, using as "421 text" as the result (don't
return *just* 421 as an all-numeric response implies OK).
res.rr.com 421 4.7.1 please use your ISP's mail server

- use RBLs that identify zombies and non-MTA clients, and
rbl_reply_maps to get a 421 reply for those RBLs.
#main.cf
rbl_reply_maps = hash:/etc/postfix/rbl_reply_maps
smtpd_client_restrictions =
...
# DNS answer is cached, no extra queries
reject_rbl_client zen.spamhaus.org=127.0.0.10
reject_rbl_client zen.spamhaus.org=127.0.0.4
reject_rbl_client zen.spamhaus.org
...
# rbl_reply_maps
zen.spamhaus.org=127.0.0.10 421 4.7.1 Service disconnecting;
$rbl_class [$rbl_what] blocked using $rbl_domain${rbl_reason?; $rbl_reason}
zen.spamhaus.org=127.0.0.4 421 4.7.1 Service disconnecting;
$rbl_class [$rbl_what] blocked using $rbl_domain${rbl_reason?; $rbl_reason}


- hang up on clients with no reverse DNS. Not so sure about this
one, but it's been working well so far.
# main.cf
unknown_client_reject_code = 421
smtpd_client_restrictions =
...
reject_unknown_reverse_client_hostname
...

Use at your own risk, your mileage may vary, objects may appear
closer, contents may be hot, do not use while driving, not packaged
for retail sale, etc.

--
Noel Jones

0 new messages