http://qs321.pair.com?node_id=184810


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

RedHat does not install mailx by default
So, you use mail, or whatever RedHat installs by default. I would only use Mail::Mailer for portability reasons, but that wasn't a reason that was mentioned.
And don't forget, system() calls aren't exactly free either.

Your point being? Have you ever looked into the works of Mail::Mailer? For Unix like systems, the _default_ is to use an external mail program like mail or mailx. And guess how that's invoked? By doing a fork & exec, just like you would be doing with:

open my $fh => "| mailx args" or die;
which my preferred way of calling mailx.
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.
Mail::Mailer isn't going to use smtp by default on a Unix system either. If it finds an executable mail or mailx, it will use that, regardless whether there's a mail daemon running or not.

As for using SMTP, I think you don't realize what you are saying. That also means you have to queue, do DNS lookups, and retry (typical up to 5 days) if there's a non-permanent failure in the delivery. Most scripts want to be finished long before email gets delivered.

Abigail

Replies are listed 'Best First'.
Re^N+1: Can I clean this up??
by tadman (Prior) on Jul 24, 2002 at 13:38 UTC
    Actually, portability was one of my primary concerns in making the case for using the module(s). If you have, for example, a Web server farm, are you going to run a mail daemon on each of those boxes? For security reasons alone, probably not. Sure, you can use mail, but with no mail daemon, it's going to look like you sent the message, but in fact, you just created a file on disk that is never going to be processed.

    This is what I use:
    my $mailer = Mail::Mailer->new('smtp', Server => $my_local_smtp);
    This just opens a connection to the local SMTP server, whatever that is, and drops off the message to be sent. The retrying, error handling, and so forth, they are taken care of by that process, wherever it may be. If it takes a significant amount of time to resolve the DNS for your local mail server, you've got to wonder what the heck is wrong with your ISP. That queueing and retrying is done by the SMTP server, not you. Your script can move on the instant you're finished writing to the socket, and that should't take very long at all.

    One of the things you can count on is that there is going to be a suitable SMTP-type service at your provider, if you don't already run one yourself. You can't assume with the same degree of confidence that everyone's going to have a working 'mail' or 'mailx'. Just because it's there doesn't mean it's plugged in.
      Having worked with Unix systems for almost 20 years, many of them as an admin, I rather rely on the existance of a mailer program on the system, than on a remote service being available. Whether that's my "provider" or not. (The world isn't all web you know). Networks are unreliable. Machines aren't 100% up. Services can be overloaded.

      And then there's of course maintability. I rather change the configuration file of my MTA once if the smarthost changes, then hundreds of itty bitty programs that think they're smart contacting the smarthost themselves.

      Abigail

        I understand your point completely. Five years ago I would agree, but these days, things aren't necessarily the same.

        If you have a Web cluster with fifteen plus machines, are you really going to run an MTA on each one? It would likely be a lot easier to use the designated MTA and go from there. Should each user in a company have an MTA on their local workstation just because?

        Yes, networks can be unreliable, but then, if they're down, who's using your application anyway? Secondly, if your MTA is down, don't you think that's going to get fixed right away? These things are usually important. And yes, services can be overloaded, but what does this mean?

        I'd rather not have to rewrite my application just because I kill off the local MTA, or change it to something more secure than sendmail.

        I don't mean to badger. We all have our preferences. Given that, I reiterate: Since you can use Mail::Mailer in either SMTP or 'mailx'-type mode, it's probably better to use that than to just assume 'mailx' is going to work. You can, after all, use Mail::Mailer in a variety of ways, but 'mailx' only works in one, possibly broken, way.