Date: Fri, 02 Apr 2010 07:12:18 +0100 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: freebsd-questions@freebsd.org Subject: Re: Sendmail Five Second Greeting Delay Message-ID: <4BB58AC2.50009@infracaninophile.co.uk> In-Reply-To: <201004011751.27767.npapke@acm.org> References: <201004011751.27767.npapke@acm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/04/2010 01:51:27, Norbert Papke wrote:
> When I connect to sendmail on a local interface, sendmail responds to the
> connection with its "220" greeting immediately. If I connect to sendmail from
> another machine on my (home) LAN, sendmail delays five seconds before sending
> the greeting. I would like it to respond immediately.
> A quick search turned up a "greet_delay" feature in sendmail that would cause
> this type of behavior. To the best of my knowledge, I do not use this
> feature. Just to be sure, I tried to explicitly enable it with both a default
> 0 second timeout and an explicit 0 second access rule. This did not the
> resolve the issue.
For the sake of the archives, I'd like to note that the `greet_pause'
feature is actually a pretty effective and very cheap to implement
anti-spam measure. You need:
FEATURE(greet_pause, `5000')dnl ## 5 seconds
in your $(hostname).mc file -- this gives you a default 5 second delay.
If you also have
FEATURE(`access_db')
you can override that value for particular IP ranges or domain names.
This is also a handy addition to the .mc file:
LOCAL_RULESETS
SLocal_greet_pause
R$* $: $&{daemon_flags}
R$* a $* $# 0
This turns off greet_pause on network ports where authentication is
required, ie. if you use port 587 for submitting new mail and reserve
port 25 for MTA to MTA mail transfers.
The way this works is that it requires the sending side to wait until
your system prints out the greeting banner. If the sending side starts
speaking before then, sendmail will refuse to accept any mail during
that session. All real MTAs will get this right, as it is part of the
SMTP specification in the RFCs. Many spambots on the other hand, send
e-mail by simply replaying one side of a recorded SMTP conversation
without reguard for what the other side says. This feature weeds out
that sort of spambot with very little effort.
Cheers,
Matthew
- --
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAku1isIACgkQ8Mjk52CukIxZHgCfYCSyseFoQ+M89C1kJIt+Oq8n
bKcAoIpNrzUS2xN3ZGGZ889qLZq6TRmD
=U4Ip
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BB58AC2.50009>