This approach should launch the configured local email client on the user's machine and then send email from there. But not all clients will be properly configured for this. (Any time you move work client side you have the problem that not every client is set up right. Such is life...)

Short answer: No.

Longer answer: The web is a stateless protocol, in other words your script only runs and generates (usually text) output and then quits, the output gets sent to the client by your webserver, which assuming they are running a standard webbrowser to connect to your script then all they can see is the output, wheither that output is a command or not.

There are some alternatives but it really depends on your clients having their own CGI script in which to grab your output and then email it that way. You can do that, but I think that probably defeats the purpose of what you're trying to do.

Finally the easy solution to what I think you're trying to do (correct me if I'm wrong) :), if you just want to show the email as being from a certain website or user, you can make the From: field of your outgoing email whatever you want it to be, regardless of where you actually send it from. Have a look at MIME::Lite which is my prefered method for sending email (easy to do attachments as well if you need something like that)

Hope that helps
Chris

Update fixed a typo.

I would advise against using this trick.

Forging an arbitrary From: field is a classic spamming technique, so a lot of spam filters look for signs of that and flag or block those emails as spam.

No no, not an arbitrary From: field. I'm assuming that he's trying to do a single email form for multiple sites or domains. He could check the REFERER to make sure its an allowed domain and then send an email with the from field being an address at that domain. So if foo.com is allowed to send mail through his form and a request comes from foo.com he sends the email with the From field with someone@foo.com where someone@foo.com is a real person expecting a reply perhaps.

That would work for most cases and where a client isn't sending the REFERER or its wrong then the connection is dropped, eleminates spammers. Maybe I should have been more clear.

On another note, companies that are hosting multiple websites do this sort of thing all the time (I know mine does) do you consider it to be SPAM? Even if the email goes to a real person and the person receiving the email knows they are getting it?

Lobster Aliens Are attacking the world!

It is possible, but it may not have all of the advantages you think. The module you would want to look at if you wanted to do this is Net::SMTP (and you'll also want Net::DNS::Resolver to get the Mail Exchanger for the recipient), but it is not as simple as just firing off one function call to send the mail and being done. In effect, your Perl script has to _become_ the sending mail server, which means it ought to handle things like retrying later in the case of a temporary outage at the recipient's end. By the time you handle everything you need to handle, you may not be saving the overhead that you wanted to save. You also need to authenticate the user, but you need to do that even if you're using a local MTA to send. And make darn sure you log the user's IP address for each message-id, or put the user's IP in the headers, or both.