I've been a sysadmin, or have done sysadminny things on a wide range of (Unix) OSses: SunOS, Solaris, Linux (more distros than I care to remember), HP-UX, AIX, SGI, *BSD. I've used Perl on all of those platforms. I've worked with MTAs on all of these platforms.

I've never ever let my choice of MTA be influenced by Perl. I've never had a problem using an MTA with Perl -- any MTA which isn't tied in to the environment (such as sendmail, qmail, postfix, exim, ...) has a standard way of delivering email to it. Typically, a /usr/lib/sendmail dropin. Perl doesn't care with MTA you are using, and the MTA doesn't care mail was composed with Perl.

There are other factors that decide which MTA I use on a platform, including, but not limiting to:

• Personal preference.
• Ease of configuration.
• Tools available on the box (if there's no C compiler, and installing one takes a long time, I'm more inclined to leave the vendor supplied MTA).
• Intended use for the MTA. It makes quite a difference if the MTA is going to handle the mail of 40,000 users, or whether it's just got to mail the occasional report to an admin.
• Directly connected to the internet or not?
• The "special" email addresses: basically any address that does needs some other action than local delivery or forwarding.
• Licensing.
• Support. Not just for the MTA, but also for applications running on the box. If the box runs an important application which uses a certain MTA, and one loses support if the MTA is replaced, it's certainly a factor in deciding whether or not to replace the MTA.

I'm not sure it really matters to most perl scripts what MTA is actually being used since most of them provide a /usr/local/bin/sendmail be it a symlink or not. If the program uses sockets or whatever the MTA will surely implement SMTP/ESMTP on port 25.

The MTA generally appears to work in the same way regardless with a few differences regarding headers and re-writing of messages... but I'm sure you'll configure whatever you change to so that it will not appear to have changed at all (as far as the users can see).

QMail seems like a good choice to me.

HTH - Mark

Please give some examples..

C.

