Re^N+1: Can I clean this up??

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.

Comment on Re^N+1: Can I clean this up?? Select or Download Code

Replies are listed 'Best First'.
Re: Can I clean this up?? by Abigail-II (Bishop) on Jul 24, 2002 at 13:46 UTC
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	[reply]
Re^2: Can I clean this up?? by tadman (Prior) on Jul 24, 2002 at 14:17 UTC
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.	[reply]
Re: Can I clean this up?? by Abigail-II (Bishop) on Jul 24, 2002 at 14:38 UTC
If you have a Web cluster with fifteen plus machines, are you really going to run an MTA on each one? If I have a web cluster with fifteen machines, running 15,000 programs, I rather have to deal with 15 MTAs than 15,000 - because every program that delivers mail is an MTA. Should each user in a company have an MTA on their local workstation just because. Yes, but that's irrelevant. Yes, networks can be unreliable, but then, if they're down, who's using your application anyway? Just because you can't reach your mail server because of network problems doesn't mean you are unreachable by someone else. Secondly, if your MTA is down, don't you think that's going to get fixed right away? Sure. But what if that's going to take a few hours? Even in a company where there's 7x24x365 support, it might take a while before the problem gets fixed. And yes, services can be overloaded, but what does this mean? It could mean the remote service is not accepting connections. What should your program do, drop the mail in the bitbucket? I rather have it queued and retried, it could be important. I'd rather not have my application lose it's mind just because I kill off the local MTA, or change it to something more secure than sendmail. As long as the replacement comes with a drop-in replacement for sendmail, there isn't a problem. I know qmail does. Abigail	[reply]