in reply to Re: Re^2: Can I clean this up??
in thread Can I clean this up??

Some people feel strongly about this, and I can in a sense understand why. SMTP might go down, so it is risky. Honestly, if your SMTP service is that crummy, and you can do a better job, run your own.

If your application requires a database back end, it's not going to work very well if that database is down, overloaded, or unreachable. Likewise, if your application requires an operational SMTP server, it will suffer in a similar way. Put it this way: Both the database and the SMTP service are mission-critical services which should not go down, and if they do, you better hustle and fix them. To prevent this from happening in the first place, make sure you've built things properly. This designated SMTP server (or better, servers) is not supposed to fail. Ever.

My point from the start was simply: If you want to use a local MTA, it's your call. If you don't have one, then you use SMTP. Mail::Mailer can do either, so why not just use that and offer configuration options to modify its behavior. Flexibility and portability, and you could even argue that using Mail::Mailer is even easier than using a pipe.

Secondly, if you are running a properly configured local MTA, you may not be able to find the program to interface with it, such as mailx, mail, sendmail in any of a dozen locations, but you can probably count on port 25 being open for business.

The assertions you make about why SMTP is not suitable would seem to be exaggerated. I am specifically talking about using a socket to transport a message to a local SMTP server which will then carry out the job of transmitting it to the final destination, including any retries, error handling, and so forth. The Perl script, once it has delivered the message, is free to move on. The buck has been passed. MX records, for example, don't even factor into the equation.

To a point, I agree: It's bad design to have a MUA deliver anywhere else than to a mailserver on the local network.