Except by piping to sendmail, you can also specify -odq, which says
to sendmail 'dump this into the mail queue and return immediately, I
don't want to wait for delivery to work' which can make the application
much faster and leave the mail delivering to sendmail.
No difference, when I SMTP my mail the server only has to dump it into it's
queue, then I get the OK back.
The best solution would be to do both, use sendmail on the web server to
deliver into a local mail queue which is forwarded to the smarthost for
delivery.
No point, you're just adding an additional MTA into the loop.
I suggested using the mail gateway as at any decent ISP it's likely to
almost always be available. Unlike individual servers which may have broken
config etc. So unless the local MTA needs the services of a smart host for
routing problems, then it's extra hops.
That way you get the advantage of having the mail server handle the mail,
while freeing you from having to write your own version of sendmail to
deal with these situations:
* What does your application do if the smarthost is getting pounded by
spammers and that outgoing socket connect fails?
* What does your applicaiton do if the smarthost is down for maintenance
or hardware failure?
I'd do the same as what I'd do if I were piping to sendmail - you do check
the return value of the open? And all the print statements? And the close
statement don't you?
Does your ISP keep a close eye on mail queues to make sure that the stuff
you're blindly dumping on the local MTA is actually getting delivered?
Carl
_______________________________________________
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
