Re: Spam/Virus Issues

Arthur Corliss wrote:
> <G> At $4,000 I'm not sure I agree. Even at $200/hr that would give me twenty
> hours to figure out how to configure Sendmail with SpamAssassin and ClamAV as
> milters, plus several other protections on existing hardware. Even without
> seeing the interface I'd have to bet I have more low-level control and
> flexibility than the Barracuda provides.
>
> I'm sure there's a market for it, but in my case that's too steep a price. Of
> course, I'm probably the cheapest person on the list. I don't have the time
> to work on my truck like I should but I'll be damned if I take it to a
> mechanic, either. ;-)
>

I agree, especially when I already have the 20 hours into sorting out
this problem. My solution is 100% ldap based. The idea is that no part
of the users config lives outside of ldap. That way searching it,
modifying it, and backing it up is completely trivial and there is
always a single source for the information.

Once you start down the road of some config here some config there you
will find that not all of your services or systems will jive. Suddenly
you end up with a web tool that has been hacked to touch this that and
the other thing instead of the authority for the account, the customers
ldap record.

Another thing that you get on a custom mail solution is the flexibility
of writing very low level filters.

Take mimedefang for example, it is a sendmail milter that is called in
the middle of a mail transaction. The message is passed to a pool of
running perl processes (which take most of the performance hit out of
using perl) then parsed with the excellent mime tools perl package
before giving you a object oriented interface to the milter process.
Once you have this installed you can do really crazy stuff like this:

# If user is authenticated or coming from localhost then stop filtering
if ((exists $SendmailMacros{md_tag} and $SendmailMacros{md_tag} eq
'authenticated') or ($ip eq "127.0.0.1")) {
     return ('ACCEPT_AND_NO_MORE_FILTERING', 'ok');
}

# if we get here and the user is sending from domain.com then they
aren't legit
if($sender =~ /domain.com/i) {
   return ('REJECT', 'You must authenticate to send mail from an
       domain.com account! GO AWAY!!!');
}

Remember that nasty virus that went around sending email from
support@yourdomain.com? Well because the above rules force your users
to authenticate to smtp before allowing email from your domain, it gets
stopped dead in it's tracks. This also adds a bit of integrity to your
mail solution as spoofed email has to come from an authenticated user.

Performance isn't bad, but you do need more server to start doing a lot
of filtering. A good dual cpu box with 2 gigs of memory can handle a
bit of email, but this setup is far better suited for small mail systems
than large ISP's.

schu

---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Thu Apr 22 06:19:00 2004