my other FREQ of the day

[Brian May]

If MailScanner became a MTA, I think most people would not use it.  I
wouldn't trust perl to be the main engine behind a MTA.  Besides, making
MailScanner an MTA would take a *while*..  but that's just what I think..
other people may/will disagree..

I like the dual queue... if I didn't have fetchmail running for a day, and
then started it, my mail server would crawl.. use up all available swap
forking the virus scanner and spamc...  granted this was all under aMaViS..
for me.. the current state of MailScanner works well..

Brian
----- Original Message -----
From: "John Rudd" <jrudd at UCSC.EDU>
To: <MAILSCANNER at JISCMAIL.AC.UK>
Sent: Saturday, February 15, 2003 3:38 PM
Subject: my other FREQ of the day


> The three main weaknesses I see in mailscanner at the moment are:
>
> 1) the dual queue approach combined with the "wait and see if anything
> arrived while we were asleep" approach to scanning messages
>
> 2) its difficulty in working with certain mta's (it's not immediately
> obvious to me how I'd use it with courier, qmail, or communigate pro,
> and we're evaluating switching to courier or communigate pro ... but
> I'd like to stick with mailscanner)
>
> 3) somewhat related to #1 is that you cannot reject messages based upon
> results.  You can try to bounce them, after the fact, but that isn't
> reliable (because you cannot trust the return addresses).  I'd rather
> reject them outright.
>
>
> I have an idea that would solve all 3 problems, I think.
>
> Have an option for MailScanner to run as an SMTP daemon.  This would
> eliminate the sendmail daemon that runs in queueonly mode.  It would
> mean that it could work with courier and communigate pro because it
> would just invoke their "sendmail" command line command when it's done
> processing the message, it could be set up to reject messages during
> the initial session, and you wouldn't end up with messages backing up
> in mqueue.in during heavy traffic periods (we still get that, even
> under 4.x) because there wouldn't be an mqueue.in.
>
> I wouldn't expect its daemon features to be terribly extensive.  You'll
> want something similar to sendmail's "stop accepting new connections
> when the load is over X" feature, as well as a throttling feature to
> keep individual sites from flooding the server.  The main mailscanner
> process would do the listen, and then fork children to handle the
> individual connections (the way sendmail does).  And, you'd want to add
> two new rule types to mailscanner: a) relay rules (who we will or wont
> relay for), and b) something which will function like the sendmail
> access db.  And you'd want a few new action options (instead of
> bouncing messages back to virus or spam senders, you'd want an option
> to reject them with a specific message, like "550 Contained the
> $VIRNAME virus" or "550 Looks like Spam" etc.).
>
> (in my case, I would probably reject viruses, deliver "Spam", and
> reject "High Spam")
>
> I understand that to a certain extent this may be unattractive because
> it duplicates several things that sendmail already does (and does
> well), but the gap between the initial sendmail daemon and mailscanner
> continues to annoy me (more and more every day, really).  I'd really
> like to eliminate it, and I think eliminating it would improve
> mailscanner on those 3 fronts.
>
> We could reject messages without bouncing them, we wouldn't ever have
> mqueue.in backing up with unprocessed messages, and it could be made to
> seamlessly work with any MTA which has a command line "sendmail"
> program.
>
>
> Am I the only person who would find that to be a useful direction for
> Mailscanner?  I could probably help some with implementation (in fact,
> I might even be able to convince my boss that it's important enough to
> our services that I could make it one of my front-burner projects), and
> I would definitely be able to provide a machine or two for testing.
>
>
> John
>