Jenda Krynicky wrote: > From: Gunnar Hjalmarsson <nore...@gunnar.cc> >> Steve Bertrand wrote: >>> Fúlvio Figueirôa wrote: >>>> I solved my problem using sendmail with the code below: >>>> >>>> open (MAIL, "|/usr/sbin/sendmail -t "); >>>> print MAIL "From: someaddr...@somedomain\n"; >>>> print MAIL "To: someaddre...@somedomain\n"; >>>> print MAIL "Content-Type: text/plain\n"; >>>> print MAIL "Subject: Very simple email test\n\n"; >>>> print MAIL "Body of the message"; >>>> close (MAIL); >>> I've had issues with doing things this way in the past. From my >>> experience with the above code, if there is a fault, the message will >>> not be sent, nor will it be queued to be sent later. Depending on the >>> situation, not having the program follow proper SMTP protocol could be a >>> problem if a message is not delivered, and there is no trace of it in >>> any queue. >>> >>> Perhaps someone here can verify that there is a workaround, but I would >>> highly recommend at least handing off the message so that a proper MTA >>> can take care of any network-type issues for you, even if the MTA is on >>> the localhost. >> That comment confuses me. AFAIK, sendmail *is* an MTA (mail transfer >> agent), which e.g. handles queuing, and the above code passes a message >> to sendmail. I also believe that there are built-in defaults in sendmail >> that help you conform to certain aspects of the SMTP protocol. > > sendmail is both an MTA and a commandline program for handing stuff > over to the MTA. The problem with this way to sending emails from > scripts is that it's hard to handle the errors reported directly by > the sendmail commandline program. Once this step succeeds, the email > is gonna be kept in the queue, retried etc. But if the sendmail > refuses the email right away, you'll never know. You'd have to check > the return value of the close(MAIL) to find out whether it succeeded > and capture and parse the /usr/bin/sendmail's STDERR to know what > failed.
Thank you. I should have clarified the difference between sendmail the command-line user agent, and Sendmail, listening as an MTA. Jenda spells out in a more understandable way the consequences of using the command-line `sendmail' from a Perl script. > It's generaly safer to leave this to a module. Either one that calls > the /usr/bin/sendmail in such a way that you do get the error info or > one that contains the MTA via SMTP, not via the commandline program. ...it is clearly much safer to have error codes left for you in the event that an email can not be delivered. Many modules will allow you to catch the error and save the message even if the initial attempt to contact an SMTP server fails. In most circumstances, knowing that an email did not go out is desirable. Further that, it's even better to have that attempted email be saved, and if necessary, retried later. Regarding my comment "...even if the MTA is on the localhost.", Sendmail runs by default on all FreeBSD systems I've ever built or used. Using a module, you can hand off the message to localhost:25 or what-have-you, and you can be sure that so long as you receive 'localhost' system messages, you will be made aware if a queued message could not be delivered to the destination domain's MX. Compare that to using the command line sendmail, you will likely never know if the message succeeded or not. Thanks Jenda, for your clarification. It is much appreciated. Steve -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
