[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Default MTA for Fedora 7



On Sat, 2007-02-03 at 22:59 +0100, Thomas M Steenholdt wrote:
> "If we change the Default MTA in Fedora - Which should it be?"
> 
> I'm sure a lot of people will say Exim is great (i can't say, since i've 
> never worked with it). Others will yell for Postfix, towards which i'm 
> probably slightly biased, since that's what I currently use in most 
> places. I'm sure yet others will have other MTA's listed as their 
> favorite one.

Exim certainly does the job for me. None of the others do, as far as I
can tell. I'd be happy to be corrected on that count though, so I'll
elucidate...

I'd like to be able to do greylisting -- but not indiscriminately; I
want to greylist only mail which actually looks suspicious in some way,
rather than delaying perfectly genuine mail. Mail gets greylisted only
if it has some SpamAssassin points, or it's HTML, or it comes from a
machine with no reverse DNS or which is listed in a RBL, etc. That's a
few lines of Exim ACL code, demonstrated (the quick hack version) at
http://david.woodhou.se/eximconf/include/acl-greylist or perhaps more
sanely with jgarzik's better SQLite-based version which is available in
the same directory although I haven't yet switched over to it.

Is it possible to do that kind of thing in other MTAs? Without writing
or installing external software (or, perhaps, calling out to Exim? :)

I also need to be able to run virtual domains on the cluster of mail
machines I operate, but I don't really want to set up yet another
distributed database; I _already_ have DNS running, after all. I keep
aliases for virtual domains in TXT records, and I use Dynamic DNS so
that owners of a given virtual domain can update their forwarding
records with a trivial script round nsupdate. Currently, that's handled
just a few lines of Exim router configuration in the same directory as
the above (routers-dns-virtual). Can I do this in any of the other MTAs
on offer?

There's one or two more along those lines, like the trick described at
http://www.infradead.org/rpr.html to avoid getting bounces to mail I
didn't send. Last time I asked for help implementing these things in
postfix, all the people who originally expressed an interest just went
quiet after I explained what Exim is currently doing. The only coherent
response I got was from the person who said "Oh. I think I'll switch to
Exim".

Obviously, not everyone wants to do quite as much with the MTA as I do.
It's also important that it's secure, it's well-documented, and that the
configuration file is actually understandable by a human rather than
resembling line noise. Exim fulfils those criteria very well, and is a
good choice for the whole range of people from newbies to nutters like
myself.

Even Postfix would also be a better choice than sendmail -- that isn't
exactly a hard accolade to achieve. But it's much less versatile than
Exim and much less flexible in handling and filtering of incoming mail.
It might serve the newbies OK and those who really don't ask much of it,
but it's less useful for anyone who actually wants to get _serious_
about running a spam-resistant mail server these days.

If we ship a fully-fledged MTA as default, then Exim seems to make most
sense. On the other hand, there is a strong argument to be made for
shipping something a /usr/lib/sendmail which isn't capable of local
delivery, doesn't listen on a TCP socket, and which does _nothing_ but
deliver all mail to an external smarthost. You'd have a module in
firstboot which asks for both the login details for that smarthost and
the address to which (and from which) all root's mail should be sent.

Actually, Exim could capably fulfil that duty too, and when running
without local delivery can be be shipped in a mode where it doesn't even
have to be setuid root. If that's all we want from a default 'MTA' then
perhaps it's still overkill for the task though. But again, there's an
advantage to having a single tool which can provide the _full_ range of
functionality from low end to high end without the user ever having to
throw one tool away and start learning a new one from scratch because
they want to do something which the one they're currently using can't
handle.

-- 
dwmw2


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]