Whilst I cannot be sure as to the meaning of the original poster, I thought that it might be interesting for me to interject at this point with some detail about some work that I have done with Perl and the Sendmail MTA. Using the mail filter (milter) interface of Sendmail and building upon the Sendmail::PMilter module (which I have tertiarily been involved in the development of), I rebuilt the entire architecture of the Bluebottle challenge-response mail service (http://www.bluebottle.com).

This service, when I first became involved with Bluebottle in early 2002, was built in a queue-processing fashion, employing a custom local mailer with Sendmail to dump inbound mail into a queue processing directory, from whence a daemon process would pick up the mail and process it according to user delivery preferences. This approach however proved to be quite limiting with the service eventually being crushed under the weight of a joe-job spam attack necessitating a better through-put time for mail messages.

After spending some time on analysing system bottle-necks and identifying potential system improvements, I set about rebuilding a version of the system which employed the milter interface of Sendmail - This interface allows for external mail filter code to access and respond to elements of the SMTP transaction as they occur and thereby provided the perfect level upon which to enact user delivery preferences. Further information about the milter interface can be found at http://www.milter.org/milter_api/index.html.

Relaunching the challenge-response component of the Bluebottle mail service employing the milter interface for mail message inspection and application of user preferences in January 2004 led to phenomenon growth of the service, which the mail service, with the revised system architecture scaled with most admirably, grew from around 8,000 users at the start of year to almost 80,000 users at the years end. The total number of messages handled by this revised mail architecture is estimated to be between 35 to 45 million messages.

This is how I have used Perl with a MTA (Sendmail) ...

 

perl -le "print unpack'N', pack'B32', '00000000000000000000001000000000'"

Be careful using qmail. It is viewed as hostile by its behavior given multiple recipients (split into multiple messages and parallelize the output). It is also viewed by some as spam support because of its accept then bounce method of handling incoming mail.

At home I have it configured to drop anything not recognized into a spam mailbox, only allow certain source addresses to send, I ignore the parallelize issue (I don't have any mail lists that it would effect), and I give myself a little reaction time by storing things in an outgoing serialmail queue for 5 minutes (giving my outbound queue time to respond to a virus infestation or the like).

--MidLifeXis

It's a little more resource intensive than C based smtp servers, but I was able to alter one of the existing auth plugins for the way I had vopmail installed and customize my setup quickly. It's easy to customize, and easy to setup.

None of those things you list in that last section, whitelists, IMing, calenders and so on, have anything to do with Transporting email. MTA = Mail Transport Agent, this is just a subset of what much mail server software does.

You appear to be looking for multi-talented mail server software, and not just an MTA. But I still haven't a clue where Perl comes into it at all.

C.

I use exim to transfer my mail, fetchmail, perl and spamassassin to fetch and filter it, Net::OSCAR to IM, a PSA to calendar.. etc...

Sorry if I have been too vague or unclear.

Try thinking about how to tie all those tools together. That is what we are doing.

You are right about multi-talented servers. We have the code that makes an MTA do more than be just an MTA. However, we are not looking for a multi-talented MTA. We just want a good solid, extensible MTA. To a point, all MTAs are extensible as are all web servers, but certain web servers outshine others in that area. I am not certain if any MTAs outshine other MTAs in this way as well. It is starting to sound like there are four primarily used MTAs that fit the bill. Sendmail is something that keeps getting dogged for security (which is why we are looking elsewhere as well).

Using Perl in Apache is not the same thing as using perl in IIS or other web servers. I was unsure of any (if any) difference in MTAs in the same respect. It seems that there are few differences and those differences are less important than MTA functionality, speed, security and manageability. Which to me says basically, forget about any considerations in relation to how perl might be *plugged* into an MTA or how an MTA might call out to perl, just focus on the MTA as an MTA only and make sure certain minimum requirement for externalizing functionality can be met. Correct me if I am wrong.

And, thanks for your input anyway. Sometimes when I have not had time to sit down and create a presentation I do not have the clearest message. Good habit to take a few hours first.

It also provides a few things over and above the Milter interface, such as hooks for backending Sendmail 8.13's SOCKETMAP option, so you can implement your virtusertable, mailertable, genericstable, etc, as arbitrary Perl code. This should make implementing throwaway addresses, making arbitrary mail routing decisions, etc, a simple matter.

( disclaimer: I work for the author of MIMEDefang )

I agree with some of the other replies that most people, if they're composing and sending email with perl, use SMTP so that it can work with any MTA (unless you already wanted to limit yourself to a certain MTA), so the MUA discussion is moot.

I don't think this is good advice. If you're going to use SMTP, you should also be willing to deal with all sorts of problems, like the MTA you're connecting to being down, (temporarely) refusing connection, or otherwise not willing to accept your mail right now. Which means you have to do build the "keep and retry" mechanism yourself.

I rather call /usr/lib/sendmail (whether that's from sendmail, or a drop-in replacement from another MTA) that will place my mail in the appropriate queue, then connect to port 25 and just pray my call gets accepted.

On the other hand, using SMTP for sending makes it downright convenient to return an informative error message to the user (and logs, hopefully) if the connection is refused or relaying denied.

Using a "keep and retry" mechanism could mislead the user into thinking that the mail has been sent and presumed delivered, when in fact it hasn't. If you're in some sort of corporate environment, warm up your support ear! ;-)

Thank you for the very thoughtful reply. This is most helpful and tends to agree with a majority of the feedback I am getting (not just here.)

However, only Exim can save you in the above scenario,

Well, not only Exim can save you. Sendmail can do all of this too. User validity checks, spam filtering, dropping after RCPT TO:, are all supported either natively, or in ways that require some minimal Perl scripting under MIMEDefang or Sendmail::PMilter.

If you're using MIMEDefang you can run your Perl code preforked in a separate process and multiplex across them -- no need to have a 1:1 mapping of incoming SMTP connects to Perl processes. I think Sendmail::PMilter can do this, too, but I've not had the opportunity to look at it in detail.

Exim may be a good MTA, but it's not the only choice for doing this sort of stuff.

Good point - I should specify that in the particular case that I was thinking of, Exim was a drop-in replacement for sendmail, and the mysql check was easily configured. In that instance, BTW, the Perl was daemonized.

Exim is not the only choice, but like perl, makes easy things easy and hard things possible. This is why I think it's a good match for Perl :-)