Re: exim or postfix
On Wed, Nov 10, 2004 at 09:19:49AM +0100, martin f krafft wrote:
> also sprach Craig Sanders <cas@taz.net.au> [2004.11.10.0901 +0100]:
> > > Anyway, if you are so confident about postfix, then maybe you
> > > can teach me how to set up spamassassin to run under the local
> > > user's identity,
> >
> > procmail, maildrop or whatever local delivery agent you use can
> > run spamassassin. that's part of an LDA's job.
>
> 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.
just because it does it differently to the way exim does it, doesn't mean
that it can't do it.
postfix doesn't do it the same way as exim because postfix is not a single
monolithic process. it's a modular system of small tools that each do their
own job. expecting postfix to do it as a single monolithic setuid binary when
it doesn't even have one goes way beyond absurd, it's being wilfully blind.
> > even on the simplest level, a .forward file which pipes to SA is
> > executed under the UID of the user.
>
> ... 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.
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 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.
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. that problem can not be solved.
they are two different programs that work in quite different ways. the
conceptual model for mail processing is different. for instance, postfix has
no real notion of "incoming" or "outgoing" mail - more precisely, because it
queues everything, *ALL* mail is both incoming AND outgoing. it comes into the
queue (from any one of numerous different sources, smtp, uucp,
/usr/sbin/sendmail, etc) and eventually leaves the queue (again, via any one of
numerous different transports, smtp, uucp, local, procmail, maildrop, etc)
this particular feature confuses lots of newbies to postfix, because they
refuse to believe it. they persist in thinking in terms of incoming and
outgoing mail, when it is patently obvious that there is no such thing in
postfix.
> > before you say "but i want the MTA to do it", that's just you
> > thinking in terms of a monolithic MTA like exim.
>
> I am challenging you.
challenging me to do what?
i've already explained how insisting that the MTA itself does it is stupid.
you're trying to force a square peg into a round hole, when you'd be much
better just trying the round peg.
repeat after me: an MTA is not an LDA. use the right tool for the job.
> > > and how to route messages based on the sending address (for SPF
> > > reasons).
> >
> > no idea, never needed to do it. try the postfix-users archives.
>
> I cheated. It's in there and marked 'impossible'. Exim can do it.
i doubt if it's impossible. more likely, no-one cares enough about it
to bother figuring out how to do it.
> > if it's not straight-forward, i'll bet you could do it with
> > a policy server.
>
> A policy server has no decision on route destination.
try a tcp map then.
after doing a bit of reading, it doesn't sound like it's even a good idea.
Wietse hacked up a patch to transport tables to do this in 2002, and made the
following comments:
http://www.irbs.net/internet/postfix/0206/0132.html
: It's a pretty schizophrenic architecture, and I am not even sure it
: can be made to work.
:
: For example, sender-based routing breaks message bounces that his
: machine sends back to the internet. In fact, any mail with a local
: sender address will loop back to his machine, even though it has
: a remote recipient address. And he will never be able to receive
: mail from someone in a sender-routed domain, because that mail will
: always be routed to the ISP for that domain.
in short, the answer is "that's not a useful question". routing based on
solely the From: address is inherently broken.
if it is ever going to work, it needs to be done either with a policy server
or a tcp transport map, then you can use more than just the From: address to
determine routing (to do it reliably, you also need to know the client IP
and whether the client IP is in $mynetworks)
craig
--
craig sanders <cas@taz.net.au> (part time cyborg)
Reply to: