Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask

Which MTA is best to use with Perl....

by digiryde (Pilgrim)
on Jan 20, 2005 at 04:56 UTC ( #423601=perlquestion: print w/replies, xml ) Need Help??

digiryde has asked for the wisdom of the Perl Monks concerning the following question:

I am looking at upgrading/changing our MTA. I have my own personal biases about what is the best tool for the job, but I need to ask the community for other peoples' wisdom to help me step outside of my little box.

What I would like to know is what is your favorite MTA to use (with perl) and why. I just want to suck your brains of all the knowledge you have (but I will be quite happy with whatever you give me.) 8^)

If you do not mind, sharing what you do with your MTA and perl would be nice as well. It is amazing how much I learn I am not doing that I could be doing when I listen up!

I know there are other languages available that have their own toolkits for MTAs, but most of our codebase is already in perl and I have not seen the need to change it yet (which may or may not be another sign of me being stuck inside my box).

So, without further ado, I would like to here from all of you!

Added for clarity

The point of this question is to find out how other people use perl with MTAs. As far as favorite MTA with perl, same interface or not, not all MTAs will allow interaction with perl (or any other outside language) in exactly the same way. True, with time and patience, you can probably do the same thing with any MTA. Maybe an MTA allows hooks into it like Apache. Maybe there is an MTA with a perl interface like mod_perl? I have not heard of anything like this, but that does not mean it does not exist, or that someone is not trying to make it happen.

I am not looking for anything terribly specific, that would be limiting on what people may feel they can suggest. I am looking for what people have done with perl and an MTA, which MTA and why it is the one they have selected. it may not matter to most perl scripts which MTA you use, but it may matter to some.

rob_au has some good information as does Anon Monk Jan 20, 2005 at 04:39. I have primarily used one MTA in any depth since I started using MTAs, sendmail. I have dealt with MS's solution and found it horrible (YMMV) for many reasons, but awesome on a few others. Since I do not know everything, I learn more by asking, and that is what this is.

Some of the things we currently do include on the fly whitelists manageable through a webpage, temporary email addresses (like temp credit card numbers), and more. We tie this stuff all together with web based calendar, task planning, document control, workflow, voicemail, IM'ing, client notifications and more. I would point to a URL, but this stuff sits behind firewalls, and many of the pages contain private information of the companies (not to mention I do not have a release to do so.)

By providing commments here, you will also provide great material for anyone looking at using perl with MTAs, and that may be the most important thing that comes about.

Replies are listed 'Best First'.
Re: Which MTA is best to use with Perl....
by Anonymous Monk on Jan 20, 2005 at 09:39 UTC
    I fail to see the point of the question.

    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.
Re: Which MTA is best to use with Perl....
by maa (Pilgrim) on Jan 20, 2005 at 08:20 UTC

    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

Re: Which MTA is best to use with Perl....
by Anonymous Monk on Jan 20, 2005 at 14:01 UTC
    Although each MTA provides similar functionality, I'd still avoid sendmail because of security issues and the fact that sendmail configuration lacks sanity. Personally I'd recommend postfix due to the fact that it is well designed (modular), extendable, secure, and uses less resources then sendmail. Qmail is another good alternative.

    I'd say the thing which would be the biggest consideration would be what platform you plan on running it on. Solaris, Linux, BSD (possibly windows) all have slightly different considerations.
Re: Which MTA is best to use with Perl....
by castaway (Parson) on Jan 20, 2005 at 08:38 UTC
    I'm slightly confused here.. Each MTA should provide the same functionality (mostly), and as pointed out, several even provide sendmail-like interfaces. How do you 'use' your MTA 'with' perl? Did you mean just using Perl to send email, or to read it, or to write plugins for the MTA or ... ?

    Please give some examples..


      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 (

      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

      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'"

Re: Which MTA is best to use with Perl....
by mkirank (Chaplain) on Jan 20, 2005 at 10:41 UTC
    My favorite is Qmail
    you can use vpopmail-0.08 to add domains , users ,change password ...
    although I have not used this there is also Mail::Ezmlm
    If all that you want is to send mails from perl then it does not matter which MTA

      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).


