Re: exim or postfix
On Wed, Nov 10, 2004 at 11:09:47AM +0100, martin f krafft wrote:
> also sprach Craig Sanders <cas@taz.net.au> [2004.11.10.1014 +0100]:
> > > I agree. But exim can do it. And even though this is the LDA
> > > part of it, postfix also includes an LDA, which is just not up
> > > to speed.
> >
> > and postfix can do it too.
>
> No, it cannot, unless you use spamassassin as the LDA, which is
> deprecated.
spamassassin is not an LDA.
you use procmail or maildrop or something as the LDA, and that calls SA,
running as the user.
> Exim can use multiple sequential filters as part of the LDA (which are
> all run as the user).
that's a function of the LDA. procmail can do that, and so can maildrop.
i have no idea if postfix's local can do it because i've never actually
used it - i've always used procmail.
but it doesn't matter - that's the job of the LDA, not the MTA, and postfix
happens to have a modular design which lets you use any LDA you like.
> > postfix doesn't do it the same way as exim because postfix is not
> > a single monolithic process.
>
> Stop harping on that and respond to my points, if at all.
it wouldn't be necessary to "harpn on" if you didn't consistently miss the
obvious. postfix is not exim. stop insisting that it try to be exactly the
same.
i'll try expressing the concept in simpler language for you, and maybe you'll
understand:
you go into a take-away food shop and order a steak sandwich. when it arrives,
you complain that it doesn't taste like chicken. well, WTF did you expect?
it's steak, not chicken. if you had wanted chicken, you should have ordered
that.
similarly, if you want the exim behaviour and model, then install exim. if you
want postifx, then install postfix. but don't expect postfix to operate
exactly the same way as exim. to get postfix to do things, you take advantage
of the way that postfix works, not complain that it doesn't work exactly like
exim.
> Even a modular architecture can support filters as part of the LDA;
> Postfix does not.
again, you don't know what you are talking about.
> > > ... not manageable...
> >
> > of course not. but a) it works, and b) it doesn't have to be
> > "manageable", .forward files are not a system-wide setting, they
> > are a per user thing.
>
> So you suggest .forward files for a machine hosting about 1700
> Windows users?
no. try reading what i wrote.
> > if you want it to run for every user without each user having to
> > do custom configuration, then use procmail as the LDA and create
> > a rule in /etc/procmailrc. problem solved.
>
> If you object to exim because of its monolithic setuid nature, how
> can you possibly advocate procmail?
for the same reason that i can appreciate cats. i.e. it's irrelevant
to the question.
procmail is not an MTA. and postfix is not an LDA. they have different
jobs.
more to the point, whatever it's other faults, procmail is not "monolithic" -
it does one job, and it does it reasonably well. it fits the modular,
small-tools paradigm.
the fact that it is setuid root is not necessarily a problem. in fact, it's
unavoidable. if you're delivering mail to local users, at some point in the
process something has to run as root so that it can change UID to the user.
IMO, it's better to have that root or setuid process do just one job (LDA) and
revoke root privs as early as possible, than to do half a dozen different jobs
(monolithic MTA).
> Sure, it's run as the user. But it's a bloody performance hog. Try
> that with 1700 users and about 130 to 200 mails per minute, and you'll
> find that it does not work.
1. you want to run SpamAssassin for 1700 users and 200 mails/minute and
you're complaing that it's *procmail* that's the performance hog. i
think you need to resynchronise your brain with reality.
2. use maildrop instead if procmail's performance bothers you.
3. write your own mini LDA
3. the CPU time, memory, and I/O used by either procmail or maildrop (or
any LDA) is utterly insignificant compared to that used by SpamAssassin.
> > if you don't care about using per-user settings in SA, then just
> > use a content filter and you'll get SA checking on ALL mail, not
> > just on locally-delivered mail. again, problem solved. IMO, this
> > is the best way to do it.
>
> If you do SA on a system-wide basis, the auto-whitelisting feature
> is a problem,
true, it doens't work as nicely as it could otherwise.....but not very
important because auto-whitelisting isn't as useful as it sounds, anyway.
> and Bayesian filtering is basically useless.
nope, it's not. SA's bayesian filters works perfectly well when used as a
system-wide filter.
> > but if the question you are asking is "i want postfix to work
> > exactly the same as exim", then you'll never get an answer.
>
> I did not say so.
you have done so repeatedly.
> > *ALL* mail is both incoming AND outgoing.
>
> Which (sensible) MTA does not do it this way?
dunno, which is why it's so puzzling that people have difficulty understanding it.
i think it's because they insist on seeing mail sent through postfix from THEIR
point of view ("i sent it, therefore it's outgoing") rather than from the MTA's
point-of-view ("mail arrived from somewhere, queue it, deliver it to
somewhere").
> > > I am challenging you.
> >
> > challenging me to do what?
>
> To consider that, in fact, postfix is not the best for all situations.
it's theoretically possible, but hasn't happened in my experience.
i've never encountered a "desired" feature that is missing in postfix that
wasn't actually a serious misfeature or a misunderstanding of how postfix or
mail in general works.
> > repeat after me: an MTA is not an LDA. use the right tool for the
> > job.
>
> I believe I said before that I completely agree. This is not the issue
> being discussed.
it is. you keep on ignoring the distinction between the two tasks
and insisting that one do the job of the other. that "works" in the
monolithic MTA model of exim because there is one process that does both
tasks. it does not work in postfix because the tasks are divided up
amongst the appropriate processes.
now there are some advantages to monolithic MTAs, mostly to do with
availability of information at all parts of the mail-handling process.
similarly there are disadvantages, partly to do with availability
(leakage) of information at all parts of the mail-handling process, and
partly to do with resource consumption, and partly the potential for
security problems.
overall, a good modular design like postfix wins in terms of features,
performance, and security.
as with anything, there are tradeoffs. i haven't yet seen anything that
postfix trades off that is worth running anything else for.
craig
--
craig sanders <cas@taz.net.au> (part time cyborg)
Reply to: