On Fri, 2006-09-01 at 22:48 +0800, Feizhou wrote:
> >> Hence why I have spamassassin used to filter after the mail is queued.
> >> Do you make mimedefang run spamassassin on all your mails before queueing?
> >>
> >
> > Inbound only, and after the other faster checks (virus, etc.) that
> > might cause rejection are done. The advantage of scanning during
> > the SMTP conversation is that you can still reject with a
> > message that would find its way back to a legitimate sender
> > without having to construct the bounce yourself.
> >
> I don't bounce the mail. I just tag the mail as a possible spam.
> Different ways of handling this :)
I mostly do that too, but I've tweaked some of the spamassassin rules
(vi*gra, etc.) to extremely high values, then MimeDefang rejects
on values that can only be reached that way with lower values
passed in a header tag for user processing.
> > Actually you can have multiple milter processes if you want, but
> > MimeDefang handles about everything. Also, sendmail has separate
> > conversations with the milter(s) for each operation which
> > MimeDefang might hand off to different slaves. The side effect
> > is that you don't block on some other long-running process unless
> > you are out of slaves but you also can't count on globals that
> > you set in one step (checking the sender or recipients) to be
> > available in later steps - but MimeDefang passes most of the
> > information you need each time and has dropped a complete
> > copy of the message broken out into its MIME components in
> > files where the programs can find them (hence the name and
> > the advantage of running multiple scanners under its control).
> >
> >
> So you are saying that mimedefang is not reliable if not provided enough
> resources.
No, I didn't say anything even close to suggesting that - and I'm
curious as to why you imagined I did. What I said was that different
phases of the filtering are likely to be handled in different processes
so your programming should be done accordingly.
> What happens to the mail then? temporary reject or let through?
Sendmail will tempfail if it can't connect to it's configured
milter(s) or it gets a socket error and there are 4 timeouts that can
be set per-milter if you don't like the defaults. And of course
sendmail
has its own configurable limit on the number of sendmail children.
MimeDefang will tell sendmail to tempfail if a slave runs out of
resources or crashes - like a virus scanner unpacking one of those
zip-of-death archives might if it is configured incorrectly. The
mimedefang-multiplexor process controls the slaves with a lot of options
that I've never had to change from the defaults.
--
Les Mikesell
lesmikesell@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