Re: Which MTA is best to use with Perl....
by redhotpenguin (Deacon) on Jan 21, 2005 at 01:44 UTC
    I use Qpsmtpd in conjuction with qmail. You can write your own plugins in perl for authentication and other SMTP functions.

    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.

Re: Which MTA is best to use with Perl....
by castaway (Parson) on Jan 21, 2005 at 11:03 UTC
    Nope, still not a clue what you mean, after your addition of the "Clarity" section, sorry.

    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.


    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.

Re: Which MTA is best to use with Perl....
by nmerriweather (Friar) on Jan 21, 2005 at 21:35 UTC
    I primarily use exim -- . You can build it with an embedded perl interpreter, and do some neat things that you might enjoy. One of my machines runs postfix. I think its a great program too. Both distributions have comprehensive sendmail support -- 99% of things you do should work exactly the same, with little or no change.
Re: Which MTA is best to use with Perl....
by dave0 (Friar) on Jan 21, 2005 at 16:31 UTC
    Assuming you're willing to keep using Sendmail, another option is MIMEDefang ( ). Same sort of idea as Sendmail::PMilter -- giving you access to manipulate messages using Perl via Sendmail's milter interface -- but it's a different implementation.

    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 )

Exim, for the love of Perl
by nerfherder (Monk) on Jan 24, 2005 at 10:25 UTC
    Like nmerriwether said: Exim can be built with Perl embedded - you can expect some loss of performance, but check it out anyway.

    Maybe you already knew that about Exim, and your requirements are of a different nature. Supposing so, I'll get long-winded:

    Will your perl code be used as an MDA (delivering mail to the message store), or an MUA (composing and sending messages to the MTA, hopefully via SMTP)? Both?

    If your MTA is going to be bombarding your perl script(s) with messages which need to be delivered to the message store, the choices drop away quickly. This is mainly because spammers sometimes try to deliver alot of messages to alot of accounts (most of which don't exist) at one of the domains you're hosting. Even daemonized, your perl MDA code will consume resources erratically and excessively -- invoking or forking to try to deliver each message -- as soon as the rate of delivery starts erratically becoming excessive.

    You might then alter the MTA config to allow fewer simultaneous connections, throttle bandwidth, maximum messages from each IP, etc.... the result is that the perl MDA is no longer consuming all the resources, but overall delivery is slower and you start to get a nasty rash of support calls from users who suddenly can't get their 'zine out to their peeps.

    Postfix (easy), Sendmail (big book), qmail (holier than you), and Exim (no relation to the skin disease) each have strong points. However, only Exim can save you in the above scenario, because of the mysql support. You can configure Exim to check the MySQL database (because that's where you put the user account data, for recoverability and extensibility reasons when creating your MDA) to verify the legitimacy of the destination address to which each message is being sent, and drop the spammers' connections at the RCPT TO:, before delivery is attempted by your perl. Thus the bullet of perl's overhead is dodged.

    Of course, since Exim can deliver to maildir, you probably aren't writing an MDA in perl... nonetheless, Exim's routers configuration possibilities make it flexible -- like perl -- and it's developed by people wishing to make an MTA which does what sendmail is supposed to do. ;-) Also, with Exim you can integrate SpamAssassin -- the Bayesian filters are pretty slick.

    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.

    If you're planning to create a lasting -- dare we say timeless? -- application, I'd suggest looking at the development teams behind the MTA's. Who's going to be with you for the long haul?

    In my experience, Exim's flexibility and ease-of-configuration make it the right choice for the most common mailserver implementations, regardless of the scale. Exim also appears to be the only MTA which gives Perl consideration.
      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 :-)

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://423601]
Approved by Errto
Front-paged by mkirank
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (2)
As of 2022-08-08 00:29 GMT
Find Nodes?
    Voting Booth?

    No recent polls found