RE: Greylisting or Postfix
Graham Miller <graham <at> gmcs.com.au>
2006-12-06 01:09:02 GMT
George Georgalis wrote:
> well qmail and mailbox verification are like oil and water ;)
This is precisely why I use Bruce's smtpfront-qmail instead of qmail-smtpd.
Join this with the CVM authentication checking daemon and mailbox
verification into vmailmgr run mailboxes is a snap.
> I run openbsd spamd
> http://www.openbsd.org/cgi-bin/man.cgi?query=spamd&sektion=8 with
> greylisting, it's 100% separate from your mta, doing packet
> forwarding (for port 25 connections from IPs that past the test)
> from your fw to your mta. It works on all the BSDs that I'm aware
> of, since it requires pf it only works on BSDs though. It doesn't
> need be on the same box or even site as the mta, and like most
> firewalls it requires almost zero cpu. That removes 98.5% of spam
> with no (RFC compliant) false positives, presumably as any
> greylisting would.
That looks interesting. Thanks for the tip. I'll check that out. We use
CentOS here so it will be interesting to see if has a port for that OS.
I came across a little greylisting daemon that can be slotted into the run
chain for smtp. It is called cqgreylist. It greylists on IP address of
sender only.
(http://oss.albawaba.com/cqgreylist.html)
This program I stuck in the run file after rblsmtpd and before
smtpfront-qmail. It worked OK and reduced the spam a fair bit, but not
fantastic. It has a couple of problems with not closing the connection and
leaving a connection slot busy and it logs pretty messily. It used a 60
second greylist wait time. But it gave me some good ideas.
So I then wrote a new greylistd program based on the code from DJB's
rblsmtpd. By using the same timeout and exit routines as he does, I figured
the program would avoid connection hangup problems. And I used the same
error logging style as djb too. So that is much tidier.
Similar to cqgreylist, we need to run a cron script every night to remove
entries over a day old (the time I chose) otherwise we will leave open some
IP addresses of zombies that manage to get past the greylisting. There is
also a way of whitelisting and blacklisting (along the same lines as
rblsmtpd).
Although the idea came from cqgreylist, I have created this program from
scratch and seems cleaner with some more features. These things can be set
on the command line and therefore can be different per instance:
- greylist wait time.
- limited smtp conversation timeout.
- directory to use for greylisting files.
- log file verbosity.
I am using 120 seconds as a greylist wait time at the moment. This has
considerably reduced the spam further.
So I have this running on a beta test smtp interface for one of my domains
and it has substantially reduced the spam arriving in mailboxes there. I am
talking a difference of something like 150 per day down to only around 10
per day. Admittedly, it has only been going for a couple of days, but shows
promising signs.
So what is the downside of doing it in this way?
This method ONLY greylists on IP address of sender only. All we do is see if
the IP address is greylisted yet or not and if not, set the greylist file,
and have a limited conversation with the sending MTA giving it a 4xx
temporary error and exiting after running the next program in the run chain.
So zombie computers can often send mail to several email addresses at your
domain and after the greylisting wait time, any new emails from that PC will
get through. I have seen some of this in the logs already. The other spam
getting through is via what looks like legitimate mail servers.
> If the remote mta gets through that, I have accept and deny
> lists for various IPs.
Good idea. I used the same mechanism as rblsmtpd uses. Set them in the
environment (GREYLIST=) using tcpserver.
> Next line of defense is a QMAILQUEUE script that does a variety of
> tests, including spamassassin, you could probably use mailfront
> here, but I've not tried it. Anyway, pass the test and mail goes to
> qmail-queue, fail and a header is added, the return path is striped
> and it goes to qmail-queue anyway (ie users can get smtp rejected
> mail in their spam mailbox, prune the maildir with cron find old and
> rm).
Mmmm, we do not do this. Once we accept the email, we deliver it to the
client.
> I don't know exactly why you want smtp rcpt verify, but the above
> works well with near zero back-scatter. Actually, if reducing
> back-scatter is your concern, you can create an ~alias/.qmail-default
> to /dev/null at little cost (which is very similar to what I do).
Mailfront does this well with vmailmgr mailboxes.
regards
Graham
---------------------------------------------------------------------
To unsubscribe, e-mail: vmailmgr-unsubscribe <at> lists.untroubled.org
For additional commands, e-mail: vmailmgr-help <at> lists.untroubled.org
RSS Feed