Re: Which greylist milter is least maintenance

On Sat, 08 Dec 2007 09:41:42 -0800, dp <dp@xxxxxxxxxxx> wrote:

Jim Britain wrote:
I am going to implement greylisting in a sendmail milter.

Which is the most maintenance free in a business environment?
One mailserver, 100 addresses, about 14,000 active customer
correspondents. average daily mesage volume of 1,200 valid messages
after removing the 92% of spam/uce.

I'm shooting for removing the additional 150-200 spam messages a day
that get through.

I'm considering:
milter-greylist, graymilter and milter-gris, and smf-grey.

My experience with greylisting has not been particularly good. Technically it works
great but end users seem to be endlessly annoyed with it. It has some surprising
consequences, and delayed mail is common place (leading to annoyed users).

If you have multiple mail servers and MX records a sending system, on receiving a
tempfail, will try the next. If that also has greylisting it will move to the next
until it has exhausted your mx list. It will then queue the message and try later.
Sometimes very much later, but that is out of your control.

This is a 'single server' solution (at least as it appears to the
outside). It is a remote sendmail server, feeding an Exchange server
inside a firewall.

My solution has been to use J-Chkmail (http://j-chkmail.ensmp.fr/) for my anti-spam
milter because it includes greylisting using a tcp/ip connected j-greyd database
daemon that all the mail servers can talk to - one database for all servers. It also
provides Bayesian filtering, an internal hook to Clamd over unix or tcp/ip sockets,
regex content filtering, URL blacklisting, behavioral analysis (open connections,
connection rate, bad MX records, etc).

I've taken a look at j-chkmail, and there's too many moving parts and
configuration files -- and a good part of it duplicates other
functionality we already have installed and working.

In addition, we are currently using MailScanner/spamassassin, with
MailWatch. But, now want to limit the amount of mail handled by
MailScanner -- stopping the UCE/spam at the connection point, rather
than later after receipt.

We already have well developed whitelists over the last two year
period, inserted in the sendmail access.db, but access.db maintenance
is becoming labor intensive, with 3500 lines -- maintained by hand.
Mostly 550 responses, with a smattering of Connect: rejects,
GreetPause and various others.

We use GreetPause, with unknowns set to 60 seconds (not my choice).
internal and good addresses set to zero, or 10 seconds, pipelining
turned off. Connection rate throttling, with /etc/host based blocking
on the third ignored delay on the rate throttling.

My boss typically runs scripts every couple of days maintaining the
550 responses, based upon spam accepted into our spam user account.

But this gets a little sloppy, and difficult to track updates, where
some IP listings, may duplicate name based entries, or where some
specific host name listings may conflict with more general domain
listings.

It's the final 8% of spam I'm looking to address.

I don't need or want anything other than the grey-listing feature on
the initial connection.


To keep the userbase happy it was necessary to whitelist all the major ISPs, all B2B
partners, all the big mail handlers like postini, and of course all your own
networks. In addition you have to whitelist certain recipients. Sales people don't
like to have sales opportunities delayed for even a second. They would rather deal
with spam than miss a sale.

Surely there are other solutions and even other problems.

I'm also looking to move Regular Expression filtering to a separate
milter, as currently we are using procmail on the delivering end with
about 1000 lines of REGEX based filtering on specific spam words by
field collections, or special internal routing, or feed to
applications.

I'm wanting to cut back on the maintenance labor required to keep the
spam from business, and only use procmail for special logging and
routing.

The advertising side of the business has become acclimated to 10
minute delay in mail due to spam processing. (sometimes 3 second,
sometimes 10 minute during database reload, restart).

I'm looking to sometime in the next year to set up a dual database,
one updating/reloading, and the other in use. Then I can knock down
that sometimes 10 minute delay back to under 5 seconds

.

Relevant Pages

  • Re: Fiber Optic
    ... There are several other such servers out there. ... some good guidance on whether your connection is buffer-limited ... address for spam. ...
    (comp.unix.bsd.freebsd.misc)
  • Re: The German server is playing up.
    ... I see very little shite and spam this end, and I use my own manual filter ... broadband providers have news servers? ... connection you were using, and it still wouldn't get around using wifi ... SteveH 'You're not a real petrolhead unless you've owned an Alfa Romeo' ...
    (uk.rec.cars.modifications)
  • Re: Which greylist milter is least maintenance
    ... servers in a while to retry the connection. ... I use two minutes - but while some servers retry ... As with spam and most other IT related ...
    (comp.mail.sendmail)
  • RE: Spamcop issue
    ... Your clients should probably go through your mail server to send mail, so why let SMTP outbound open? ... And if you know you're being a spam source, ... servers in Hong Kong. ... Hmmm, HTTP connection over some high port number, downloading ...
    (Security-Basics)
  • Re: MTA on non-standard port
    ... one machine on my LAN is allowed to speak SMTP to the world. ... with his/her laptop, which happens to be infected and sends spam, etc. ... Comcast stirred up the ants. ... servers!), citing "an incident of spam from my IP address". ...
    (freebsd-questions)
Loading