Default MTA for Fedora 7

[David Woodhouse]

On Sun, 2007-02-04 at 22:21 -0300, Horst H. von Brand wrote:
> > 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 note you make no pretence at claiming Postfix can do these things;
only arguments that I shouldn't _want_ to. This despite the fact that
they're only _examples_ of the kind of thing people do with mail
servers, and the fact that these are the reasons people come to me and
_ask_ for an account on my systems.

But despite the fact that it's a complete digression and you seem to
have already conceded the point I was making, it's a subject which
interests me so I'll play along...

> > 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.
> 
> The /point/ in greylisting is not to expend any effort on mail that comes
> from suspect origins.

Resources are cheap, right up to the point the mail is accepted and
delivered to my mailbox. At _that_ point I start to resent it.

The point in greylisting is very simple: it's to check that the mail is
coming from a 'proper' mail server which actually does retry mail when
you give a temporary rejection. Some people naïvely delay all incoming
mail (and some outgoing mail too, if they reject at RCPT TO and the
recipient uses callouts) by greylisting indiscriminately. I prefer mail
to be fast in the common case, so I like to delay _only_ mail which
actually looks suspicious in some way, and I prefer _never_ to greylist
mail from a host (IP address) which was already observed to retry in the
past.

>  Stopping mail from an RBLed origin or no reverse DNS
> (or non-matching reverse DNS) are other, independent anti-spam
> measures. Sure, they can be integrated into greylisting (milter-greylist
> for sendmail integrates RBLs), but they are still independent. So is
> spamassassin's score, etc.

You may have been trained to treat them independently because that's all
you're used to being able to do, but personally I don't want to be
limited in that fashion. I _want_ to be able to combine SA score with
other reasons for considering a mail 'suspicious', and use that as a
trigger for stuff like greylisting.

For someone else, I used a similar set of criteria to trigger Exim's
'fakereject' feature which allows one to give a 550 rejection but still
actually accept the message. It was configured to 'freeze' the mail on
the queue, and give a URL with the rejection message as well as an
explanation. When the recipient of the bounce went to that URL they
would get a far more coherent explanation of the offences which caused
the mail to be 'rejected', and could complete a captcha to verify that
the mail _is_ genuine and have it unfrozen for delivery.

That's not something I would normally have done; I prefer just to bounce
and let people fix their sending mail servers if they're broken enough
to get rejected. But the client in this case was adamant that this was
what they wanted, and it allows them to peruse the frozen spam on the
queue for false positives. It's better than accepting it and putting it
into a spam folder, because that way the recipient wouldn't get a
bounce, so they might think their mail is actually going to be read.

> > Is it possible to do that kind of thing in other MTAs? Without writing
> > or installing external software (or, perhaps, calling out to Exim? :)
> 
> Why is "installing external software" (specially if it is written to
> standardized interfaces defined exactly for such uses) off-limits?

I suppose it isn't off-limits if it's versatile enough to be tweaked to
users' requirements and if it's shipped in Fedora.

Standardised interfaces are fine, again as long as they're versatile
enough. For a long time, Exim had SpamAssassin support (sa-exim) which
used a similar interface -- running on the mail just after DATA and
giving a decision about whether to accept it or not. That wasn't good
enough for folks who were used to better things, and it was very quickly
replaced with full content scanning support within the ACL language. We
finally dropped sa-exim from the Fedora packages in FE6, after keeping
it around for a long time for compatibility.

http://fedora.redhat.com/docs/release-notes/fc6/en_US/sn-Extras.html#id2916368

> > 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,
> 
> Lousy missuse of DNS, if you ask me.

DNS is a distributed database which automatically synchronises between
all the machines in the cluster. It also allows me to give 'keys' to
certain users in order that they can modify certain subdomains as they
desire. It was already running; I didn't have to set up a new database.

Yes, it's 'abuse of DNS'. It's also _extremely_ convenient. If I want
bondage and discipline I'll go back to programming in Modula-3.

> >                                             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?
> 
> Why does an MTA have to bend over to such abuse of DNS?

An MTA should be flexible enough that the admin can do what he/she need
to do with with it. Because of the way SMTP works, especially the need
to avoid sending bounces _after_ accepting mail, stuff _does_ need to be
pushed down into the MTA to be done at SMTP time. And in the current
environment, you have to get more and more involved to stay ahead of the
game. I've just highlighted a few of the things I do with it; that's
all. It wasn't an exhaustive list; just a glimpse of how Exim makes the
mail system work much better for _me_ (and my users) than any other MTA
could manage.

OK, so returning to the original topic... now I've got two kinds of
responses. First the "oh, I think I'll switch to Exim" and now the
somewhat more disingenuous "you shouldn't want to do that anyway" :)

-- 
dwmw2