Default MTA for Fedora 7

[nodata]

Am Montag, den 05.02.2007, 11:25 +0000 schrieb 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
> 

Are we really changing the default MTA just because of a cock-up in
resolving dependencies?