Reloading confs

[James L. Day]

I like having the startup/shutdown scripts separated.  If I want to make
a change to MailScanner, I can shut it down while Sendmail continues to
run.  I find myself continually jacking with MailScanner and seldom do I
mess with Sendmail.  Yes, MailScanner is a necessary part of the e-mail
process, but I see no reason to tie it into the running of  Sendmail or
any other MTA.

I have my Sendmail checking against local RBL's and that stops about 90%
of the junk.  I can afford to let Sendmail accept messages while I have
MailScanner shut down.  If you're letting MailScanner do the RBL
lookups, perhaps you can't.

Lynn

Greg Borders wrote:
>
>
> Logan Shaw wrote:
>>> You shouldn't ever start sendmail (or restart sendmail) - you should
>>> only restart MailScanner which in turns stops/starts sendmail for you.
>> <snip>
>> I've never really understood this.
>> <snip>
>> So is there something I'm missing?  Is there a reason why it
>> is the way it is?
>>
>>   - Logan
> This is one of the single most common things I've seen when dealing
> with folks that are new to MailScanner.
> I too had to struggle with the logic of it at first.  The thing of it
> is, it's a real change from the way you would expect it to work.
> Typically you would think, "I have my MTA and it does all the mail
> work, sending / recieving etc. as a service, running happily in the
> background."
> "Then I have my virus scanner, it does the same, scans all activity
> for files getting saved."
> So here's MailScanner, it should follow the same logic, and just run
> and flag all the e-mails that come and go as a service like the others.
>
> That's the fatal flaw in the thinking.  MailScanner isn't just another
> service.  It's a way of life for e-mail. By adding MailScanner to your
> systems, you are taking the services you know and trust, and turning
> them over to a caretaker to do it for you, and it does it better. A
> lot better.
>
> Since MailScanner is now "in control", you turn off the standalone
> services.  Sendmail/Postfix/Exim/Etc. daemons are stopped.  Virus
> checkers are stopped.
> All is quiet on the server, and then you fire up the MailScanner
> service.  It is now the conductor of your e-mail orchestra, and calls
> upon the other programs as needed, to get the job done.
>
> This is my take on the flow of programs within a properly setup
> MailScanner system:
> MailScanner fires up instances of the MTA, waiting for messages to
> arrive. AKA "Children"
> MailScanner fires up instances of the MTA, waiting for messages to be
> sent.
> MailScanner fires off a slew of tasks once messages arrive.
> A batch of them are ready, MailScanner runs them thru spamassassin.
> Now any that didn't get flagged, are scanned for viruses with the
> ClamAV for example, (or more if you want).
> Then they are delivered/stored/etc. all based upon the settings in the
> .conf file with another MTA child.
>
> Whether users send messages out, or receive them, they go thru the
> same steps, and the are delivered by MailScanner via the tools that
> are wired into it.
>
> Julian has cooked up the very clever system that calls upon many
> external pieces to perform at the times needed, and has created the
> best most flexable open e-mail filtering system on the market. We can
> use many MTA's, many virus scanners, many spam scanners, and still
> have room for custom functions to do even more if we want.
>
> Take a look at the administrators guide, the first figure "MailScanner
> Process Flow".  That will make it crystal clear on the total path, and
> number of tests MailScanner actually performs.
>
> It's a wonderful concept, once you can wrap your brain around the idea
> that MailScanner is more than just an add on service. Bolt on Steve's
> Mailwatch and you have more than most e-mail admins can dream about. ^__^
>
> Greg. Borders
> Sys. Admin.
> JLC Co.
>
>
>
>
> -- 
> This transmission may contain information that is privileged,
> confidential
> and/or exempt from disclosure under applicable law. If you are not the
> intended recipient, you are hereby notified that any disclosure, copying,
> distribution, or use of the information contained herein (including any
> reliance thereon) is STRICTLY PROHIBITED. If you received this
> transmission
> in error, please immediately contact the sender and destroy the
> material in
> its entirety, whether in electronic or hard copy format. Thank you.
>