[IMC-Tech] Re: [Imc-web] Email and imsahp Tue Aug 22 10:42 CDT reboot

[Zach M]

It should be further noted that some of our spam problems are
unavoidable. Even gmail's fairly advanced spam filter has been letting
through more and more spam every day (even as it captures more and
more as well....just like our spam filter...it stop thousands of spams
daily...that we see hundreds of spams getting through may be bad but
it could be MUCH worse). The spammers are getting smart faster than
the anti-spam software is getting effective.

One thing we need to look into is some software that will allow users
to have access to their stuff that gets identified as spam so that ham
can be found without sysadmin intervention.

On 8/23/06, Zach M <leftistmuppet at gmail.com> wrote:
> I moved away from spamd/spamc....amavis is a much more advanced
> framework for using spamassassin. It uses the perl libraries directly
> so it's like spamd on crack because it also does the anti-virus stuff
> which is very important. It also integrates much more nicely with
> postfix.
>
> The configuration is a very good one. The problem we had today was
> because of a known and patched security problem. There really isn't a
> problem with our mail config except that we need to put better SA
> rules in place and also add in some smarter envelope-level filtering
> options in postfix. I highly recommend getting the O'Reilley postfix
> book!
>
> One limitting factor is that because of all the CPU and memory that
> apache eats up we are limitted in how many concurrent amavis processes
> we can run. Mail would run much more quickly if could run twice as
> many amavis processes concurrently. Once again everything on this
> system is pretty well tuned EXCEPT that apache sucks all the system
> resources. Fix apache and lots of other problems fix themselves.
>
> On 8/23/06, dan blah <dan.blah at gmail.com> wrote:
> > awesome... thanks for the info.  what do you think about using the sa
> > blacklists and moving to spamd/spamc?  also, i was thinking about
> > using temfs for the spool directory used to create the tmp files for
> > scanning.  dunno if all of this will help or hurt performance.  as it
> > seems to me fixing/moving apache will solve lots.
> >
> > On 8/23/06, Zach M <leftistmuppet at gmail.com> wrote:
> > > I just upgraded clamav which had a recently discovered buffer overrun
> > > that allowed a denial of service attack. The mail queue is now empty.
> > > I suspect this may have been the problem.
> > >
> > > There is no customer list. Someone has to generate one. Look at all
> > > the mailman lists and all the virtual hosts in apache. Figure out who
> > > runs each organization. Ask me about ones you can't figure out.
> > >
> > > Mail works like this:
> > >
> > > Postfix receives a message via smtpd.
> > >
> > > The message is first passed to postgrey which does greylisting (if no
> > > messages have been previously received from this
> > > <sender,recipient,sender-ip> triple before  then delivery acceptance
> > > is deferred for 300 seconds. Correctly configured mail daemons resend
> > > every 5-15 minutes. Some spammers tend not to resend. Postgray is a
> > > service that gets a message a message on a localhost port and simply
> > > returns an answer of whether the message should be accepted or
> > > deferred.
> > >
> > > When the message gets past postgrey it is sent to amavisd. Which is a
> > > spam and virus filtering daemon that coordinates spamassassin and
> > > clamav. Amavis receives an SMTP style message on a localhost port and
> > > then re-delivers an SMTP style message back to a special localhost
> > > port on postfox.
> > >
> > > Amavis sends the message to clamav for a virus check.
> > >
> > > If the message passes clamav, Amavis sends the message through
> > > spamassassin for a spam check.
> > >
> > > If the message passed spamassassin, amavis sends the message back to
> > > postfix for final delivery.
> > >
> > > Things you can tweak: There are a number of envelope checks that
> > > postfix can do that you could enable. You could prevent postfix from
> > > ever even accepting certain messages from certain kinds of spam
> > > sources (using black hole lists, using checks for non-RFC compliant
> > > SMTP behavior, etc). Every one of these checks introduces the
> > > possibility that ham will be lost forever without sender or recipient
> > > knowing that it was mis-identified. These policies must be very
> > > carefully researched and considered.
> > >
> > > Spam assassin rules can be adjusted/updated.
> > >
> > > Spamassassin rules live in /etc/spamassassin. In particulate check out
> > > /etc/spamassassin/local.cf
> > >
> > > Postfix configs live in /etc/postfix. In particularly check out
> > > main.cf and master.cf.
> > >
> > > Amavis configs live in /etc/amavis/amavisd.conf
> > >
> > > Caught spam and virus mails live in /var/lib/amavis/virusmails (which
> > > I occasionally rotate out since it has tens of thousands of messages
> > > in it).
> > >
> > > I have several utilities for redelivering caught spam at:
> > > /home/wolfgang/bin/process_spam.pl and /etc/wolfgang/bin/redeliver_non_spam.pl
> > >
> > > If you are going to use the spam redelivery programs PLEASE read them
> > > carefully and understand what they do first. They are quick hacks that
> > > I put together myself and I need you to understand them before running
> > > them.
> > >
> >
> >
> > --
> > Daniel
> > _______________________________________________
> > IMC-Tech mailing list
> > IMC-Tech at lists.ucimc.org
> > http://lists.chambana.net/cgi-bin/listinfo/imc-tech
> >
> >
>