If you want your Perl program to spend less time sending mail, you have to let someone else spend the time doing it. That's what's happening when you let sendmail figure it all out. It's not sending the mail in a millisecond. It's queueing the mail in that long, after which your Perl program gets control again. sendmail does more work on its own.

Of course brian is right ... you're going to have to work with the sendmail admin to ensure you have your local sendmail daemon configured correctly to support the queueing. Once that's done, you can use the -odd option to sendmail for the quickest async operation (all database lookups (DNS) are deferred until the queue is run). The downside to this approach is normally delayed delivery. It may take some time for the queue to be processed and hence your mail delivered.

-derby

1 millisecond (0.0017 secs)

Are you serious! What do you mean, "what's the rush"! Have you NEVER waited for sendmail to send mail? That 0.017 seconds is torture, it's like waiting at the Department of Motor Vehicles to renew your driver's license. All of that wasted time just spent waiting, waiting, waiting, just to send an email, it's enough to make a programmer go nuts!

Joking, of course.

    -Bryan

Yeah, what's the rush. In my time, when we had to walk to the office (teleworking was done by the people inventing the television), 25 miles throught the snow, and uphill both ways, we had to bang rocks together to get our ones and zeros (I fondly remember we invented the one, that made life so much easier), we were happy if we could send an email in less than a week. To the other end of the hallway. Using bangpaths.

Youngsters. Next thing they want is interactive processing, with actual keyboard and a vt100 terminal. If batch processing was good enough for God, it's good enough for mankind.

With heartfelt apologies to both Hormel and Monty Python, could the answer to your question lie here?

Jack

Well I suspect that it does, but I didn't want to start casting aspersions