my other FREQ of the day

[John Rudd]

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