It will then send the mail to OpenACS, either with a HTTP POST or an XML-RPC call. (Possibly it could also put the mail contents directly into the database with nstcl. However this would not be very different from the next approach.)
Why use something like an HTTP POST instead of having the script insert the data itself, via DBI, for instance if it's a Perl script? (I guess nstcl-database is the equivalent of Perl's DBI, but I'm willing to bet that even in the OACS community a lot more people are familiar with the basic Perl modules.) I've done this on a couple of occasions for an intranet, giving the script a different DB user with just as much read and write privilege as it needs to do it's job. It's a lot easier to install, debug and enhance, and it adds hardly any complexity proportional to the overall complexity of OACS. It is also more Unix-y (it conforms to the rules of modularity, clarity, simplicity and separation, and I would argue also of parsimony, transparency, robustness, least surprise and diversity)
Also, instead of .qmail-default which will handle any otherwise unhandled address, you should use a more specific alias, e.g. .qmail-blogger (which would handle only emails to blogger@whatever.com). This leaves open the possibility of using other addresses for other purposes, and using subaliases, such as blogger-bob or blogger-alice, which would both be handled by .qmail-blogger, but the script would know that one was intended for Bob's blog and one for Alice's (à la ezmlm), without having to set up any mailboxes (not even the one required to use a sweeper.)
I'm curious about the "many hours of frustration with qmail" since I've found it to be about the least frustrating piece of software ever (no experience with vpopmail, though).
