Well, this mediocre monk says that putting the code that generates the mail and the code that sends it, in a separate process/thread means that one is not dependent on the other.

You can fork and send the mail from a separate process, but be careful because forking under mod_perl can be tricky. Or you can use a PerlCleanupHandler. http://perl.apache.org/docs/1.0/guide/performance.html#Forking_and_Executing_Subprocesses_from_mod_perl

I think that your best bet would be to do a minor re-design of your application at this point. Rather than sending an email directly, you should be writing a job to a queue (eg by writing to a table in a database). Another job should then run in the background to process that queue (eg from cron) and actually send the messages. This is much more resiliant in case of downtime (eg mailserver maintenance won't take your site down), and won't force your users to wait whilst your application tries to send mail.

If you don't want to do that though, then the first thing I'd check is whether you're talking to a remote mailserver, or one that's running on the local machine. Talking to a mailserver on the local machine is likely to be a lot faster than talking to a remote machine.

If that isn't the problem, and you're running sendmail locally, then stopping sendmail trying to do ident queries may also help (confTO_IDENT in your sendmail.mc file), as may checking your /etc/hosts file to make sure you have a proper entry for localhost in there.

That does sound a bit long. Just out of curiousity, are thoe messages very large? Also, if it is the *exact* same message going to multiple addresses, are you building a new copy of the message for each?

There are libs that go directly to the MTA's queue. One example is for Qmail QmailQueue