SMTP banner delay
spamd...@natrium.datanet.hu
I would like to implement a short delay before postfix sends the "220 ..." smtp banner.
I added few lines to src/smtpd/smtpd.c and src/global/mail_params.h which creates a new
config parameter var_smtp_banner_delay:
in src/smtpd/amtpd.c:
+ if(var_smtp_banner_delay > 0)
+ sleep(var_smtp_banner_delay);
+
smtpd_chat_reply(state, "220 %s", var_smtpd_banner);
Can someone tell me whether this sleep has a performance impact? If you know a better mechanism
for this initial delay, please let me know.
Thanks,
SJ
J.D. Bronson
Sendmail 8.13.1 offers this and it would be a VERY welcome addition to postfix.
On my sendmail machines I use a 5 second delay. It stops an incredible
amount of spam...however there are some legit companies with do
pre-greeting traffic (gmail.com for example) so there would need to be some
exceptions...
- Jeff
Wietse Venema
> Hello!
>
> I would like to implement a short delay before postfix sends the "220 ..." smtp banner.
> I added few lines to src/smtpd/smtpd.c and src/global/mail_params.h which creates a new
> config parameter var_smtp_banner_delay:
>
> in src/smtpd/amtpd.c:
>
> + if(var_smtp_banner_delay > 0)
> + sleep(var_smtp_banner_delay);
> +
> smtpd_chat_reply(state, "220 %s", var_smtpd_banner);
>
> Can someone tell me whether this sleep has a performance impact? If you kn
> for this initial delay, please let me know.
This means you are creating your own D.O.S. on your own mail system.
Consider using greylisting instead.
Wietse
Victor Duchovni
> However there are some legit companies with do
> pre-greeting traffic (gmail.com for example) so there would need to be some
> exceptions...
>
Do you have evidence to back the claim that gmail has a non RFC compliant
SMTP client?
--
Viktor.
Disclaimer: off-list followups get on-list replies or get ignored.
Please do not ignore the "Reply-To" header.
To unsubscribe from the postfix-users list, visit
http://www.postfix.org/lists.html or click the link below:
<mailto:majo...@postfix.org?body=unsubscribe%20postfix-users>
Len Conrad
>>I would like to implement a short delay before postfix sends the "220
>>..." smtp banner.
These are our typical numbers for avg STMPD sessions:
Per-Hour SMTPD Connection Summary
hour connections time conn. avg./conn. max. time
--------------------------------------------------------------------
0000-0100 59493 107:06:49 6s 371s
0100-0200 61853 112:33:40 7s 226s
0200-0300 61503 110:41:06 6s 234s
0300-0400 54616 94:38:46 6s 224s
0400-0500 62865 108:10:08 6s 210s
0500-0600 547 1:00:13 7s 229s
Adding a 5 sec delay to SMTP greeting would almost double the avg session
length, which is a waste of our MTA resources and is a scalability issue
(longer sessions => more SMTPD sessions in RAM to handle the same incoming).
I can see putting such a delay into a restriction class for IPs without
PTR, or an IP from a subscriber access network, but does postfix know the
result of the PTR/A query before giving SMTP greeting? But even in those
two classes of IPs, our policies are extremely effective, efficient, and
aggressive since 99+% of those IPs are spamming. So what gets past our
policies is already miniscule, and we are well into diminishing returns
chasing those last crumbs.
I think I would not use such a delay since we have made our MX very
impatient with its smtpd timeouts, have SHEL = 2, run anvil and
greylisting, all in the interest of not wasting our MX resources on the 75%
to 95% of connections that are illegit. We can now envelope-reject 40+
msgs/second without being DoSed.
But, greylist/postgrey has been unimaginably effective, so I'm open to
being surprised that a delay in SMTP greeting delay could replace any of
the defenses we already have. But I wouldn't bet a warm, flat beer on it.
Len
_____________________________________________________________________
http://IMGate.MEIway.com : free anti-spam gateway, runs on 1000's of sites
spamd...@natrium.datanet.hu
About how much performance loss should I expect if I'm still
stuck with the sleep() delay?
SJ
J.D. Bronson
> > However there are some legit companies with do
> > pre-greeting traffic (gmail.com for example) so there would need to be
> some
> > exceptions...
> >
>
>Do you have evidence to back the claim that gmail has a non RFC compliant
>SMTP client?
This was just talked about on the comp.mail.sendmail forum.
Since I use sendmail on one of our machines...I too experienced this.
Seems there are a few RFC violations for gmail.com ;)
-JEFF
Magnus Bäck
spamd...@natrium.datanet.hu wrote:
> About how much performance loss should I expect if I'm still
> stuck with the sleep() delay?
How long is a piece of string?
--=20
Magnus B=E4ck
mag...@dsek.lth.se
Victor Duchovni
> I can see putting such a delay into a restriction class for IPs without
> PTR, or an IP from a subscriber access network, but does postfix know the
> result of the PTR/A query before giving SMTP greeting?
It does, indeed with "smtpd_delay_reject = no", the client restrictions
are processed before the greeting, so one could implement a selective
delay for some clients via a policy server... A blanket delay makes no
sense, one should only consider delay for traffic that would otherwise
be rejected, but that is likely to cause some false positives... The
best place for such a (selective) delay is in the DATA response, just
prior to a reject_unauth_pipelining check.
spamd...@natrium.datanet.hu
>>How long is a piece of string?
I thought about 3 sec would be fine.
(I created a new config variable called smtp_banner_delay).
SJ
J.D. Bronson
This is the setting I use on sendmail. Seems like a good balance.
sendmail[934]: i8K5JuAr000934: rejecting commands from [61.110.211.199]
[61.110.211.199] due to pre-greeting traffic
..other than gmail.com, I have not seen a false positive. virtually all of
the machines that get rejected are either missing reverse and/or sending SPAM.
Of course there is NO outgoing delay on my side...so for a minor 3sec delay
on incoming email (whats 3 seconds after all) - to block the amount of spam
we do...its alot faster than querying RBL servers and what not if you think
about it...right??
-JEFF
Victor Duchovni
You are deliberately penalizing all mail. RBL lookups are cached, this
delay is for each delivery. Under load all your SMTP servers will be
asleep and no new mail will arrive. While your theoretical peak input
rate is 33 messages per second (with a process limit of 100), the actual
limit is lower because many connections will not result in a delivery,
and there will be other delays in addition to the 3s minimum. This is
not a good idea. Don't break real email while fighting spam.
spamd...@natrium.datanet.hu
You convinced me that delaying all email is a bad thing. Now I tried the following.
I created a CDB file which lists those MX hosts exchange email with me.
Than I created a policy server which answers back to postfix immediately if
we are talking to a friendly whitelisted host or waits 3 secs before it answers
with 'DUNNO' to postfix. Do you think this is a better solution?
SJ
Victor Duchovni
Yes this is better, but you need a way to add more relays that are found
to send "mostly" legitimate email. Legitimate MTAs come and go, and you
cannot statically define them all once. Why do you need this at all? I
find that RBL + anti-spam content filter is sufficiently effective.
spamd...@natrium.datanet.hu
>>Why do you need this at all? I find that RBL + anti-spam content
>>filter is sufficiently effective.
As Jeff has also said this initial delay may reduce spam with even 40%.
Of course I will maintain whitelisted hosts regularly.
Currently I do not use RBL-lists, I am satisfied with my bayesian filter
on my computer. This smtp banner delay approach is planned to a different
configuration where spam is a greater issue.
SJ
lst_...@kwsoft.de
> Hello!
>
> You convinced me that delaying all email is a bad thing. Now I tried th=
e
> following.
> I created a CDB file which lists those MX hosts exchange email with me.
> Than I created a policy server which answers back to postfix immediatel=
y if
> we are talking to a friendly whitelisted host or waits 3 secs before it
> answers
> with 'DUNNO' to postfix. Do you think this is a better solution?
Why reinvent the wheel??
Use greylisting
http://www.greylisting.org
http://www.postfix.org/SMTPD_POLICY_README.html
http://www.postfix.org/addon.html
Regards
Andreas