Exim, for the love of Perl

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.

Comment on Exim, for the love of Perl

Replies are listed 'Best First'.
Re: Exim, for the love of Perl by Anonymous Monk on Jan 24, 2005 at 15:51 UTC
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.	[reply]
Re^2: Exim, for the love of Perl by nerfherder (Monk) on Jan 24, 2005 at 18:53 UTC
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! ;-)	[reply]
Re^3: Exim, for the love of Perl by Anonymous Monk on Jan 25, 2005 at 09:36 UTC
I assume your SMTP solution is going to deliver all mail to a "smart host", and isn't going to do MX resolving itself, and deliver the mail to one of the servers returned. In that case, if you get a "relaying denied" error, you have a serious problem - it basically means all you may be able to do send mail to local users. Your error message should have been "this solution is never ever going to work". If the user gets a "connection refused" message, he'll be pissed. He doesn't want a "connection refused" message from an MTA. He wants the MTA to queue the mail and retry again. That's the task of the MTA - not the task of the user. This problem was solved more than 30 years ago. If you just fill in a correct return address errors, not only the error message will be send to the user, the mail as sent will be returned as well, even if there's a problem (like 'relaying denied') further down the line.	[reply]
Re: Exim, for the love of Perl by digiryde (Pilgrim) on Jan 24, 2005 at 15:43 UTC
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.)	[reply]
Other options by dave0 (Friar) on Jan 24, 2005 at 17:25 UTC
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.	[reply]
Re: Other options by nerfherder (Monk) on Jan 24, 2005 at 18:44 UTC
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 :-)	[reply]