Re: What stripe size for mail server?
On Wednesday 10 November 2004 23.29, Chris Wagner wrote: It's 'you' - three letters :-) > If u still need RAID 5 then I would make the > stripe size equal to average file size / number of data disks up to no > more than 32KB stripe. To optimize random small reads, it's best if a read can be satisfied by touching only one disk, so large stripe sizes should be better - with your avg file size, 8k or 16k stripes should be fine; even 4k probably wouldn't hurt much. Disclaimer, however: this is based on reasoning, not experience. cheers -- vbi -- Oops -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What stripe size for mail server?
On Wed, Nov 10, 2004 at 05:29:37PM -0500, Chris Wagner wrote: > I would say that RAID 5 is probably overkill for a mail queue. It's not the mail queue. Its the mail store (maildirs). We have no problems with mail queue performance so far. > Unless ur > mail queue is running hundreds of gigabytes and overloading a single disk, The store is over 60 GB now, and still growing. Will probably reach over 100 GB in a few months. > a > normal single hard drive is sufficient. Definitely not sufficient for us :) > Based on ur graph it looks like ur > queue is under half a gig. What makes you think so? I did mention that those data were just from a random sample. > If you want redundancy for the mail queue then a > RAID 1 (mirroring) will give u everything u need. Mirroring seems a little bit to expensive for us. But we will certainly consider that if someone points me to a comparison that strongly favors mirroring over RAID5 for a similar setup. Simply saying that > RAID 5 is for extremely > high usage like large file servers and stuff. is not enough to make the decision, unfortunately. > Adding RAM to beef up the > file cache can give u a significant speedup (Ur entire queue can be RAM > cache). Unfortunately adding more system RAM to that machine is not an option (at least for now). We are going to add more RAM to the controller, though. > If u still need RAID 5 then I would make the stripe size equal to > average file size / number of data disks up to no more than 32KB stripe. Since avg file size would be something around 2500 bytes, and we have 5 disks, that would give us a 500 byte stripe. I don't think that is even possible. Marcin -- Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What stripe size for mail server?
I would say that RAID 5 is probably overkill for a mail queue. Unless ur mail queue is running hundreds of gigabytes and overloading a single disk, a normal single hard drive is sufficient. Based on ur graph it looks like ur queue is under half a gig. If you want redundancy for the mail queue then a RAID 1 (mirroring) will give u everything u need. RAID 5 is for extremely high usage like large file servers and stuff. Adding RAM to beef up the file cache can give u a significant speedup (Ur entire queue can be RAM cache). If u still need RAID 5 then I would make the stripe size equal to average file size / number of data disks up to no more than 32KB stripe. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
..do I lose _anything_ going from apache-1.3.3x to apache-2.0.5x ?
Hi, ..seeing recent the exim vs postfix thread, and having both apache-1.3.3x and apache-2.0.5x available on a box, is obviously beyond overkill, it's pointless. ;-) So I'm choosing one. Figuring out "which one?" has asking myself a lot of questions. ..more importantly, do I lose _anything_ worthwhile such as performance, functionality or "memory foot print acreage", going from apache-1.3.3x to apache-2.0.5x ? I can see that writing code to do the same things in apache-2.0.5x, will be different from how is is done in apache-1.3.3x. What I don't see is how that bugs me. The one thing that leans me towards the newer of the 2, is I suspect it will survive 1.3 by as much as 1.3 survives what came before apache-0.9.x or whatever it was. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
What stripe size for mail server?
Hi! http://mail1.expro.pl/~porridge/dist.png shows the distribution of file sizes on our mail server (actually just the partition holding maildirs). The sample was 80 files. "-512" means zero-byte files. "0" means the files whose sizes are greater than zero, but less than 512. "512": greater than 512, but less than 1024 etc The green line shows the distribution of messages in Maildir/(new|cur|tmp). The red one also includes the number of other files (mostly sqwebmail index and preferences files, .qmail, etc). We probably need to optimize on reads, since currently there are 16 times more block reads than block writes on that partition. Given that, what would be the best stripe size for (hardware) RAID 5 (currently 5 disks)? I read somewhere that large stripe sizes are good for small random reads, but what is your experience? Or maybe RAID 5 is totally unreasonable for such usage? regards, Marcin -- Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Value of backup MX
On Wed, 10 Nov 2004, Andreas Barth wrote: > * Robert Brockway ([EMAIL PROTECTED]) [041110 20:20]: > > Oh you mean reject mail for unknown recipients rather than bounce the > > mail[1]. Ok, I can see why you are suggesting it but it is an RFC > > violation. > > Why should it be a RFC violation to reject mail for unknown recipients > with 550? If a remote client sends me a mail adress I don't accept on a > permanent reason, I should give a 5xx error code. My reading of the original poster was that he was suggesting dropping the mail on the floor rather than returning a 5xx (which would be a bounce). Reviewing it, he did mention rejecting with a 5xx, so I withdraw the statement. Cheers, Rob -- Robert Brockway B.Sc. Senior Technical Consultant, OpenTrend Solutions Ltd. Phone: 416-669-3073, Email: [EMAIL PROTECTED], http://www.opentrend.net OpenTrend Solutions: Reliable, secure solutions to real world problems. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Value of backup MX
On Wed, Nov 10, 2004 at 02:18:50PM -0500, Robert Brockway wrote: > On Wed, 10 Nov 2004, Craig Sanders wrote: > > if you do have a backup MX, then you need to have the same anti-spam > > & anti-virus rules as on your primary server AND (most important!) it > > needs to have a list of valid recipients, so that it can 5xx reject > > mail for unknown users rather than accept and bounce them (known as > > "backscatter"). > > Oh you mean reject mail for unknown recipients rather than bounce the > mail[1]. Ok, I can see why you are suggesting it but it is an RFC > violation. so are most anti-spam and anti-virus methods. theory is fine, but pragmatic reality sometimes dictates divergence from an idealist theory. > Not that I'm necessary saying not to do it but one must walk > towards RFC violations fully aware of the fact (for the benefit of those > reading along at home). true. you've got to know the rules before you break them. > [1] I thought you were suggesting the MTA should drop mail from unknown > senders - a type of brutal white list :) not at all. that wouldn't make much sense, and it wouldn't be very useful. craig -- craig sanders <[EMAIL PROTECTED]> (part time cyborg) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Value of backup MX
On Wed, Nov 10, 2004 at 02:10:18PM -0500, Robert Brockway wrote: > On Wed, 10 Nov 2004, Craig Sanders wrote: > > > backup MX is obsolete these days, very few people need it (most of > > This does seem to be a prevailing opinion but I think backup MXs are > valuable now for the same reason they always were - outages happen. We > have no way of knowing how long a remote MTA will continue attempting to > resend, even if it is following the rules of SMTP. I do not want to lose > mail because a remote admin can't afford to hold mail for very long > (assuming a major issue like a hardware fault). > > I do fully support the idea of the backup MXs having the same anti-spam > capabilities as the primary (rsync over ssh can do wonders) if you have full administrative control over your own backup MX, *AND* if you maintain the list of valid relay recipients, then it is perfectly OK to have a backup MX. you probably won't benefit from it anywhere near as much as you think you will (and it will be constantly bombarded by spammers), but it won't cause any problems for anyone else. > Peered MXs (eg, 2 x MX 10) and dynamic backups which don't just queue mail > but continue to deliver when the primary is down are even better. that's not backup MX, that's load-balancing. a different kettle of fish. in order to work at all, they *MUST* have a list of valid recipients. again, not a problem AND, unlike backup MX, you will get significant benefits from running a load-balanced mail setup if you have the mail volume to warrant it. > > those who *think* they do are just running on ancient & obsolete > > gossip/"common sense" from the days when backup MXes were useful). > > almost all mail these days is delivered by SMTP, and all real SMTP > > MXs are hardly useful for mail that is not travelling over SMTP :) true. however, very little mail travels over alternative transports these days. except for a few weirdoes like myself who set up uucp over tcp instead of the brain-damaged kludge of multi-drop POP mailboxes, almost nobody does anything but SMTP. and in any case, when using uucp, you generally don't set up the uucp host as a secondary MX. you set it up as the primary MX, and give it a transport table entry to route mail for the destination domain via uucp. > > servers(*) will retry delivery. this works perfectly well without a > > backup MX, and in fact works BETTER without a backup MX. > > How does it work _better_ without a backup MX? 1. it's not clogged up with undeliverable spam bounces 2. it's not clogged up with backscatter 3. the original sender (or their sysadmin) can tell that their mail hasn't been delivered yet, instead of wondering why they haven't got a reply to their important mail that has been waiting in a queue on the backup MX for 3+ days. > > if you do have a backup MX, then you need to have the same anti-spam > > & anti-virus rules as on your primary server AND (most important!) it > > I agree with this (as noted above) > > > needs to have a list of valid recipients, so that it can 5xx reject > > mail for unknown users rather than accept and bounce them (known as > > I disagree with this. I'd sooner not have a backup than use this > strategy. Sounds like a good way to lose new customers. a list of valid relay recipients is essential. without it, you generate vast quantities of backscatter. if you do that, you are contributing to the spam & virus problem. sooner or later, someone will get pissed off enough by backscatter to create a backscatter DNSRBL that lists sites which generate large amounts of backscatter (and sites that send out those annoying bogus virus notifications from their AV scanners). as with open-relay and open-proxy and spam-source DNSRBLs, this can only be a good thing because it will force lazy and ignorant system admins to do the Right Thing if they want their legit mail to be delivered. > > btw, backscatter also causes problems for you and your server. many > > of the spam/virus bounces are from undeliverable return addresses, > > so they end up clogging your mail queue for days and slowing the > > entire system down. > > Only if the queue is really huge, honestly. yes, and this happens in very short time. craig -- craig sanders <[EMAIL PROTECTED]> (part time cyborg) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Value of backup MX
* Robert Brockway ([EMAIL PROTECTED]) [041110 20:20]: > Oh you mean reject mail for unknown recipients rather than bounce the > mail[1]. Ok, I can see why you are suggesting it but it is an RFC > violation. Why should it be a RFC violation to reject mail for unknown recipients with 550? If a remote client sends me a mail adress I don't accept on a permanent reason, I should give a 5xx error code. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Value of backup MX
On Wed, 10 Nov 2004, Craig Sanders wrote: > if you do have a backup MX, then you need to have the same anti-spam > & anti-virus rules as on your primary server AND (most important!) it > needs to have a list of valid recipients, so that it can 5xx reject > mail for unknown users rather than accept and bounce them (known as > "backscatter"). Oh you mean reject mail for unknown recipients rather than bounce the mail[1]. Ok, I can see why you are suggesting it but it is an RFC violation. Not that I'm necessary saying not to do it but one must walk towards RFC violations fully aware of the fact (for the benefit of those reading along at home). [1] I thought you were suggesting the MTA should drop mail from unknown senders - a type of brutal white list :) Rob -- Robert Brockway B.Sc. Senior Technical Consultant, OpenTrend Solutions Ltd. Phone: 416-669-3073, Email: [EMAIL PROTECTED], http://www.opentrend.net OpenTrend Solutions: Reliable, secure solutions to real world problems. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Value of backup MX
On Wed, 10 Nov 2004, Craig Sanders wrote: > backup MX is obsolete these days, very few people need it (most of This does seem to be a prevailing opinion but I think backup MXs are valuable now for the same reason they always were - outages happen. We have no way of knowing how long a remote MTA will continue attempting to resend, even if it is following the rules of SMTP. I do not want to lose mail because a remote admin can't afford to hold mail for very long (assuming a major issue like a hardware fault). I do fully support the idea of the backup MXs having the same anti-spam capabilities as the primary (rsync over ssh can do wonders) Peered MXs (eg, 2 x MX 10) and dynamic backups which don't just queue mail but continue to deliver when the primary is down are even better. > those who *think* they do are just running on ancient & obsolete > gossip/"common sense" from the days when backup MXes were useful). > almost all mail these days is delivered by SMTP, and all real SMTP MXs are hardly useful for mail that is not travelling over SMTP :) > servers(*) will retry delivery. this works perfectly well without a > backup MX, and in fact works BETTER without a backup MX. How does it work _better_ without a backup MX? > if you do have a backup MX, then you need to have the same anti-spam > & anti-virus rules as on your primary server AND (most important!) it I agree with this (as noted above) > needs to have a list of valid recipients, so that it can 5xx reject > mail for unknown users rather than accept and bounce them (known as I disagree with this. I'd sooner not have a backup than use this strategy. Sounds like a good way to lose new customers. > btw, backscatter also causes problems for you and your server. many of the > spam/virus bounces are from undeliverable return addresses, so they end up > clogging your mail queue for days and slowing the entire system down. Only if the queue is really huge, honestly. > having a backup MX that you don't control is a very bad idea. Yes. Spam aside you are placing much trust in the admins of the backup MX if you do this. > if you have one, get rid of it ASAP. One opinion :) I happen to have a different opinion. Rob -- Robert Brockway B.Sc. Senior Technical Consultant, OpenTrend Solutions Ltd. Phone: 416-669-3073, Email: [EMAIL PROTECTED], http://www.opentrend.net OpenTrend Solutions: Reliable, secure solutions to real world problems. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
This Is a Test Mail
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: exim or postfix
On Wed, Nov 10, 2004 at 11:09:47AM +0100, martin f krafft wrote: > also sprach Craig Sanders <[EMAIL PROTECTED]> [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
Re: Limiting User Commands
Michael Graham wrote: Ben Hutchings wrote: Christopher Swingley wrote: Change the ownership and permissions on their .bash_profile and .bashrc to root:root 644: -rw-r--r--1 root root 420 Sep 21 13:05 .bash_profile -rw-r--r--1 root root 746 Sep 21 13:05 .bashrc You should also add the sticky bit to their directory (chmod +t) to prevent them from replacing these files. I feel the need to learn something new today. How could the user replace the root owned files in a directory that they own? By renaming or unlinking them. Linux treats this as an operation on the directory, not the file, so it's controlled by the directory's permissions. Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: exim or postfix
also sprach Craig Sanders <[EMAIL PROTECTED]> [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. Exim can use multiple sequential filters as part of the LDA (which are all run as the user). > 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. Even a modular architecture can support filters as part of the LDA; Postfix does not. > > ... 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? > 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? 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. > 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, and Bayesian filtering is basically useless. > 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. > *ALL* mail is both incoming AND outgoing. Which (sensible) MTA does not do it this way? > > I am challenging you. > > challenging me to do what? To consider that, in fact, postfix is not the best for all situations. > 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. > > I cheated. It's in there and marked 'impossible'. Exim can do > > it. > > i doubt if it's impossible. You are making a fool of yourself. > in short, the answer is "that's not a useful question". routing > based on solely the From: address is inherently broken. Did I say that the From address was the only feature to base routing on? Also you (and Wietse) are failing to see the value for store-and-forward relays. Anyway, this is pointless. You just read my last post on the issue. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: exim or postfix
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]
Re: exim or postfix
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. > even on the simplest level, a .forward file which pipes to SA is > executed under the UID of the user. ... not manageable... > 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. My postfix does not do said things, and I sure well know why. > > 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. > 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. Anyway, I can't believe I am arguing against the product that I embrace the most. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, user, and author `. `'` `- Debian - when you have better things to do than fixing a system Invalid/expired PGP subkeys? Use subkeys.pgp.net as keyserver! signature.asc Description: Digital signature
Re: exim or postfix
On Wed, Nov 10, 2004 at 08:21:14AM +0100, martin f krafft wrote: > also sprach Craig Sanders <[EMAIL PROTECTED]> [2004.11.10.0010 +0100]: > > > There have been some very simple things that I've needed to find > > > solutions to with postfix in the past which I ended up having to > > > do with procmail that I can now deal with in ~ 3 lines in the exim > > > config. > > > > my guess is that you just know exim better than postfix, so things > > that an experienced postfix user would find easy aren't as easy for > > you as just using exim. > > > > all of the things you listed as benefits of exim, my first thought > > was "but postfix does that (and it does it better :)". > > You are not seriously arguing this, right? yes. > The exim routers are far beyond what postfix can do. not in my experience. > IMHO, they are far beyond the job of an MTA, so it's more a plus for > exim than a minus for postfix. show me anything that you think can't be done in postfix and i'll probably tell you how it can be done. in my experience, the only people who say "postfix can't do that" are people who don't actually know postfix, or who are so caught up in the way that you do it in some other MTA that it never occurs to them to investigate how you might do it in something else such as postfix. every MTA has a different conceptual model for how mail is handled. if someone insists on applying exim models to postfix (or vice-versa) then they're not going to be very successful. > 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. even on the simplest level, a .forward file which pipes to SA is executed under the UID of the user. before you say "but i want the MTA to do it", that's just you thinking in terms of a monolithic MTA like exim. anyone who thinks in postfix terms would be horrified by the idea of having a huge setuid binary try to do everything. postfix consists of several small, modular parts. each one does it's job, and each one is replacable. postfix can hand off local delivery to it's own LDA called "local" or it can hand off local delivery to procmail or maildrop or cyrus or whatever. you can even have some local mail delivered by local and some by procmail etc. as far as postfix is concerned, it doesn't matter - as long as they fulfil the function of a local delivery agent. > 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. if it's not straight-forward, i'll bet you could do it with a policy server. > > ps: i've used pretty nearly all of the free software MTAs (and > > some not-so-free, like qmail) over the last 15 years. > > So have i, but i miss in your list a mention of exim. i tried exim sometime after switching to sendmail. it was just smail without the stupid bugs, so i saw no reason to switch to it. it's progressed a lot since then, but it is still the same model as exim. > I have also never used exim because I had settled on postfix through > much the same path (I also checked out zmailer in between) as you and > was me too. it didn't do anything amazingly different and was even clumsier to use than qmail. i tried pretty nearly every MTA i ever cam acrossand am a firm believer in the maxim that all mail programs suck, but some suck less. and postfix sucks least of all. craig -- craig sanders <[EMAIL PROTECTED]> (part time cyborg) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
