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

If you need to send mail, you better be using SMTP. Sure, you can use 'mail', but how can you tell if the system actually checks the mail queue. Is the mail daemon even running? Can you even assume it's going to be Sendmail? If you have your own little kingdom where certain things can be taken for granted, you can code accordingly. In general terms, though, such assumptions are risky.

Well, yes and no. No, you can't assume that the user is using sendmail, but yes, you should assume that he'll be running some kind of mailserver on the local machine, at least if he know what he is doing. Any other configuration will effectively break all kinds of redundancy and failrecovery built into SMTP.

A Perl script is non-persistent, like any other MUA (Mail User Agent). In other words, if the MUA can't deliver the mail it must fail, even though it might be possible to recover, according to SMTP rules. Many MUA won't even handle MX records, and will fail if the first mailserver in the MX records won't answer, or even worse, will fail if there are just MX records and no A/CNAME records, which is a rather common situation. This problem could be fixed, although there would be problems with the script blocking until the mail is actually delivered, which may take several minutes. Not a situation you wan't in a CGI script. And it still won't be able to handle queuing.

In my opinion, it's bad design to have a MUA deliver anywhere else than to a mailserver in the local machine. In worst case deliver to a local mailserver that can act as a relay, for example to handle firewall issues. It's extremely bad karma to deliver directly to remote mailserver from a MUA. It will only cause people to call you at 3AM claiming that mail doesn't work.

Replies are listed 'Best First'.
Re^4: Can I clean this up??
by tadman (Prior) on Jul 24, 2002 at 18:16 UTC
    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.
      Ok, I think we basically have the same view of it then: never let the MUA wander out on the Internet to deliver any emails. The way to accomplish a mail delivery to a mailserver on localhost or perhaps a nearby relay is a matter of taste, TMTOWTDI. Not all of us have the luxury to be concerned about whether the scripts run anywhere else than on the machine we wrote it for, we just need it to do it's job.