On Wed, Nov 10, 2004 at 09:19:49AM +0100, martin f krafft wrote: > also sprach Craig Sanders <[EMAIL PROTECTED]> [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 <[EMAIL PROTECTED]> (part time cyborg) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]