|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
Re: early_talkers for postfix
From: Noel Jones (njones
megan.vbhcs.org)
Date: Tue Jun 20 2006 - 13:25:50 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
At 12:34 PM 6/20/2006, PlanAlpha wrote:
>I was reading about a plugin for qpsmtpd called
>early_talkers that
>forbid mail from senders that tried to send mail before
>the HELO. I
>believe sendmail had this feature called greet_pause. Is
>the Postfix
>equivalent reject_unauth_pipelining? Is there a proper way of
>achieving this? I'm using version 2.1.5-9 on Debian.
>Many thanks!
Sendmail's greet_pause delays the 220 greeting banner to
see if the client illegally starts sending first. This is
not very polite as it slows down connections from everybody
unless you maintain an extensive whitelist of known good
clients (basically any client that has previously passed
the test). A site using such a policy would likely need to
increase the maximum number of smtpd processes as SMTP
sessions would take longer. A high-volume site may find
this causes a self-inflicted denial of service.
The main point of something like this is to thwart the
millions of spam-bots and virus spewing PCs that are not
real MTAs. Any real MTA (and it seems most dedicated
spamware) follow RFCs closely enough to wait for the
greeting banner.
If you're interested in suppressing zombie mail, probably
greylisting is more effective. But not everyone likes the
idea of greylisting.
To answer your question, reject_unauth_pipelining does
perform a similar function, and postfix can be configured
to do a greet pause
Typical configuration. This is safe, but doesn't catch
many clients - only 1 in the last 30 days here:
# main.cf
smtpd_data_restrictions =
reject_unauth_pipelining
Greet pause configuration. This penalizes all clients to
catch a few bad apples, er, PCs. The nodelay_clients
whitelist must be maintained separately, possibly by a
user-supplied script that parses the logs for prior
successful connections. This is not generally recommended
but may be useful for low-volume sites. I would suggest a
greylist policy server as an alternative:
This requires postfix 2.3
# main.cf
smtpd_delay_reject = no
smtpd_client_restrictions =
permit_mynetworks
permit_sasl_authenticated
check_client_access hash:/etc/postfix/nodelay_clients
sleep 1
reject_unauth_pipelining
You may also catch some zombies on 2.1 and 2.2 postfix by
using a couple of RBL lookups to introduce a (somewhat
random) delay.
# main.cf
smtpd_delay_reject = no
smtpd_client_restrictions =
permit_mynetworks
permit_sasl_authenticated
reject_rbl_client sbl-xbl.spamhaus.org
reject_rbl_client list.dsbl.org
reject_unauth_pipelining
http://www.postfix.org/addon.html#policy
http://www.postfix.org/postconf.5.html#reject_unauth_pipelining
http://www.postfix.org/postconf.5.html#sleep
--
Noel Jones
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]