>     I'm wondering if there's a way to force the processing of *.mail files
> by sendmail.  The mail that is waiting to go to the outside world ends up
> in xxxxxxxx.mail.  (...)  When I look at one of the files, it seems to have
> all the SMTP commands to be processed by sendmail.  Is there a command
> that can be issued to sendmail to process specific files manually?  With
> all the viruses going through recently, our listserv processing is taking
> a very long time.  I have some .mail files that are sometimes 2 or 3 hours
> old.

There is a way to do that, although I would not recommend it. The command is:

/whatever/sendmail -bs < xxxx.mail >> logfile

Substitute the right path and the name of a suitable logfile. You have to erase the file afterwards and make sure it does not get submitted by an SMTP worker while you are doing that. You can also configure LISTSERV to do all this automatically instead of using standard SMTP delivery:

SMTP_ENQUEUE="/whatever/sendmail -bs < %s >> logfile"

If you go this route, you CANNOT have any SMTP workers defined or you WILL have duplicates. This obscure feature pre-dates SMTP workers and assumes there is only one process calling sendmail concurrently. It was implemented for a customer who really did not want to hear about SMTP delivery, but I think in the end it was never used. One issue in particular is that sendmail could give you a success status even though there was an error, LISTSERV will then delete the file and nobody will ever know what happened. If sendmail returns an error status, LISTSERV is not too sure how or when to retry (but it will retry, I just don't remember how). Likewise I am not sure what happens if one recipient is rejected but not the others. I am not saying that sendmail does not handle this correctly, I am saying that there are many versions of sendmail and many configuration options, spam filtering options, and so on, and I am not making any guarantees on things that I do not control, use at your own risk, etc. One final thing is that the -bs option looked like a historical feature back when SMTP_ENQUEUE was implemented in 1995.

My recommendation is to reconfigure sendmail for NOCANONIFY, which is really an absolute must-have for high loads, and to add enough SMTP workers to have your queue in sendmail rather than in the spool directory. Also, I would use the AVS to filter out all the viruses and relieve both LISTSERV and sendmail. This list has been running the AVS since 2001-10, although it wasn't called that at the time. The internal codename was "Eric got tired of all these viruses on VM and developed something so they could be filtered" ;-) Later I added statistics, redundancy, bells and whistles, but it all started with the irony of having so many PC viruses in my VM mailbox when I had such an effective filtering system for my PC. Admittedly these viruses were totally harmless on VM, but I still had to delete them. I am in many people's address book, for better or for worse, and one of the bad things is that I get a very generous serving of viruses. Every day, little SEARN receives about 850 infected messages! I cannot say for sure how many of these messages would have made them to my vs someone else's mailbox if not filtered, but one thing is sure, I am not about to turn off the AVS to find out :-)

  Eric