Re: qmail relaying
"Richard Zuidhof" <[EMAIL PROTECTED]> writes: > William Dode <[EMAIL PROTECTED]>: > >> I must change the machine of a mx. The first one is with qmail and the >> second with exim. >> Before the dns propagation, i would like that all the mail who still >> arrive on the qmail machine will be redirected to the new one. But i >> don't know qmail... >> >> Is it enough to remove the domain from >> /var/qmail/control/virtualsdomains and put it on rcpthosts ? > > It needs to stay in rcpthosts but you need to create an smtproute to get the > mail on the second server. /var/qmail/control/smtproutes should contain a > line like: > domain.com:eximmx.domain.com thanks -- William - http://flibuste.net
Re: qmail relaying
William Dode <[EMAIL PROTECTED]>: > I must change the machine of a mx. The first one is with qmail and the > second with exim. > Before the dns propagation, i would like that all the mail who still > arrive on the qmail machine will be redirected to the new one. But i > don't know qmail... > > Is it enough to remove the domain from > /var/qmail/control/virtualsdomains and put it on rcpthosts ? It needs to stay in rcpthosts but you need to create an smtproute to get the mail on the second server. /var/qmail/control/smtproutes should contain a line like: domain.com:eximmx.domain.com Richard
Re: qmail relaying
"Richard Zuidhof" <[EMAIL PROTECTED]> writes: > William Dode <[EMAIL PROTECTED]>: > >> I must change the machine of a mx. The first one is with qmail and the >> second with exim. >> Before the dns propagation, i would like that all the mail who still >> arrive on the qmail machine will be redirected to the new one. But i >> don't know qmail... >> >> Is it enough to remove the domain from >> /var/qmail/control/virtualsdomains and put it on rcpthosts ? > > It needs to stay in rcpthosts but you need to create an smtproute to get the > mail on the second server. /var/qmail/control/smtproutes should contain a > line like: > domain.com:eximmx.domain.com thanks -- William - http://flibuste.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: qmail relaying
William Dode <[EMAIL PROTECTED]>: > I must change the machine of a mx. The first one is with qmail and the > second with exim. > Before the dns propagation, i would like that all the mail who still > arrive on the qmail machine will be redirected to the new one. But i > don't know qmail... > > Is it enough to remove the domain from > /var/qmail/control/virtualsdomains and put it on rcpthosts ? It needs to stay in rcpthosts but you need to create an smtproute to get the mail on the second server. /var/qmail/control/smtproutes should contain a line like: domain.com:eximmx.domain.com Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
WikiLearn page on Virtual Email Domains (was: Re: qmail or postfix?)
Thomas GOIRAND wrote: > Cool ! Don't forget to post here when it's done ! :) I've started a WikiLearn page: http://twiki.org/cgi-bin/view/Wikilearn/EmailVirtualDomains Look it over, see what's wrong, misleading, or missing, and fix it. ;-) (It is, after all, a wiki.) regards, Randy Kramer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: qmail or postfix? (was: RE: What is the best mailling list manager for qmail and Domain Tech. Control ?)
> > > Can someone write here an easy understandable configuration for > > > Postfix with virtual domains ? After some call for help here, none of > > > you that know Posfix did it... there is an easy understandable VIRTUAL_README in postfix docs yet (at least in woody version), so it's not necessary to write another one; moreover on the Net, there are many howtos for specific situations if you run into trouble with the info, let send more specific questions. regards David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: qmail or postfix? (was: RE: What is the best mailling list manager for qmail and Domain Tech. Control ?)
- Original Message - From: "Ruth A. Kramer" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, February 28, 2004 6:48 AM Subject: Re: qmail or postfix? (was: RE: What is the best mailling list manager for qmail and Domain Tech. Control ?) > I'd like to try to help (to write an easy understandable configuration > for Postfix with virtual domains), but: Thanks ! Someone sent me sutch help from sendmail. A document telling how to do it for few MTAs could be written and for sure would be helpfull for a lot... >* I don't know how to do it myself, so if we get good responses here, > I'll try to help organize them on a WikiLearn page. Cool ! Don't forget to post here when it's done ! :) > I suppose setting up a virtual email domain means getting Postfix to > accept mail (for local delivery) for an email address that is not > "native" to the machine hosting the email server. yes > For example, if I have an email server named myemailserver.com, but want > to receive email for an address like [EMAIL PROTECTED], I then need > a virtual email domain? yes. And moreover, it's important that it can be possible to choose where a mailbox will be on the filesystem. A centralised /var/mail with all mbox files in it may not be the best design... > Questions: >* can I then also send email from [EMAIL PROTECTED] Yes, with tools like smtp with auth and/or webmail on that server for example. >* must rhkramer.com be a registered domain name (I assume so)? Yes, and the MX of that domain must point to that mailserver, otherwise mailserver should reject all message for that domain (that's what qmail do, exept if you do relaying). Regards, Thomas GOIRAND Get a hosting account: http://gplhost.com GPL.Host: Open source hosting worldwide -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: qmail or postfix? (was: RE: What is the best mailling list manager for qmail and Domain Tech. Control ?)
Sorry about the attributions below -- I suspect they are incorrect -- I didn't save some of the earlier posts in this thread, and didn't try searching the archives. Craig Sanders wrote: Thomas GOIRAND wrote??: > > Can someone write here an easy understandable configuration for > > Postfix with virtual domains ? After some call for help here, none of > > you that know Posfix did it... I'd like to try to help (to write an easy understandable configuration for Postfix with virtual domains), but: * I don't know how to do it myself, so if we get good responses here, I'll try to help organize them on a WikiLearn page. * I'm not even quite sure what virtual domains means or what they accomplish, so I'll start by asking that question, trying to answer it myself, and then asking some followup questions. I suppose setting up a virtual email domain means getting Postfix to accept mail (for local delivery) for an email address that is not "native" to the machine hosting the email server. For example, if I have an email server named myemailserver.com, but want to receive email for an address like [EMAIL PROTECTED], I then need a virtual email domain? Questions: * can I then also send email from [EMAIL PROTECTED] * must rhkramer.com be a registered domain name (I assume so)? Randy Kramer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: qmail or postfix? (was: RE: What is the best mailling list manager for qmail and Domain Tech. Control ?)
On Tue, Feb 24, 2004 at 03:29:04PM +0100, Thomas GOIRAND wrote: > - Original Message - > From: "Craig Sanders" <[EMAIL PROTECTED]> > > On Thu, Feb 19, 2004 at 09:34:52PM +0100, Bj?rnar Bj?rgum Larsen wrote: > > > > 4. the configuration is truly bizarre.bernstein has his own > > non-standard directory structures, and a liking for many little files. > > many of these files are 'magical' - the contents are irrelevant, mere > > existence of them alters behaviour of the program, and even causes programs > > to be run automagically. > > > > this makes it impossible to experiment by temporarily commenting out > > particular lines - you have to delete a file, and then hope you can > > remember what it was called if you need to re-enable that feature. > > I deseagree on that. I've found qmail's config file a lot more efficient than > one stupid unic file, fine. you have every right to be wrong. > Can someone write here an easy understandable configuration for > Postfix with virtual domains ? After some call for help here, none of > you that know Posfix did it... sorry, but it's not our problem if YOU can't understand clear and simple instructions or concepts. virtual domains are a well-documented part of postfix, and have been for years. > > 5. bernstein likes to reinvent the wheel. he does this (and does it badly) > > without regard to whether the wheel actually needs to be reinvented or not > > (e.g. ucspi-tcp). > > > > this is compounded by the fact that it is a complete PITA to use any of his > > programs without using all of his programs. > > I deseagree a lot on that also. Bernstein has coded ucspi-tcp as a > replacement for the standard tcp program. the program you are thinking of is called inetd (or xinetd - another version with resource limitation controls built in). > He has the rights to do so, and you have the rights not to use it if you like > inetd... of course he has the right to do so. that is beyond question. it was just unneccesary and stupid of him to do so. more to the point, if he's going to reinvent the wheel he should at least try to do a good job - a square wheel isn't any use to anyone. > that focus on staying on unix style, you couldn't be more wrong on this point. his programs implement BERNSTEIN-style, not traditional unix style. his programs are about as different from unix style as it's possible for software to be and still run on unix systems. craig -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: qmail or postfix? (was: RE: What is the best mailling list manager for qmail and Domain Tech. Control ?)
- Original Message - From: "Craig Sanders" <[EMAIL PROTECTED]> To: "Bj?rnar Bj?rgum Larsen" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, February 19, 2004 11:13 PM Subject: Re: qmail or postfix? (was: RE: What is the best mailling list manager for qmail and Domain Tech. Control ?) > On Thu, Feb 19, 2004 at 09:34:52PM +0100, Bj?rnar Bj?rgum Larsen wrote: > > 4. the configuration is truly bizarre.bernstein has his own non-standard > directory structures, and a liking for many little files. many of these files > are 'magical' - the contents are irrelevant, mere existence of them alters > behaviour of the program, and even causes programs to be run automagically. > > this makes it impossible to experiment by temporarily commenting out particular > lines - you have to delete a file, and then hope you can remember what it was > called if you need to re-enable that feature. I deseagree on that. I've found qmail's config file a lot more efficient than one stupid unic file, and most of the time the only files you have to modify are thoses (read it as "file: content". In this example, one and only mailbox is configurated for [EMAIL PROTECTED] has one unic row: -- /var/qmail/control/me: hostname.domain.com one line per domains: - /var/qmail/control/rcpthosts: domain.com /var/qmail/control/virtualdomains: domain.com:domain-com one line per mailbox: - /var/qmail/users/assign: =domain-com-joe:nobody:888:888:path::: /etc/poppasswd: pop_login:crypted_password:real_login:path I use /etc/poppasswd for popauth instead of /etc/passwd (using checklocalpwd password check replacement from Jedi) when I don't want to use SQL... I think it's clear, simple, and efficient. If you want to keep backups, then tar the /var/qmail/control folder and it's done... Can someone write here an easy understandable configuration for Postfix with virtual domains ? After some call for help here, none of you that know Posfix did it... > 5. bernstein likes to reinvent the wheel. he does this (and does it badly) > without regard to whether the wheel actually needs to be reinvented or not > (e.g. ucspi-tcp). > > this is compounded by the fact that it is a complete PITA to use any of his > programs without using all of his programs. I deseagree a lot on that also. Bernstein has coded ucspi-tcp as a replacement for the standard tcp program. He has the rights to do so, and you have the rights not to use it if you like inetd... His code is not well commented, maybe a bit hard to read for non-unix gurus, it's true. But it ends to very a short code, that focus on staying on unix style, eg modular, and reusing existing tools. If you want to have a quick idea of what I'm talking about, have a look at qmail-pop3d.c and you'll understand what it is all about. I've done mysqmail, a bunch of 3 binaries for having pop3 auth using mysql, and smtp + pop3 traffic accounted by domains in mySQL database. See: http://www.gplhost.com/?rub=softwares&sousrub=mysqmail For example, Bernstein uses his own "puts()" function that is NOT the real unix puts() function. The if you want to use the real unix puts(), patching means renaming his puts() into puts2() or something... This does not mean at all it's not well written. It's hard to read, but the resulting code seams to be efficient when you see the C code. On the counter part, I agree totaly on the fact that qmail should include all the add-ons made by lot's of people, like one of thoses dozens of pop alternative authentification. > ps: as for postfix being better - it is: > > 1. free software, with a real free software license (IBM public license) > 2. actively developed, with a friendly principal developer and helpful > developer & user community. > 3. backwards compatible with sendmail, so migration is easy > 4. secure > 5. fast (much faster than qmail) > 6. the best anti-spam features of any MTA available > 7. more features than you can poke a stick at For sure, I'll spend more time on Postfix soon... :) Best regards, Thomas GOIRAND Get a hosting account: http://gplhost.com GPL.Host: Open source hosting worldwide -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: qmail or postfix? (was: RE: What is the best mailling list manager for qmail and Domain Tech. Control ?)
Hi, On Sat, 21.02.2004 at 00:23:26 +0100, Adam ENDRODI <[EMAIL PROTECTED]> wrote: > Since the license prohibits distributing binary packages built > from modified source, you must rely on other methods of > installation. (On the other hand, once done, it's done for ever; > see the next point). well, if you are a new user and want to look at qmail, then you should *not* look at the Debian package qmail-src, but to this instead: http://qmail.mirrors.space.net/netqmail-1.05.tar.gz (found from http://qmail.mirrors.space.net/top.html) Or, if you have "higher" requirements, look at http://www.qmail-ldap.org/ > The most recent version (1.03) was released in the middle of 1998. > (Well, at least you won't have frequent head-ache due to new > releases :) Stock qmail-1.03 is sort of not recommended any longer, but superseded by netqmail. Best, --Toni++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: qmail or postfix? (was: RE: What is the best mailling list manager for qmail and Domain Tech. Control ?)
Bjørnar Bjørgum Larsen wrote: I am in the process of choosing between postfix and qmail for our mail relays. I've not decided yet. However, I am surprised by the fact that many people who prefer postfix, also enjoy posting unqualified[0] statements[1][2][3] about qmail. If anyone have properly grounded views, please share! Qmail does _everything_ like DJB thinks is the right way: - The FHS doesn't exist - /sbin/init and inetd suck, because they're based on 30 year old design - The biggest problem with qmail is it's license, as it permits to release a secure _and_ feature-rich binary distribution. This may be no big reason for one or two people managing one or two servers, but in an ISP environment I (and many other) prefer to save time by using "apt-get install". Another problem is: qmail (at least in standard configuration) is an I/O hog. At one client it was unable to saturate a T1 from a celeron 433 machine with a cheap IDE drive. Postfix in standard configuration outperformed it by factor 5 (and maybe more, since the T1 was saturated then). I was pretty confused about the number of config files. Yes, even Postfix has some, but there's not one config file for each subsystem. (That argument applies to Sam Varchawik's software [Courier MTA/-IMAP] as well). [...] [1] Michael Loftis wrote (about qmail): First is, unless they've made design changes, it's trivial to DoS. Really? How would you DoS qmail? Could the same attack be used to DoS postfix? [2] Michael Loftis also wrote (about qmail): Second, it doesn't scale so well, but unless you're talking upwards of about 3-5k/msgs/hr you might not run into it. Really? Quoting Bernstein quoting Bill Weinman (cr.yp.to/qmail/users.html): "Our busiest list is about 250 messages X 1800 subscribers (avg mail deliveries: 450,000 transactions per day). Sendmail was barfing badly on this, and qmail seems to be doing real well. The machine is a Pentium 90 running Linux 2.0.13 with 64Mb of RAM. I have the spawn limit set at 100. I am *very* impressed." How was the qmail that didn't scale well configured? On what hardware? See _my_ #2. Qmail _may_ scale well, but it *doesn't* in standard configuration. Did I mention that nobody with a clean mind runs critical and I/O intensive tasks on such hardware? [3] Craig Sanders wrote: ps: qmail is a bad idea. postfix is better. Your conclusion may be right, but the arguments are missing. Would you please share? I agree. Both statements. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: qmail or postfix? (was: RE: What is the best mailling list manager for qmail and Domain Tech. Control ?)
On Thu, Feb 19, 2004 at 09:34:52PM +0100, Bj?rnar Bj?rgum Larsen wrote: > I am in the process of choosing between postfix and qmail for our mail relays. I've > not decided yet. However, I am surprised by the fact that many people who prefer > postfix, also enjoy posting unqualified[0] statements[1][2][3] about qmail. > > If anyone have properly grounded views, please share! I used qmail for several years. One reason I dismissed it from my systems was its source code, which I regarded incoprehensive. For me, it meant whenever found myself in trouble I could not look at the source and trace down the problem, could not fix things I considered bugs and it was impossible to add new or to complete features I missed. DJB's taste to reinvent everything (including libc functions) was also disturbing. There are many supplementary patches to qmail; I suspect the number of machines running the virgin qmail is relatively low. As a consequence, in case you wished to achieve anything non-trivial you need to patch the source with code that's quality is unknown. Since the license prohibits distributing binary packages built from modified source, you must rely on other methods of installation. (On the other hand, once done, it's done for ever; see the next point). The most recent version (1.03) was released in the middle of 1998. (Well, at least you won't have frequent head-ache due to new releases :) bit, adam -- Am I a cleric? | 1024D/37B8D989 Or maybe a sinner? | 954B 998A E5F5 BA2A 3622 Unbeliever?| 82DD 54C2 843D 37B8 D989 Renegade? | http://sks.dnsalias.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: qmail or postfix? (was: RE: What is the best mailling list manager for qmail and Domain Tech. Control ?)
[no cc:s necessary, thanks] On Friday 20 February 2004 12.37, Craig Sanders wrote: > On Fri, Feb 20, 2004 at 08:36:08AM +0100, Adrian 'Dagurashibanipal' von Bidder wrote: > > I guess the document was written years ago, when postfix did indeed lack > > *some* of the features people did expect (one of them being the ability > > to reject mail instead of bounce it ;-) > > actually, it is qmail and not postfix that can't 5xx reject mail. qmail > has to accept and bounce it.postfix has always been able to reject > unwanted mail during the SMTP session (although the relay_recipient_maps > option is a relatively recent addition for rejecting unknown relay > recipient addresses). Hmm. Weren't there some early postifx 1.x releases who did by default bounce on unknown users? Or was it something different? I seem to dimly remember some discussions about the possibility to bounce directly in the SMTP dialog instead of bouncing under some circumstances. Anyway, the issue is of purely historic interest - today's postfix does of course reject mail quite early in most, if not all, cases where this is possible. cheers -- vbi -- Do you understand now why we attacked Iraq? Because war is good for the economy, which means war is good for America. Also, since God is on America's side, anyone who opposes war is a godless un-American Communist. -- excerpt from one of those 'joke' mails floating around. pgp0.pgp Description: signature
Re: qmail or postfix? (was: RE: What is the best mailling list manager for qmail and Domain Tech. Control ?)
On Fri, Feb 20, 2004 at 08:36:08AM +0100, Adrian 'Dagurashibanipal' von Bidder wrote: > On Thursday 19 February 2004 23.28, Craig Sanders wrote: > > On Thu, Feb 19, 2004 at 09:34:52PM +0100, Bj?rnar Bj?rgum Larsen wrote: > > > For example, I'd like comments on > > > http://homepages.tesco.net/~J.deBoynePollard/Reviews/UnixMTSes/postfix.ht > > >ml > > > > a collection of lies, half-truths, and mistruths. > > Since Bj?rnar was asking for qualified information, let's do the dance for > him... well done. you put a lot more effort in than i thought was warranted for tripe like that. > > the best that can be said about this document is that the author doesn't > > know what he is talking about. > > I guess the document was written years ago, when postfix did indeed lack > *some* of the features people did expect (one of them being the ability to > reject mail instead of bounce it ;-) actually, it is qmail and not postfix that can't 5xx reject mail. qmail has to accept and bounce it.postfix has always been able to reject unwanted mail during the SMTP session (although the relay_recipient_maps option is a relatively recent addition for rejecting unknown relay recipient addresses). BTW, bouncing rather than rejecting contributes significantly to the spam and virus problem. when a virus or spamware encounters a 5xx rejection, it does nothing, it just ignores it and moves on to the next victim address. when qmail accepts and bounces such a mail, it ends up spamming the forged sender address with unwanted bounces (which is also extra work for the qmail system itself - serious consequences during a spammer dictionary attack) > > > http://homepages.tesco.net/~J.deBoynePollard/Reviews/UnixMTSes/qmail.html > | host and user masquerading, > | virtual users, > | virtual domains, > | users that are not in /etc/passwd, > | SMTP Relay being denied by default, > | per-host SMTP Relay control, > | consultation of SMTP client blacklist and whitelist databases (using > | rblsmtpd from UCSPI-TCP), and > | an 8-bit clean SMTP server. > > postfix does all of these. but qmail doesn't do all of them. in particular, it is not really an 8-bit clean SMTP server. one of the requirements for 8-bit clean-ness is that the MTA translate 8-bit bodies to 7-bit quoted-printable if the mail is being sent to a non-8-bit MTA. qmail doesn't bother to do this. qmail's failure here is quite deliberate. bernstein's intention is to cause breakage for what he sees as obsolete systems. fair enough, they may be obsolete but to deliberately feed them data that you know they can't handle is irresponsible vandalism. it is also an extreme version of his notorious disdain for any kind of backwards-compatibility or migration path. see section 3.1 of http://www-dt.e-technik.uni-dortmund.de/~ma/qmail-bugs.html and bernstein's own words on the subject: http://cr.yp.to/smtp/8bitmime.html (in fact, the entire qmail-bugs document mentioned above is worth reading) craig -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: qmail or postfix? (was: RE: What is the best mailling list manager for qmail and Domain Tech. Control ?)
On Thursday 19 February 2004 23.28, Craig Sanders wrote: > On Thu, Feb 19, 2004 at 09:34:52PM +0100, Bj?rnar Bj?rgum Larsen wrote: > > For example, I'd like comments on > > http://homepages.tesco.net/~J.deBoynePollard/Reviews/UnixMTSes/postfix.ht > >ml > > a collection of lies, half-truths, and mistruths. Since Bjørnar was asking for qualified information, let's do the dance for him... | It has an official web page, but no third-party user-run web pages. http://www.aet.tu-cottbus.de/personen/jaenicke/postfix_tls/ http://www.kobitosan.net/postfix/ http://postfix.state-of-mind.de/patrick.koetter/smtpauth/ | However unlike qmail, there is not a large cottage industry producing | third-party extensions and contributions to Postfix. This is because the | modules in Postfix are more tightly coupled to one another and the | interfaces between them are undocumented, making it harder to write | third-party add-ons and replacement modules for Postfix than for qmail. http://www.postfix.org./addon.html | Also, this modularity does not extend to Postfix' configuration files. | Postfix is firmly in the same camp as exim and Sendmail here. It uses two | large monolithic configuration files, master.cf and main.cf, rather than | multiple simple small task-oriented configuration files. Like with all True, but is in the 'it's a feature, not a bug' category: you have all the info in one place, and you have comments in the default and (lots of) example conffiles. I guess exim4 has the best of both worlds here with a .d style directory, I wonder if postfix will follow suit here. | applications that choose this route, configuring Postfix thus requires that | one learn a set of configuration file keywords, and automated configuration | cannot be easily done under script control with echo and cat. There is postconf, and if add sed/awk to your toolset, you are not so helpless. Besides: how often do you do scripted reconfiguration of your mailer? I touch conffiles less than every month. | The glaring omission is a secure queue submission mechanism. Here Postfix | trades the appearance of security for actual security. Postfix boasts that | as standard it has no set-UID or set-GID programs, which superficially | appears to be an attractive feature. However, this boast comes at a price. | The price is that local users can place arbitrary junk into the mail | submission area, or delete submitted messages. Both qmail and MMDF avoid | this by having a non-world-writable submission directory and the program | that does the writing to that directory (qmail-queue and submit, | respectively) set-UID to its owner (the only set-UID program in the entire | package in the case of qmail). Huh? Users can send arbitrary junk in mail. Wow. Unique feature of postfix, sure. The only world writable things I could find in /var/spool/postfix were the sockets - so everybody can open the sockets and fifos in the 'public' directory. I guess this makes sense as everybody should be permitted to send email. | Furthermore, Postfix does not even fully utilise the user partitioning | capabilities of the operating system to fully insulate users from other | users as qmail does. You'd have to read the code to assess these. | Which daemons in Postfix run as root is not documented in the manual pages. ps is a handy tool, for one thing. Also, the man pages *do* have a 'SECURITY' section, where it say things like 'The qmgr daemon does not talk to the outside world, and it can be run at fixed low privilege in a chrooted environment.' | Postfix contains numerous configuration options, particularly in the area of | SMTP Relay service. However, the flexibility of Postfix is in many ways | illusory. Many of the configuration options control features that are | half-baked ideas from the Half-Baked Ideas Brigade. The two examples, smtpd_helo_restrictions and reject_unknown_client, *can* be used by site administrators. The default configuration afaik leaves them out. The documentation does describe what they do - and anybody with a bit of experience in fighting spam can see why they are useful. | There are several different "mbox" formats. MTSes such as qmail use the | "mboxrd" format that was proposed by Rahul Dhesi on 1995-06-04, which uses a | reversible encoding of "From " lines in messages. However, Postfix uses the | "mboxo" format instead. The encoding of "From " lines is not reversible in | this format, and where the original message contained a "From " line there | is no means for an MUA to obtain the message in its original form as it was | before Postfix delivered it to the mailbox. Somebody else will have to comment on that - I've got no idea what he's talking about here. | Postfix always requires DNS service. Dunno, never have tracked DNS calls. | Postfix modifies in-transit and inbound mail. I think the idea here is that any mail postfix spits out is regular mail according to the RF
Re: qmail or postfix? (was: RE: What is the best mailling list manager for qmail and Domain Tech. Control ?)
On Thu, Feb 19, 2004 at 11:22:54PM +0100, Adrian 'Dagurashibanipal' von Bidder wrote: > I take this to mean that there are no binaries to download from postifx.org > itself - all binaries are made by integrators/vendors. This does not mean > that making binaries is not allowed. Binaries are, indeed, released through vendors. See http://www.postfix.org/packages.html for a listing of various links to packages of postfix. The postfix.org website doesn't have the packages, but links to them all. According to the mirrors, Things are done according to the IBM public license, http://getmyip.com/mirror/pub/LICENSE Read the IBM public license and take it from there. Hope this might help clear up any licensing/packaging issues with postfix. Sorry, I cannot comment as to the status of qmail, since I have chosen to use postfix instead. j -- == + It's simply not | John Keimel+ + RFC1149 compliant!| [EMAIL PROTECTED]+ + | http://www.keimel.com + == pgp0.pgp Description: PGP signature
Re: qmail or postfix? (was: RE: What is the best mailling list manager for qmail and Domain Tech. Control ?)
On Thu, Feb 19, 2004 at 09:34:52PM +0100, Bj?rnar Bj?rgum Larsen wrote: > For example, I'd like comments on > http://homepages.tesco.net/~J.deBoynePollard/Reviews/UnixMTSes/postfix.html a collection of lies, half-truths, and mistruths. the best that can be said about this document is that the author doesn't know what he is talking about. > and > http://homepages.tesco.net/~J.deBoynePollard/Reviews/UnixMTSes/qmail.html biased bullshit and boosterism. rah rah rah! worship bernstein. craig -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: qmail or postfix? (was: RE: What is the best mailling list manager for qmail and Domain Tech. Control ?)
On Thursday 19 February 2004 21.56, Dan MacNeil wrote: > > http://homepages.tesco.net/~J.deBoynePollard/Reviews/UnixMTSes/postfix.ht > >ml > > says at the very bottom: > > Postfix is only available in source form, > not as precompiled or prepackaged binaries. > There is a list of FTP sites that hold the > source tarball on the official web site. > > I have apt-get install'd postfix so I suspect this is not true. If this is > an error, there may be others. I take this to mean that there are no binaries to download from postifx.org itself - all binaries are made by integrators/vendors. This does not mean that making binaries is not allowed. cheers -- vbi -- Der Satire steht das Recht auf Übertreibung zu. Aber sie hat es schon seit langem nicht mehr nötig, von diesem Recht Gebrauch zu machen. -- Gabriel Laub pgp0.pgp Description: signature
Re: qmail or postfix? (was: RE: What is the best mailling list manager for qmail and Domain Tech. Control ?)
On Thu, Feb 19, 2004 at 09:34:52PM +0100, Bj?rnar Bj?rgum Larsen wrote: > [3] Craig Sanders wrote: > > ps: qmail is a bad idea. postfix is better. > > Your conclusion may be right, but the arguments are missing. Would you please > share? search the archives of this list. MTA comparisons have been discussed many times. i've made the arguments several times before and i'm getting bored of it. to summarise: 1. because qmail is so different from other MTAs, it is a dead-end trap, just like proprietary software. bernstein doesn't believe in making any effort to assist people who were using other MTAs and want to switch - migrating to qmail is a pain, and migrating away from it is just as bad. 2. it has severe licensing problems, which mean that the code basically stagnated years ago. no patches are ever accepted into qmail, and the author doesn't appear to be interested in making any improvements (in his estimation, it is already "perfect"...ignoring several glaringly obvious faults and lacks). the license means that using qmail is a reversion to the bad old days before free software became ubiqitous - the late 1980s for instance. back then you had to hunt for the original source (easy enough), then hunt for every patch that you needed to make it useful, then apply them (and hope that the patches are compatiblediscovering by trial and error that they can be compatible but only if applied in a particular *undocumented* order), then compile and install it. 3. bernstein insists that you discard years of practice, tools, and techniques and start from scratch. if you don't like it, then you are a moron because bernstein is Always Right so don't complain. 4. the configuration is truly bizarre.bernstein has his own non-standard directory structures, and a liking for many little files. many of these files are 'magical' - the contents are irrelevant, mere existence of them alters behaviour of the program, and even causes programs to be run automagically. this makes it impossible to experiment by temporarily commenting out particular lines - you have to delete a file, and then hope you can remember what it was called if you need to re-enable that feature. it also means that there is no config file containing comments to serve as working reference documentation. 5. bernstein likes to reinvent the wheel. he does this (and does it badly) without regard to whether the wheel actually needs to be reinvented or not (e.g. ucspi-tcp). this is compounded by the fact that it is a complete PITA to use any of his programs without using all of his programs. 6. the author is a rude jerk. this is undisputed, even by those who actually like bernstein's software. craig ps: as for postfix being better - it is: 1. free software, with a real free software license (IBM public license) 2. actively developed, with a friendly principal developer and helpful developer & user community. 3. backwards compatible with sendmail, so migration is easy 4. secure 5. fast (much faster than qmail) 6. the best anti-spam features of any MTA available 7. more features than you can poke a stick at -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: qmail or postfix? (was: RE: What is the best mailling list manager for qmail and Domain Tech. Control ?)
On Thu, 2004-02-19 at 11:34, Bjørnar Bjørgum Larsen wrote: > I am in the process of choosing between postfix and qmail for our mail relays. I've > not decided yet. However, I am surprised by the fact that many people who prefer > postfix, also enjoy posting unqualified[0] statements[1][2][3] about qmail. > > If anyone have properly grounded views, please share! > > For example, I'd like comments on > http://homepages.tesco.net/~J.deBoynePollard/Reviews/UnixMTSes/postfix.html > and > http://homepages.tesco.net/~J.deBoynePollard/Reviews/UnixMTSes/qmail.html > > > > [0] A _qualified_ statement would e.g. be "qmail is trivially DoS'ed by sending > emails with no subject at a rate of 2 per second". Typical unqualified statements > are shown below. > > [1] Michael Loftis wrote (about qmail): > > First is, unless they've made design changes, > > it's trivial to DoS. > > Really? How would you DoS qmail? Could the same attack be used to DoS postfix? > > [2] Michael Loftis also wrote (about qmail): > > Second, it doesn't scale so well, but unless > > you're talking upwards of about 3-5k/msgs/hr > > you might not run into it. > > Really? Quoting Bernstein quoting Bill Weinman (cr.yp.to/qmail/users.html): > "Our busiest list is about 250 messages X 1800 subscribers > (avg mail deliveries: 450,000 transactions per day). Sendmail > was barfing badly on this, and qmail seems to be doing real > well. The machine is a Pentium 90 running Linux 2.0.13 with > 64Mb of RAM. I have the spawn limit set at 100. I am *very* > impressed." > > How was the qmail that didn't scale well configured? On what hardware? > > [3] Craig Sanders wrote: > > ps: qmail is a bad idea. postfix is better. > > Your conclusion may be right, but the arguments are missing. Would you please share? > > > Thanks, > > :) Bjornar > Bjornar, I have run them all at one time or another. We currently are running qmail for our main MTA's but have postfix running on the sidelines. I don't care to debate MTA's any more. Akin to debating which is a better automobile. So I say, "pick a horse and ride". Now that said, it really depends on your experience, time focus, OS and hardware. qmail does the job, round the clock. So does postfix. You mentioned nothing specifically about what you wanted to do with your MTA relays ? Hard to help. qmail & postix will both relay. Dee -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: qmail or postfix? (was: RE: What is the best mailling list manager for qmail and Domain Tech. Control ?)
On Thursday 19 February 2004 21.34, Bjørnar Bjørgum Larsen wrote: > I am in the process of choosing between postfix and qmail for our mail > relays. I've not decided yet. Matter of taste - I find postfix' log files are orders of magnitude easier to read than qmail's. Also matter of taste - I could not wrap my head around qmail's configuration ideology. postfix imho stays closer to what I expect from a program in the Unix world. These two made the decision for me quite early, and I'm happy with postfix now, so I haven't gone back to see how well qmail would have dealt with requirements. A third argument - also not of the hard facts kind - is that I don't like qmail's licensing. cheers -- vbi -- Maintenance-free: When it breaks, it can't be fixed... pgp0.pgp Description: signature
Re: qmail or postfix? (was: RE: What is the best mailling list manager for qmail and Domain Tech. Control ?)
> http://homepages.tesco.net/~J.deBoynePollard/Reviews/UnixMTSes/postfix.html says at the very bottom: Postfix is only available in source form, not as precompiled or prepackaged binaries. There is a list of FTP sites that hold the source tarball on the official web site. I have apt-get install'd postfix so I suspect this is not true. If this is an error, there may be others. The biggest complaint I've heard about qmail is that its license requires you to install binaries according to the taste of the creator. This means that things are the same on Debian solaris and redhat but also makes it less "standard" if all you use is one distribution. On Thu, 19 Feb 2004, Bjørnar Bjørgum Larsen wrote: > I am in the process of choosing between postfix and qmail for our mail > relays. I've not decided yet. However, I am surprised by the fact that > many people who prefer postfix, also enjoy posting unqualified[0] > statements[1][2][3] about qmail. > > If anyone have properly grounded views, please share! > > For example, I'd like comments on > http://homepages.tesco.net/~J.deBoynePollard/Reviews/UnixMTSes/postfix.html > and > http://homepages.tesco.net/~J.deBoynePollard/Reviews/UnixMTSes/qmail.html > > > > [0] A _qualified_ statement would e.g. be "qmail is trivially DoS'ed by sending > emails with no subject at a rate of 2 per second". Typical unqualified statements > are shown below. > > [1] Michael Loftis wrote (about qmail): > > First is, unless they've made design changes, > > it's trivial to DoS. > > Really? How would you DoS qmail? Could the same attack be used to DoS postfix? > > [2] Michael Loftis also wrote (about qmail): > > Second, it doesn't scale so well, but unless > > you're talking upwards of about 3-5k/msgs/hr > > you might not run into it. > > Really? Quoting Bernstein quoting Bill Weinman (cr.yp.to/qmail/users.html): > "Our busiest list is about 250 messages X 1800 subscribers > (avg mail deliveries: 450,000 transactions per day). Sendmail > was barfing badly on this, and qmail seems to be doing real > well. The machine is a Pentium 90 running Linux 2.0.13 with > 64Mb of RAM. I have the spawn limit set at 100. I am *very* > impressed." > > How was the qmail that didn't scale well configured? On what hardware? > > [3] Craig Sanders wrote: > > ps: qmail is a bad idea. postfix is better. > > Your conclusion may be right, but the arguments are missing. Would you please share? > > > Thanks, > > :) Bjornar > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Qmail + Amavis + Spamassassin
On Tue, 15 Jul 2003 at 13:18:21 +0200, M.S. Lucas wrote: > > I want to use Qmail with Amavis and Spamassassin on a Debian Woody server. > Qmail and Spamassassin are both available on Woody but Amavis isn't. > > What source do you use for the (backported) amavis packages > > I used > deb http://people.debian.org/~nobse/debian/woody/backported ./ > > on a test server but thay don't serve Amavis packages anymore. > > What is a good and stable source for amavis deb files. > > Maurice Lucas Instead of amavis, you can consider using amavisd-new. -- Package: amavisd-new Maintainer: Brian May <[EMAIL PROTECTED]> Version: 20030616p3-1 Replaces: amavis Provides: amavis Depends: file, libmime-perl (>= 5.313), libconvert-tnef-perl (>= 0.06), libconvert-uulib-perl, libcompress-zlib-perl (>= 1.14), libarchive-tar-perl, libarchive-zip-perl, libmailtools-perl, libunix-syslog-perl, libnet-perl (>= 1:1.12), libnet-server-perl, libtime-hires-perl, adduser (>= 3.34), libdigest-md5-perl, libmime-base64-perl, perl Suggests: spamassassin, clamav, clamav-daemon, lha, arj, unrar, zoo, nomarch, cpio, lzop Conflicts: amavis Description: Interface between MTA and virus scanner/content filters AMaViSd-new is a script that interfaces a mail transport agent (MTA) with zero or more virus scanners, and spamassassin (optional). . AMaViSd-new supports all MTAs through its generic SMTP filter mode (ideal for postfix and exim). It is faster and safer to use the SMTP filter mode than using the AMaViS pipe client. . When in doubt about which amavis-* package to use, try this one - Packages backported for Woody are at http://people.debian.org/~aurel32/BACKPORTS/pool/main/a/amavisd-new/ So the entry in the sources.list is: deb http://people.debian.org/~aurel32/BACKPORTS woody main HIH -- Tomasz Papszun SysAdm @ TP S.A. Lodz, Poland | And it's only [EMAIL PROTECTED] http://www.lodz.tpsa.pl/ | ones and zeros. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Qmail+Spamassasin
Try this http://www.magma.com.ni/~jorge/spamassassin.html If you have any grief let me know as I've got it running here from these instructions Dave At 13:16 25/02/2003 +0100, Jasper Metselaar wrote: Hi, Is there someone who's using Spamassasin together with Qmail (Gerrit Pape's packages)? I am trying to get this combination working, but didn't succeed yet.If someone knows a good how-to document I would be very grateful. Thanks in advance! - Jasper -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Qmail+Spamassasin
Try this http://www.magma.com.ni/~jorge/spamassassin.html If you have any grief let me know as I've got it running here from these instructions Dave At 13:16 25/02/2003 +0100, Jasper Metselaar wrote: Hi, Is there someone who's using Spamassasin together with Qmail (Gerrit Pape's packages)? I am trying to get this combination working, but didn't succeed yet.If someone knows a good how-to document I would be very grateful. Thanks in advance! - Jasper -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Qmail+Spamassasin
Actualy its quite easy to get spamassassin to work with qmail, install and run spamassassin as a deamon (spamd), and insert something like: |ifspamh example-com-isspam in top of the users dot-qmail file ex. .qmail-example-com then create .qmail-example-com-isspam and modify it to your needs. There is several ways to make it work, but this method works well for me :) //Burner On Tuesday 25 February 2003 13:16, Jasper Metselaar wrote: > Hi, > > Is there someone who's using Spamassasin together with Qmail (Gerrit > Pape's packages)? I am trying to get this combination working, but didn't > succeed yet.If someone knows a good how-to document I would be very > grateful. > > Thanks in advance! > > - Jasper
Re: Qmail+Spamassasin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 25 February 2003 05:16, Jasper Metselaar wrote: > Is there someone who's using Spamassasin together with Qmail (Gerrit > Pape's packages)? I am trying to get this combination working, but didn't > succeed yet.If someone knows a good how-to document I would be very > grateful. Morning... I'm not running Gerrit's packages, but Jon Marler's, which are installable as build scripts by apt-get. These packages have several of the patches, including the (I think) qmail-local patch to allow other programs to process the mail before delivery. However, with my config, I'm not using that right now. I may soon, however. What I am doing is calling spamassassin via my local procmail (preline-ing it in my users .qmail files) without a problem. - --mec - -- The mere fact that my assumptions are incorrect and my conclusions invalid does not mean that I am not right in principle. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+W3y1vDNtj3aXDYkRApg9AJ913mKN+fnxCpN2GhQwke9SFoVT5ACcCozb GjaZfhR8BX8UU3mP+C8UQ9M= =b62m -END PGP SIGNATURE-
Re: Qmail+Spamassasin
Actualy its quite easy to get spamassassin to work with qmail, install and run spamassassin as a deamon (spamd), and insert something like: |ifspamh example-com-isspam in top of the users dot-qmail file ex. .qmail-example-com then create .qmail-example-com-isspam and modify it to your needs. There is several ways to make it work, but this method works well for me :) //Burner On Tuesday 25 February 2003 13:16, Jasper Metselaar wrote: > Hi, > > Is there someone who's using Spamassasin together with Qmail (Gerrit > Pape's packages)? I am trying to get this combination working, but didn't > succeed yet.If someone knows a good how-to document I would be very > grateful. > > Thanks in advance! > > - Jasper -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Qmail+Spamassasin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 25 February 2003 05:16, Jasper Metselaar wrote: > Is there someone who's using Spamassasin together with Qmail (Gerrit > Pape's packages)? I am trying to get this combination working, but didn't > succeed yet.If someone knows a good how-to document I would be very > grateful. Morning... I'm not running Gerrit's packages, but Jon Marler's, which are installable as build scripts by apt-get. These packages have several of the patches, including the (I think) qmail-local patch to allow other programs to process the mail before delivery. However, with my config, I'm not using that right now. I may soon, however. What I am doing is calling spamassassin via my local procmail (preline-ing it in my users .qmail files) without a problem. - --mec - -- The mere fact that my assumptions are incorrect and my conclusions invalid does not mean that I am not right in principle. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+W3y1vDNtj3aXDYkRApg9AJ913mKN+fnxCpN2GhQwke9SFoVT5ACcCozb GjaZfhR8BX8UU3mP+C8UQ9M= =b62m -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Qmail and bounces
Hi, On Tue, Feb 18, 2003 at 10:19:27AM +0100, Russell Coker wrote: > I have a mail server running a cluster of back-end stores (because no single > server can handle the load) and Qmail-ldap for the front-end to send the > message to the appropriate back-end machine. > > The problem is that Qmail is accepting messages for non-existant destinations > (IE mail for [EMAIL PROTECTED] when there is not account named "user" in the > LDAP directory). Ideally Qmail would reject the message with a SMTP 550 > code. However then Qmail will repeatedly try to deliver the message > "locally" to the back-end machine but aborts every time because it's not in > the LDAP (one message had 17 delivery attempts). > > Any suggestions for what to do about this? Even if the LDAP backend is implemented as a delivery agent, it should be able to generate bounces. Qmail interprets error code 100 as a permanent error, and 111 as a temporary error. If qmail-ldap generates a 111 if the user is not found in LDAP, I guess that's what should be fixed... Cheers, Emile. -- E-Advies / Emile van Bergen | [EMAIL PROTECTED] tel. +31 (0)70 3906153| http://www.e-advies.info msg08097/pgp0.pgp Description: PGP signature
Re: Qmail/Postfix/Sendmail for fastest outgoing mail
I remember, that sendmail, exim, and others have queuing strategies, that try to minimize the number of remote conections. El lun, 25-11-2002 a las 07:00, Craig Sanders escribió: > On Mon, Nov 25, 2002 at 11:37:58PM +1100, Jason Lim wrote: > > > nope, because postfix has no way of knowing that they were > > > originally the same email(*). postfix has been handed 10 individual > > > emails by qmail, so it will deliver 10 individual emails. > > > > Mmm... but, for example, if it scanned it's queue every 30 seconds, > > for example, it could then combine them together? > > nope. For example at www.exim.org you find the following paragraphs: SMTP batching When an SMTP delivery attempt fails, causing the message to be deferred till later, Exim updates a DBM database that contains records keyed by host name plus IP address. Each record holds a list of messages that are waiting for that host and address. When an SMTP delivery succeeds, Exim consults the database to see if there are any other messages waiting for the same host and address. If it finds any, it creates a new Exim process and passes it the open SMTP channel and a message identification. The new process then delivers the waiting message down the existing channel and may in turn cause the creation of yet another process. Any other waiting addresses in the message are skipped. The maximum number of messages sent down one connection is configurable. This scheme achieves some SMTP efficiency when a number of messages have been queued up for a given host, without the overhead of a heavyweight queueing apparatus. --- This is similar to what I'm talking about. I'm just looking to increase efficiency with sending millions of emails. > > Nope... not running ezmlm at all, just a lot of CGIs (through > > web/Apache) sending emails. Actually... I wonder... is there any > > drop-in replacement for /usr/sbin/sendmail that would just dump the > > emails to another server for actual sending? This should not affect > > receiving email in the least (hence minimize disruption) but would > > need to be able to dump the emails at a high rate. I'm not sure if > > there is such a thing though. In your scenario you could forward the messages to the mail-sending box via the QMTP protocol provided by Qmail. On the Mail sending box you just receive via QMTP and hand it over to Postfix or whatever you decide to use for outgoing mail. QMTP is loots faster then SMTP. But only Qmail supports QMTP, which means the outgoing server must be running QMTP too? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Qmail/Postfix/Sendmail for fastest outgoing mail
On Tue, Nov 26, 2002 at 01:33:57AM -0600, [EMAIL PROTECTED] wrote: > El lun, 25-11-2002 a las 07:00, Craig Sanders escribi?: > > On Mon, Nov 25, 2002 at 11:37:58PM +1100, Jason Lim wrote: > > > > nope, because postfix has no way of knowing that they were > > > > originally the same email(*). postfix has been handed 10 individual > > > > emails by qmail, so it will deliver 10 individual emails. > > > > > > Mmm... but, for example, if it scanned it's queue every 30 seconds, > > > for example, it could then combine them together? > > > > nope. > > For example at www.exim.org you find the following paragraphs: > > SMTP batching > [...] >When an SMTP delivery succeeds, Exim consults the database to see >if there are any other messages waiting for the same host and >address. If it finds any, it creates a new Exim process and passes >it the open SMTP channel and a message identification. The new >process then delivers the waiting message down the existing channel >and may in turn cause the creation of yet another process. Any >other waiting addresses in the message are skipped. The maximum >number of messages sent down one connection is configurable. this is what postfix, and i believe sendmail too, calls "connection caching", or re-using an existing SMTP connection to deliver a second (or third or...) message, instead of closing the connection after sending one message and opening new connections for subsequent messages. tis isn't what Jason wanted, which was combining multiple almost-identical messages together into one message. postfix can't do this yet. the author, wietse venema, says it is on his TODO list - i guess he'll start working on it for the dev snapshot after the postfix 1.2 has been released (due about a month from now) what postfix does now is open multiple smtp connections to the same host in parallel if there are multiple different messages to deliver to that host. this is controlled by the smtp_destination_concurrency_limit option. qmail also does multiple parallel deliveries to the same host (always, even when one message is CC-ed to 2+ addresses at the same domain). i don't know whether qmail also does connection caching or not. personally, i'd like to have both connection caching AND parallel delivery - but if i had to choose between them, i'd probably choose parallel. it isn't one of the reasons i use postfix, but i'm not at all dissatisfied with postfix's performance...quite the contrary. >This scheme achieves some SMTP efficiency when a number of messages >have been queued up for a given host, without the overhead of a >heavyweight queueing apparatus. yep, it avoids the overhead of establishing new smtp connections to the same host - i.e. saves a few round-trip delays of possibly several hundred milliseconds (or sometimes more) each. this can be significant. it is particularly useful when outbound smtp connections go through a firewall or NAT box which can only keep track of a limited number of connections. some commercial firewalls have this problem, linux ipchains/iptables doesn't. craig -- craig sanders <[EMAIL PROTECTED]> Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Qmail/Postfix/Sendmail for fastest outgoing mail
Hello! I remember, that sendmail, exim, and others have queuing strategies, that try to minimize the number of remote conections. El lun, 25-11-2002 a las 07:00, Craig Sanders escribió: > On Mon, Nov 25, 2002 at 11:37:58PM +1100, Jason Lim wrote: > > > nope, because postfix has no way of knowing that they were > > > originally the same email(*). postfix has been handed 10 individual > > > emails by qmail, so it will deliver 10 individual emails. > > > > Mmm... but, for example, if it scanned it's queue every 30 seconds, > > for example, it could then combine them together? > > nope. For example at www.exim.org you find the following paragraphs: SMTP batching When an SMTP delivery attempt fails, causing the message to be deferred till later, Exim updates a DBM database that contains records keyed by host name plus IP address. Each record holds a list of messages that are waiting for that host and address. When an SMTP delivery succeeds, Exim consults the database to see if there are any other messages waiting for the same host and address. If it finds any, it creates a new Exim process and passes it the open SMTP channel and a message identification. The new process then delivers the waiting message down the existing channel and may in turn cause the creation of yet another process. Any other waiting addresses in the message are skipped. The maximum number of messages sent down one connection is configurable. This scheme achieves some SMTP efficiency when a number of messages have been queued up for a given host, without the overhead of a heavyweight queueing apparatus. --- > > Nope... not running ezmlm at all, just a lot of CGIs (through > > web/Apache) sending emails. Actually... I wonder... is there any > > drop-in replacement for /usr/sbin/sendmail that would just dump the > > emails to another server for actual sending? This should not affect > > receiving email in the least (hence minimize disruption) but would > > need to be able to dump the emails at a high rate. I'm not sure if > > there is such a thing though. In your scenario you could forward the messages to the mail-sending box via the QMTP protocol provided by Qmail. On the Mail sending box you just receive via QMTP and hand it over to Postfix or whatever you decide to use for outgoing mail. QMTP is loots faster then SMTP. Best Regards, Jorge-León -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Qmail/Postfix/Sendmail for fastest outgoing mail
Jason Lim writes: > > recently there was a patch floating on the qmail list that patches > > the way qmail-send runs. The result is having two processes instead, > > and one performance bottleneck within qmail-send removed. I don't > > recall the details, but the purported increase in performance > > should be at least a factor of 4-5 if I understood that well. > > You probably need other patches, too, to get > > concurrencyremote > 254. > > I've heard of and installed the ">254 concurrencyremote" patch... to allow > about 400 concurrent remote connections, BUT I haven't heard of this other > patch you mention... sounds like it might increase speed considerably... > got any more info on it? The patch can be found at www.nrg4u.com. From the doc: The exttodo patch addresses a problem known as the silly qmail (queue) problem. This problem is found only on system with high injection rates. Regards, -- Adriano -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Qmail/Postfix/Sendmail for fastest outgoing mail
> recently there was a patch floating on the qmail list that patches > the way qmail-send runs. The result is having two processes instead, > and one performance bottleneck within qmail-send removed. I don't > recall the details, but the purported increase in performance > should be at least a factor of 4-5 if I understood that well. > You probably need other patches, too, to get > concurrencyremote > 254. I've heard of and installed the ">254 concurrencyremote" patch... to allow about 400 concurrent remote connections, BUT I haven't heard of this other patch you mention... sounds like it might increase speed considerably... got any more info on it? > > > create so many simultaneous connections to slow remote hosts (waiting > > around and stuff), and instead would be able to get email off faster to > > the Email box and thus free up load on the Qmail servers, so they can do > > other stuff more (Apache). > > Yes, but the now-central qmail server must be ramped up a bit since it > will have the combined load of all other (former) mail servers. Actually, I was kind of under the impression that since the dedicated email server would be ONLY doing email and absolutely nothing else, that even a 900Mhz CPU with 128Mb RAM and 30Gb HD would suffice, since it would only act as a conduit (and it has good bandwidth btw). No email is actually received there either... it just sends OUT email (the Qmail servers only relay their mail to that server). Wouldn't this be the case? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Qmail/Postfix/Sendmail for fastest outgoing mail
On Tue, Nov 26, 2002 at 12:00:32AM +1100, Craig Sanders wrote: > > Actually, I can't see how Postfix would be at all faster, since it > > would still be sending individual emails on separate connections. In > > fact, wouldn't it be slower, since Qmail was optimized specifically > > for this? > > nope, because postfix is faster than qmail. with some usage patterns > (i.e. no VERP) it is much faster. for others (e.g. VERP) is is only > slightly faster. actually, it's a lot better than i remembered it to be even when using VERP. postfix is between two and four times as fast as qmail with the same load on the same hardware, depending on other, non-MTA, optimisations (e.g. filesystem tweaks). the main reason for this is that postfix is far more efficient in it's disk I/O. http://www-dt.e-technik.uni-dortmund.de/~ma/postfix/vsqmail.html in this benchmark, postfix delivered the same number of messages on exactly the same hardware (running FreeBSD) about twice as fast as qmail. when you enable FreeBSD's filesystem softupdates (which is safe to do with postfix, but not safe with qmail), the delivery speed almost doubles again. all the messages were to individual recipients, i.e. worst-case for postfix. there's a newer benchmark by the same guy with more details. it compares postfix, qmail, exim, and sendmail: http://www-dt.e-technik.uni-dortmund.de/~ma/postfix/bench2.html there are other MTA benchmarks around. search on google if you want to find more. btw, on a linux box, use a better filesystem than ext2 or ext3 for best performance. XFS is good. reiserfs is fine too. with ext2/ext3 you have to run 'chattr +S' on the spool directories to be safe, which makes all write operations in that directory synchronous. this is a real performance killer. craig ps: i found a link to mini_sendmail, which looks like it may be exactly what you need to replace the /usr/sbin/sendmail binary. http://www.acme.com/software/mini_sendmail/ mini_sendmail reads its standard input up to an end-of-file and sends a copy of the message found there to all of the addresses listed. The message is sent by connecting to a local SMTP server. This means mini_sendmail can be used to send email from inside a chroot(2) area. -- craig sanders <[EMAIL PROTECTED]> Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Qmail/Postfix/Sendmail for fastest outgoing mail
On Mon, Nov 25, 2002 at 11:37:58PM +1100, Jason Lim wrote: > > nope, because postfix has no way of knowing that they were > > originally the same email(*). postfix has been handed 10 individual > > emails by qmail, so it will deliver 10 individual emails. > > Mmm... but, for example, if it scanned it's queue every 30 seconds, > for example, it could then combine them together? nope. > I'd assume ISPs and such would have great use for this, especially on > web hosting boxes, as overhead in sending numerous emails could be > saved? i don't imagine they would. it's easy enough to just send one email if that's what you want to do - why complicate matters by hacking your MTA to have super mind-reading powers? > > postfix would be slightly faster than qmail but not that much faster > > that it's worth using different software for - unless part of your > > purpose is to get some real (as opposed to testing) experience with > > postfix to decide whether it's worth switching. > > Actually, I can't see how Postfix would be at all faster, since it > would still be sending individual emails on separate connections. In > fact, wouldn't it be slower, since Qmail was optimized specifically > for this? nope, because postfix is faster than qmail. with some usage patterns (i.e. no VERP) it is much faster. for others (e.g. VERP) is is only slightly faster. > > if you want to fix this problem, you have to do it at the source - > > i.e. replace qmail with postfix on your main boxes. that would be > > a lot of work, not something to be done lightly. > > And certainly not feasible on production systems... unfortunate. But > actually, Qmail was the best choice at the time, since it an Vpopmail > make such a good incoming email system. actually, it is feasible, it's just a lot of work that can go seriously wrong if you're not scrupulously careful in your planning and your implementation. i.e. it's do-able, but hard. whether it's worth the effort is for you to decide. > > if you're not using ezmlm, you may be able to hack your list manager > > to bypass local qmail and send outgoing messages via SMTP direct to > > the postfix box. this may involve hacking the list manager to talk > > SMTP rather thank fork /usr/sbin/sendmail, or it may involve > > replacing /usr/sbin/sendmail with a wrapper script that talks SMTP. > > either way, it's not too hard. > > Nope... not running ezmlm at all, just a lot of CGIs (through > web/Apache) sending emails. Actually... I wonder... is there any > drop-in replacement for /usr/sbin/sendmail that would just dump the > emails to another server for actual sending? This should not affect > receiving email in the least (hence minimize disruption) but would > need to be able to dump the emails at a high rate. I'm not sure if > there is such a thing though. IIRC, there's a simple one that comes with postfix or is available on one of the postfix contrib web sites. if not, it would be trivial to hack up a simple one in perl using the Net::SMTP or MIME::Lite modules. about 5 minutes work - accept the message on stdin, connect to port 25 on the postfix box, and send the message via smtp. alternatively, just modify your CGI scripts to make an SMTP connection to the postfix box rather than fork sendmail. it's easy to do and, IMO, is what CGI scripts should do anyway. MIME::Lite is a good perl module for sending mail via smtp - whether you use it's MIME features or not (and it's also good for generating correctly formatted MIME messages) IMO, using MIME::Lite is easier than forking sendmailand far more versatile. i tend to modify most email sending CGI scripts to use MIME:Lite or Net::SMTP because i really don't like CGI scripts that fork sendmail - most of the authors are too lazy to call sendmail with the right arguments to set the real From envelope address, so the mail is sent with the apache user's address in the Return-Path header (e.g. [EMAIL PROTECTED]) - which results in bounces being delivered to www-data and the occasional idiot user replying to www-data...a mailbox that almost never gets read. this is not a problem when sending with SMTP because you have to specify the envelope from address as part of the SMTP dialog. craig -- craig sanders <[EMAIL PROTECTED]> Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Qmail/Postfix/Sendmail for fastest outgoing mail
> > > however, it won't solve the multiple-recipients-at-one-domain > > > problem. if qmail relays individual messages via a postfix box, > > > then the postfix box will have individual messages in it's queue - > > > it can't recombine them into one message. i.e. the "damage" has > > > already been done. > > > > I don't quite understand that part about the "damage" already being > > done. For example, if Qmail hands Postfix, say, 10 emails > > (individually, as Qmail does), and 5 of those emails is to the same > > domain/mailserver, wouldn't Postfix "combine" them and send them at > > one time? > > nope, because postfix has no way of knowing that they were originally > the same email(*). postfix has been handed 10 individual emails by > qmail, so it will deliver 10 individual emails. Mmm... but, for example, if it scanned it's queue every 30 seconds, for example, it could then combine them together? I'd assume ISPs and such would have great use for this, especially on web hosting boxes, as overhead in sending numerous emails could be saved? > postfix would be slightly faster than qmail but not that much faster > that it's worth using different software for - unless part of your > purpose is to get some real (as opposed to testing) experience with > postfix to decide whether it's worth switching. Actually, I can't see how Postfix would be at all faster, since it would still be sending individual emails on separate connections. In fact, wouldn't it be slower, since Qmail was optimized specifically for this? > > sendmail isn't a good choice if high-performance is important to you. > overall performance would probably be worse than just keeping things as > they are. (there, that was a very politic way of saying that, wasn't it :) > Hehe... Sendmail was out of the running almost since the beginning, I was just using it as an idea/example. > > if you want to fix this problem, you have to do it at the source - i.e. > replace qmail with postfix on your main boxes. that would be a lot of > work, not something to be done lightly. And certainly not feasible on production systems... unfortunate. But actually, Qmail was the best choice at the time, since it an Vpopmail make such a good incoming email system. > > if you're not using ezmlm, you may be able to hack your list manager to > bypass local qmail and send outgoing messages via SMTP direct to the > postfix box. this may involve hacking the list manager to talk SMTP > rather thank fork /usr/sbin/sendmail, or it may involve replacing > /usr/sbin/sendmail with a wrapper script that talks SMTP. either way, > it's not too hard. Nope... not running ezmlm at all, just a lot of CGIs (through web/Apache) sending emails. Actually... I wonder... is there any drop-in replacement for /usr/sbin/sendmail that would just dump the emails to another server for actual sending? This should not affect receiving email in the least (hence minimize disruption) but would need to be able to dump the emails at a high rate. I'm not sure if there is such a thing though. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Qmail/Postfix/Sendmail for fastest outgoing mail
have a look at zmailer also! if you are limited to choose between the three you quoted, then postfix is the answer. reasons in other posts of this thread... -- .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, admin, and user `. `'` `- Debian - when you have better things to do than fixing a system msg07391/pgp0.pgp Description: PGP signature
Re: Qmail/Postfix/Sendmail for fastest outgoing mail
On Mon, Nov 25, 2002 at 03:01:29PM +1100, Jason Lim wrote: > > however, it won't solve the multiple-recipients-at-one-domain > > problem. if qmail relays individual messages via a postfix box, > > then the postfix box will have individual messages in it's queue - > > it can't recombine them into one message. i.e. the "damage" has > > already been done. > > I don't quite understand that part about the "damage" already being > done. For example, if Qmail hands Postfix, say, 10 emails > (individually, as Qmail does), and 5 of those emails is to the same > domain/mailserver, wouldn't Postfix "combine" them and send them at > one time? nope, because postfix has no way of knowing that they were originally the same email(*). postfix has been handed 10 individual emails by qmail, so it will deliver 10 individual emails. postfix is good, but it's not magic. (*) theoretically, it is possible to scan the headers and/or body to determine this, but postfix doesn't do it and i doubt if anyone would implement it. it's just not worth the dev. time (or the increased size & complexity of code) to do it just to handle this unusual corner-case. > Of course, if there is significant delay between the messages, such as > 1 hour, then obviously Postfix won't wait an hour to collect enough > emails to a particular domain, but say they were sent in succession > (say 2 seconds apart), since these are mailing list servers and email > from the Qmail servers tends to go out in a batch rather than > individually. Wouldn't Postfix combine them in this situation? nope. you might think of them as just one email, but by the time postfix gets them they are multiple different emails. > I was also hoping in some optimization of the actual mail sending as > well... such as what Sendmail or Postfix could offer in this case. If > what you say above is what will happen (emails send individually and > not combined) then in effect setting up the email server as > qmail/sendmail/postfix won't make any difference, since they would be > sent individually anyway? there would be a difference, just not the huge difference you were hoping for. postfix would be slightly faster than qmail but not that much faster that it's worth using different software for - unless part of your purpose is to get some real (as opposed to testing) experience with postfix to decide whether it's worth switching. sendmail isn't a good choice if high-performance is important to you. overall performance would probably be worse than just keeping things as they are. (there, that was a very politic way of saying that, wasn't it :) if you want to fix this problem, you have to do it at the source - i.e. replace qmail with postfix on your main boxes. that would be a lot of work, not something to be done lightly. if you're not using ezmlm, you may be able to hack your list manager to bypass local qmail and send outgoing messages via SMTP direct to the postfix box. this may involve hacking the list manager to talk SMTP rather thank fork /usr/sbin/sendmail, or it may involve replacing /usr/sbin/sendmail with a wrapper script that talks SMTP. either way, it's not too hard. actually, now that i think about it, i remember reading something about getting ezmlm to work with postfix...i didn't pay much attention because it required a qmail box as well as postfix, so it might be just right for your situation. search the postfix-users archive for ezmlm. craig -- craig sanders <[EMAIL PROTECTED]> Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Qmail/Postfix/Sendmail for fastest outgoing mail
Thanks for the input, Craig. > > it'll take the mail delivery load off your multi-purpose boxes, but > won't result in much faster delivery (although you'll get some benefit > simply because you're spreading the same load over more machines). > > however, it won't solve the multiple-recipients-at-one-domain problem. > if qmail relays individual messages via a postfix box, then the postfix > box will have individual messages in it's queue - it can't recombine > them into one message. i.e. the "damage" has already been done. I don't quite understand that part about the "damage" already being done. For example, if Qmail hands Postfix, say, 10 emails (individually, as Qmail does), and 5 of those emails is to the same domain/mailserver, wouldn't Postfix "combine" them and send them at one time? Of course, if there is significant delay between the messages, such as 1 hour, then obviously Postfix won't wait an hour to collect enough emails to a particular domain, but say they were sent in succession (say 2 seconds apart), since these are mailing list servers and email from the Qmail servers tends to go out in a batch rather than individually. Wouldn't Postfix combine them in this situation? > > I'm *thinking* it would because then the Qmail servers would not need > > to create so many simultaneous connections to slow remote hosts > > (waiting around and stuff), and instead would be able to get email off > > faster to the Email box and thus free up load on the Qmail servers, so > > they can do other stuff more (Apache). > > yep, it will get the mail off the qmail boxes ASAP, which will be some > improvement at least. I was also hoping in some optimization of the actual mail sending as well... such as what Sendmail or Postfix could offer in this case. If what you say above is what will happen (emails send individually and not combined) then in effect setting up the email server as qmail/sendmail/postfix won't make any difference, since they would be sent individually anyway? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Qmail/Postfix/Sendmail for fastest outgoing mail
On Mon, Nov 25, 2002 at 01:00:51PM +1100, Jason Lim wrote: > I don't want to spark a flame war or anything... but for purely > outgoing mailing (sending emails), which mail package would be > fastest? if you're using VERP (Variable Envelope Return Path), postfix is a little faster than qmail. if you're not using VERP, postfix is *MUCH* faster than qmail. > I know people have complained about Qmail's way of sending emails... > in that it creates a connection for each email rather than bunching > them up like Sendmail, but then how does Postfix operate > (similar/hybrid)? It hear Postfix does something fancy in that regard > that is a mix or something, but since I'm no Postfix expert, perhaps > someone knows more about this? postfix can do either, depending on how you use it. by default, postfix does the same as sendmail - multiple emails to different recipients at the same domain will be sent in one SMTP session. actually, postfix performs much better than sendmail in this instance because for any given message with multiple recipients, postfix will open multiple connections to *different* servers in parallel, whereas, for the same message, sendmail will open only one connection to each server in turn. if you use VERP for completely automated bounce-detection then postfix will send one message per recipient the same as qmail, even if several recipients are @ the same domain - VERP requires this to work. actually, even sendmail can send one message per recipient, *IFF* your mailing list software sends one message per recipient. qmail and postfix can, by using VERP, do the same even when the mailing list sends only one message with a huge CC or BCC list. to summarise: - qmail *always* sends one message per recipient, whether it makes sense to do so or not. - postfix can do either, depending on what you tell it to do. - sendmail can do either, depending on what it is given to do. > The reason I ask is that we have a number of Qmail servers right now, > and they are heavily loaded because they also run Apache, DNS, and > other stuff. My idea was to get Qmail to send all email quickly to the > "pure Email box" (mail relay), and have the Email box handle all the > actual grunt work of sending to remote hosts. All servers are > connected together by 100Mbps so no bottleneck there. We can't stop > using Qmail on the multi-purpose servers because the whole system is > setup and downtime is unacceptable, but do you think having the Qmail > relay all email to the Email box, then having them actually sent would > benefit? We're talking about 2-3 million emails per day, which the > Qmails have done well so far but because Apache is getting loaded, > Qmail is slowing up and the number of concurrent connections it can > handle has been dropping. it'll take the mail delivery load off your multi-purpose boxes, but won't result in much faster delivery (although you'll get some benefit simply because you're spreading the same load over more machines). however, it won't solve the multiple-recipients-at-one-domain problem. if qmail relays individual messages via a postfix box, then the postfix box will have individual messages in it's queue - it can't recombine them into one message. i.e. the "damage" has already been done. > I'm *thinking* it would because then the Qmail servers would not need > to create so many simultaneous connections to slow remote hosts > (waiting around and stuff), and instead would be able to get email off > faster to the Email box and thus free up load on the Qmail servers, so > they can do other stuff more (Apache). yep, it will get the mail off the qmail boxes ASAP, which will be some improvement at least. craig -- craig sanders <[EMAIL PROTECTED]> Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Qmail vpopmail Courier
Thanks, I'll try that. Christofer On 16 May 2002 15:02 CEST you wrote: > I had this problem also and was unable to get the Courier-IMAP.deb to work > so I marked it as "hold" and then just installed from source. > > Make sure you compile with vpopmail option turned on and in the > configuration, turn off auth-daemon (as mentioned on the vpopmail mailing > list). I don't use "local" users so I haven't had to worry about that and > only list authvchkpw as the only auth module used. > > Hope this helps. > > At 10:31 AM 5/16/2002 , Christofer Algotsson wrote: > >Hi list. > > > >I have a Qmail vpopmail system running on Debian/unstable with no problems. > >I have both real and virtual users on the system. > >For a couple of days I have tried to teach my Courier-IMAP to authenticate > >viritual accounts with no luck. > > > >It seems to me that the Coruier-IMAP .deb is compiled with; > > > >(from the debian-patched source) > >royce@curlin:~/imap/courier-0.37.3$ grep 'vchk' debian/rules > > --without-authvchkpw > > > >However, that module (I think) is needed by Courier's authentication-daemon? > > > >Now. > > > >I added (what I beleve is correct) to /etc/courier/autodaemonrc > > > >authmodulelist="authpam authvchkpw" > > > >authpam (for the users with real accounts) and authvchkpw (for the virtuals). > > > >no success. Still pop3 and IMAP (for real users) works perfectley. > >Login-name for virtual pop3 and IMAP is the same, username@domain as > >login-name. (I've even tried username%domain, with no success). > > > > > >Re-compiling the package --with-authvchkpw resulted in some error with > >/var/lib/vpopmail/etc/lib_deps (wich was not found)... so i touched it and > >tried again.. Now i was missing some other libraries, added them.. and the > >result was compilation-errors. > > > >I read through goggle and tried to find out by myself, but I believe I'm > >stuck. > > > > > >Have anyone got Imap to work with vpop-authentication ? > > > >Please help if you can! > > > >Very best regards, > > > >Christofer > > > > > >-- > >To UNSUBSCRIBE, email to [EMAIL PROTECTED] > >with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Qmail vpopmail Courier
I had this problem also and was unable to get the Courier-IMAP.deb to work so I marked it as "hold" and then just installed from source. Make sure you compile with vpopmail option turned on and in the configuration, turn off auth-daemon (as mentioned on the vpopmail mailing list). I don't use "local" users so I haven't had to worry about that and only list authvchkpw as the only auth module used. Hope this helps. At 10:31 AM 5/16/2002 +, Christofer Algotsson wrote: >Hi list. > >I have a Qmail vpopmail system running on Debian/unstable with no problems. >I have both real and virtual users on the system. >For a couple of days I have tried to teach my Courier-IMAP to authenticate >viritual accounts with no luck. > >It seems to me that the Coruier-IMAP .deb is compiled with; > >(from the debian-patched source) >royce@curlin:~/imap/courier-0.37.3$ grep 'vchk' debian/rules > --without-authvchkpw > >However, that module (I think) is needed by Courier's authentication-daemon? > >Now. > >I added (what I beleve is correct) to /etc/courier/autodaemonrc > >authmodulelist="authpam authvchkpw" > >authpam (for the users with real accounts) and authvchkpw (for the virtuals). > >no success. Still pop3 and IMAP (for real users) works perfectley. >Login-name for virtual pop3 and IMAP is the same, username@domain as >login-name. (I've even tried username%domain, with no success). > > >Re-compiling the package --with-authvchkpw resulted in some error with >/var/lib/vpopmail/etc/lib_deps (wich was not found)... so i touched it and >tried again.. Now i was missing some other libraries, added them.. and the >result was compilation-errors. > >I read through goggle and tried to find out by myself, but I believe I'm >stuck. > > >Have anyone got Imap to work with vpop-authentication ? > >Please help if you can! > >Very best regards, > >Christofer > > >-- >To UNSUBSCRIBE, email to [EMAIL PROTECTED] >with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: qmail
Thus spake Pedro Braga, on Mon, Oct 15, 2001 at 06:10:16PM +0100: > Hello, > I've Debian 2.2 r3 on my servers and I use sendmail, but I want to try > "qmail"! I've been on "http://www.qmail.org"; and the ".deb" link in the > "top.html" page leads me to "top.html#200101270" instead of the file > ".deb". > > Q.: is there a deb package with "qmail"? > Yep, a src package: stable qmail-src 1.03-14 (266.2k) Source only package for building qmail binary package http://packages.debian.org/stable/mail/qmail-src.html > I can always get the "tgz" file, but it would me much better the debian > package... :-) > Blame djb. > -- > Pedro Braga > Eng. Telec./Programador > http://www.iportalmais.pt > > -- Jose Celestino <[EMAIL PROTECTED]> - Weekends were made for programming. - Karl Lehenbauer
Re: qmail
Thus spake Pedro Braga, on Mon, Oct 15, 2001 at 06:10:16PM +0100: > Hello, > I've Debian 2.2 r3 on my servers and I use sendmail, but I want to try > "qmail"! I've been on "http://www.qmail.org"; and the ".deb" link in the > "top.html" page leads me to "top.html#200101270" instead of the file > ".deb". > > Q.: is there a deb package with "qmail"? > Yep, a src package: stable qmail-src 1.03-14 (266.2k) Source only package for building qmail binary package http://packages.debian.org/stable/mail/qmail-src.html > I can always get the "tgz" file, but it would me much better the debian > package... :-) > Blame djb. > -- > Pedro Braga > Eng. Telec./Programador > http://www.iportalmais.pt > > -- Jose Celestino <[EMAIL PROTECTED]> - Weekends were made for programming. - Karl Lehenbauer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Qmail+vpopmail with mailing lists
On qmail-systems you should use ezmlm. Otherwise take a look at Mailman (http://www.list.org) Martin On Wed, 10 Oct 2001, Juha-Matti Tapio wrote: > Our mail environment runs several virtual domains on qmail+vpopmail. Now I > need to setup mailing lists for a few of these domains. > > Any suggestions on what software to use? > > Web-management interface would certainly be nice feature. > > -- > Juha-Matti Tapio, Atk-suunnittelija, puh. 050-5419230 > Kirahvi -domainit Oy, Tekniikantie 21 C, Espoo > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: Qmail+vpopmail with mailing lists
On qmail-systems you should use ezmlm. Otherwise take a look at Mailman (http://www.list.org) Martin On Wed, 10 Oct 2001, Juha-Matti Tapio wrote: > Our mail environment runs several virtual domains on qmail+vpopmail. Now I > need to setup mailing lists for a few of these domains. > > Any suggestions on what software to use? > > Web-management interface would certainly be nice feature. > > -- > Juha-Matti Tapio, Atk-suunnittelija, puh. 050-5419230 > Kirahvi -domainit Oy, Tekniikantie 21 C, Espoo > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Qmail relay control
On Fri, 13 Jul 2001 at 16:51:01 +1000, andy wrote: > > /etc/qmail/rcpthosts No. > man qmail-smtpd Yes :-) . rcpthosts Allowed RCPT domains. If rcpthosts is supplied, qmail-smtpd will reject any envelope recipient address with a domain not listed in rcpthosts. And Alex is looking for a file containing hostnames _from_ which qmail is to relay, not _to_ which. To control it, one must set environment variable RELAYCLIENT. It can be done for instance with tcp-env or tcpserver. See FAQ point 5.4 (or whatever it is numbered nowadays). > On Thu, 12 Jul 2001, Alex Borges wrote: > > > Mhm cant seem to find a file for allowed relay-from hosts on qmail such > > as the one in sendmail i need (as everybody) to deny relaying from > > everywhere but a well defined set of > > ip's. > > > > Please, pretttyplease, prettypleasewithacherryontop help me! > > > > Alex -- Tomasz Papszun SysAdm @ TP S.A. Lodz, Poland | And it's only [EMAIL PROTECTED] http://www.lodz.tpsa.pl/ | ones and zeros. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Qmail relay control
/etc/qmail/rcpthosts man qmail-smtpd On Thu, 12 Jul 2001, Alex Borges wrote: > Mhm cant seem to find a file for allowed relay-from hosts on qmail such > as the one in sendmail i need (as everybody) to deny relaying from > everywhere but a well defined set of > ip's. > > Please, pretttyplease, prettypleasewithacherryontop help me! > > Alex > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Qmail Installation and Configuration
The best qmail reference I ever found was http://www.lifewithqmail.com. To install qmail on debian you should apt-get install qmail-src. Then run build-qmail (or something close to that, apt will tell you what to do). The build-qmail script adds the qmail users and groups and also builds qmail. I haven't done this in a while so please correct me if I am wrong... Greg On Tue, 3 Jul 2001, Florian DUVAL - HostMaster wrote: > Hi Guys ! > > I'm looking for install Qmail, but i don't understand How to ... > Could someone help me pleaze ? > > Florian > > -Message d'origine- > De : jens-ingo brodesser [mailto:[EMAIL PROTECTED] > Envoyé : mardi 3 juillet 2001 12:50 > À : debian-isp@lists.debian.org > Objet : Mysqld dying together with safe_mysql > > > hello, > > i'm experiencing a strange problem with mysqld under debian potato. > it dies almost allways together with the safe_mysql script which is > intended to restart a dead mysql server. > > has anybody an explanation for this strange behavior of the safe_mysql > script ? > > thank you, > > -- > jens-ingo > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- Greg Rowe Paranoia is a virtue. http://www.therowes.net
Re: Qmail Installation and Configuration
The best qmail reference I ever found was http://www.lifewithqmail.com. To install qmail on debian you should apt-get install qmail-src. Then run build-qmail (or something close to that, apt will tell you what to do). The build-qmail script adds the qmail users and groups and also builds qmail. I haven't done this in a while so please correct me if I am wrong... Greg On Tue, 3 Jul 2001, Florian DUVAL - HostMaster wrote: > Hi Guys ! > > I'm looking for install Qmail, but i don't understand How to ... > Could someone help me pleaze ? > > Florian > > -Message d'origine- > De : jens-ingo brodesser [mailto:[EMAIL PROTECTED]] > Envoyé : mardi 3 juillet 2001 12:50 > À : [EMAIL PROTECTED] > Objet : Mysqld dying together with safe_mysql > > > hello, > > i'm experiencing a strange problem with mysqld under debian potato. > it dies almost allways together with the safe_mysql script which is > intended to restart a dead mysql server. > > has anybody an explanation for this strange behavior of the safe_mysql > script ? > > thank you, > > -- > jens-ingo > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact > [EMAIL PROTECTED] > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- Greg Rowe Paranoia is a virtue. http://www.therowes.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Qmail errors
Outlook ignores the SMTP spec by not enclosing the e-mail addresses in angle brackets (although microsoft blames "older mail server systems"): http://support.microsoft.com/support/kb/articles/Q197/4/17.ASP?LN=EN-US&SD=gn&FR=0 Djb did a workaround for this (stupid RFC ignorant clients) on qmail version 1.03, install it. Thus spake Robert Ruzbacky, on Mon, Jul 02, 2001 at 08:59:28PM +1000: > Currently I am having a problem with qmail. Our users are getting the > following error when sending mail via SMTP: > > > "No transport provider was available for delivery to this recipient" > > The client they are using is Microsoft Outlook. I can send via Outlook > express, and it works fine on my machine. I check the qmail logs, but cannot > find any bounce message. The error bounces back to the user with systems > administrator as the user. With Microsoft Outlook, internet email is enabled > as well as Microsoft Mail (the old win3.11 pop system) for internal mail. > > Any ideas? I am running a debian 1.3 server with qmail being v1.02. > > > Thanks > > Rob.. > > -- Jose Celestino <[EMAIL PROTECTED]> - "Existence takes is toll, extinction unfolds, The Colossus falls back from its threshold" -- Borknagar - Colossus
Re: Qmail errors
Outlook ignores the SMTP spec by not enclosing the e-mail addresses in angle brackets (although microsoft blames "older mail server systems"): http://support.microsoft.com/support/kb/articles/Q197/4/17.ASP?LN=EN-US&SD=gn&FR=0 Djb did a workaround for this (stupid RFC ignorant clients) on qmail version 1.03, install it. Thus spake Robert Ruzbacky, on Mon, Jul 02, 2001 at 08:59:28PM +1000: > Currently I am having a problem with qmail. Our users are getting the following >error when sending mail via SMTP: > > > "No transport provider was available for delivery to this recipient" > > The client they are using is Microsoft Outlook. I can send via Outlook express, and >it works fine on my machine. I check the qmail logs, but cannot find any bounce >message. The error bounces back to the user with systems administrator as the user. >With Microsoft Outlook, internet email is enabled as well as Microsoft Mail (the old >win3.11 pop system) for internal mail. > > Any ideas? I am running a debian 1.3 server with qmail being v1.02. > > > Thanks > > Rob.. > > -- Jose Celestino <[EMAIL PROTECTED]> - "Existence takes is toll, extinction unfolds, The Colossus falls back from its threshold" -- Borknagar - Colossus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Qmail - huge performance increase
On Wed, Jun 27, 2001 at 04:03:11PM +0200, Tomasz Papszun wrote: > "/bin/ls | wc" has taken 1 (one) second. "ls | wc" lasted 3 minutes and 26 > seconds. Yes, near 3 and a half minutes! > > This is because "ls" with additional information (e.g. file type, which is > needed to colour a listing) needs more time to gather this information. > I don't know what difference would be for reiserfs or xfs filesystems. yep. ls -l also takes a long time in large directories because it has to stat each file to get the info about it. i never bothered timing it, but in a directory with thousands of files it is significantly faster to run this: ls -1S | head -30 | xargs ls -lS ^ -- numeral 1, not letter l. than this: ls -lS | head -30 btw, in case you're wondering, i used to use commands like that to find the largest 30 files in /var/spool/mail craig -- craig sanders <[EMAIL PROTECTED]> Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch
Re: Qmail - huge performance increase
On Wed, Jun 27, 2001 at 04:03:11PM +0200, Tomasz Papszun wrote: > "/bin/ls | wc" has taken 1 (one) second. "ls | wc" lasted 3 minutes and 26 > seconds. Yes, near 3 and a half minutes! > > This is because "ls" with additional information (e.g. file type, which is > needed to colour a listing) needs more time to gather this information. > I don't know what difference would be for reiserfs or xfs filesystems. yep. ls -l also takes a long time in large directories because it has to stat each file to get the info about it. i never bothered timing it, but in a directory with thousands of files it is significantly faster to run this: ls -1S | head -30 | xargs ls -lS ^ -- numeral 1, not letter l. than this: ls -lS | head -30 btw, in case you're wondering, i used to use commands like that to find the largest 30 files in /var/spool/mail craig -- craig sanders <[EMAIL PROTECTED]> Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Qmail - huge performance increase
And on an Ultra-60 running Solaris 7 w/UFS: bash-2.04$ time /bin/ls | wc 63975 63975 1971245 real0m2.213s user0m1.160s sys 0m0.890s bash-2.04$ time ls | wc 63975 63975 1971253 real2m19.965s user0m1.490s sys 0m16.340s bash-2.04$ Sped it up "just a little bit" :-) On Wednesday 27 June 2001 07:03, Tomasz Papszun wrote: > On Thu, 21 Jun 2001 at 13:25:17 +1000, Craig Sanders wrote: > > On Thu, Jun 21, 2001 at 01:45:23AM +0800, Jason Lim wrote: > > > SO... by increasing conf-split to 97 (from the default of 20 > > > something afaik), each directory ends up only having a hundred or so > > > files. Doing "ls" now is far speedier. > > > [...] > > > > this is actually a well-known limitation of ext2fs and similar > > file-systems - as soon as you get more than a thousand or so files in a > > directory, performance takes a nosedive. > > BTW, a tip: if you've got "ls" aliased (for instance as > 'ls --color=auto -F') then you can shorten this long execution of "ls". > Just issue "/bin/ls" instead of "ls". The difference is very big. It can > be as 1:200 (yeah!). I've just done a comparison in a directory > with > 33000 files. > > "/bin/ls | wc" has taken 1 (one) second. "ls | wc" lasted 3 minutes and 26 > seconds. Yes, near 3 and a half minutes! > > This is because "ls" with additional information (e.g. file type, which is > needed to colour a listing) needs more time to gather this information. > I don't know what difference would be for reiserfs or xfs filesystems. > > Hope it helps a little :-) . -- "To me vi is Zen. To use vi is to practice zen. Every command is a koan. Profound to the user, unintelligible to the uninitiated. You discover truth everytime you use it." [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Qmail - huge performance increase
On Thu, 21 Jun 2001 at 13:25:17 +1000, Craig Sanders wrote: > On Thu, Jun 21, 2001 at 01:45:23AM +0800, Jason Lim wrote: > > SO... by increasing conf-split to 97 (from the default of 20 > > something afaik), each directory ends up only having a hundred or so > > files. Doing "ls" now is far speedier. > > [...] > > this is actually a well-known limitation of ext2fs and similar > file-systems - as soon as you get more than a thousand or so files in a > directory, performance takes a nosedive. > BTW, a tip: if you've got "ls" aliased (for instance as 'ls --color=auto -F') then you can shorten this long execution of "ls". Just issue "/bin/ls" instead of "ls". The difference is very big. It can be as 1:200 (yeah!). I've just done a comparison in a directory with > 33000 files. "/bin/ls | wc" has taken 1 (one) second. "ls | wc" lasted 3 minutes and 26 seconds. Yes, near 3 and a half minutes! This is because "ls" with additional information (e.g. file type, which is needed to colour a listing) needs more time to gather this information. I don't know what difference would be for reiserfs or xfs filesystems. Hope it helps a little :-) . -- Tomasz Papszun SysAdm @ TP S.A. Lodz, Poland | And it's only [EMAIL PROTECTED] http://www.lodz.tpsa.pl/ | ones and zeros.
Re: Qmail - huge performance increase
And on an Ultra-60 running Solaris 7 w/UFS: bash-2.04$ time /bin/ls | wc 63975 63975 1971245 real0m2.213s user0m1.160s sys 0m0.890s bash-2.04$ time ls | wc 63975 63975 1971253 real2m19.965s user0m1.490s sys 0m16.340s bash-2.04$ Sped it up "just a little bit" :-) On Wednesday 27 June 2001 07:03, Tomasz Papszun wrote: > On Thu, 21 Jun 2001 at 13:25:17 +1000, Craig Sanders wrote: > > On Thu, Jun 21, 2001 at 01:45:23AM +0800, Jason Lim wrote: > > > SO... by increasing conf-split to 97 (from the default of 20 > > > something afaik), each directory ends up only having a hundred or so > > > files. Doing "ls" now is far speedier. > > > [...] > > > > this is actually a well-known limitation of ext2fs and similar > > file-systems - as soon as you get more than a thousand or so files in a > > directory, performance takes a nosedive. > > BTW, a tip: if you've got "ls" aliased (for instance as > 'ls --color=auto -F') then you can shorten this long execution of "ls". > Just issue "/bin/ls" instead of "ls". The difference is very big. It can > be as 1:200 (yeah!). I've just done a comparison in a directory > with > 33000 files. > > "/bin/ls | wc" has taken 1 (one) second. "ls | wc" lasted 3 minutes and 26 > seconds. Yes, near 3 and a half minutes! > > This is because "ls" with additional information (e.g. file type, which is > needed to colour a listing) needs more time to gather this information. > I don't know what difference would be for reiserfs or xfs filesystems. > > Hope it helps a little :-) . -- "To me vi is Zen. To use vi is to practice zen. Every command is a koan. Profound to the user, unintelligible to the uninitiated. You discover truth everytime you use it." [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Qmail - huge performance increase
On Thu, 21 Jun 2001 at 13:25:17 +1000, Craig Sanders wrote: > On Thu, Jun 21, 2001 at 01:45:23AM +0800, Jason Lim wrote: > > SO... by increasing conf-split to 97 (from the default of 20 > > something afaik), each directory ends up only having a hundred or so > > files. Doing "ls" now is far speedier. > > [...] > > this is actually a well-known limitation of ext2fs and similar > file-systems - as soon as you get more than a thousand or so files in a > directory, performance takes a nosedive. > BTW, a tip: if you've got "ls" aliased (for instance as 'ls --color=auto -F') then you can shorten this long execution of "ls". Just issue "/bin/ls" instead of "ls". The difference is very big. It can be as 1:200 (yeah!). I've just done a comparison in a directory with > 33000 files. "/bin/ls | wc" has taken 1 (one) second. "ls | wc" lasted 3 minutes and 26 seconds. Yes, near 3 and a half minutes! This is because "ls" with additional information (e.g. file type, which is needed to colour a listing) needs more time to gather this information. I don't know what difference would be for reiserfs or xfs filesystems. Hope it helps a little :-) . -- Tomasz Papszun SysAdm @ TP S.A. Lodz, Poland | And it's only [EMAIL PROTECTED] http://www.lodz.tpsa.pl/ | ones and zeros. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Qmail - huge performance increase
On Thu, Jun 21, 2001 at 01:45:23AM +0800, Jason Lim wrote: > SO... by increasing conf-split to 97 (from the default of 20 > something afaik), each directory ends up only having a hundred or so > files. Doing "ls" now is far speedier. > > I couldn't find any documentation anywhere stating this, so I'll share > it with you all :-) this is actually a well-known limitation of ext2fs and similar file-systems - as soon as you get more than a thousand or so files in a directory, performance takes a nosedive. you can see this effect on news servers such as INN and also mail servers which use Maildir when the users keep thousands of messages in the one "folder", and in mail servers with many thousands of messages in the queue...in fact, in any application which has lots of files in one directory. i'd recommend using reiserfs or perhaps xfs for these applications. this is one of the major advantages that a modern filesystem like reiserfs has over ext2 - you can have as many files as you want in a directory and it doesn't suffer from this slowdown. reiserfs is included in kernel 2.4.x now, and SGI's linux port of their xfs is available as a patch. i've been using reiserfs on production servers for ages with no problems (even using it on mission critical mail servers), and have been trialling xfs since the 1.0 release...with no problems so far, so i'm starting to use it on non-mission-critical servers (e.g. my anonymous ftp server / debian mirror). if it lives up to expectations, i'll start replacing reiserfs with xfs over the next 6-12 months. BTW, even sendmail lets you set the hash queue depth (to use postfix terminology, which i am more comfortable with :) these days. sendmail used to have just one directory for all queue fileswhich made for lousy performance. craig -- craig sanders <[EMAIL PROTECTED]> Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch
Re: Qmail - huge performance increase
On Thu, Jun 21, 2001 at 01:45:23AM +0800, Jason Lim wrote: > SO... by increasing conf-split to 97 (from the default of 20 > something afaik), each directory ends up only having a hundred or so > files. Doing "ls" now is far speedier. > > I couldn't find any documentation anywhere stating this, so I'll share > it with you all :-) this is actually a well-known limitation of ext2fs and similar file-systems - as soon as you get more than a thousand or so files in a directory, performance takes a nosedive. you can see this effect on news servers such as INN and also mail servers which use Maildir when the users keep thousands of messages in the one "folder", and in mail servers with many thousands of messages in the queue...in fact, in any application which has lots of files in one directory. i'd recommend using reiserfs or perhaps xfs for these applications. this is one of the major advantages that a modern filesystem like reiserfs has over ext2 - you can have as many files as you want in a directory and it doesn't suffer from this slowdown. reiserfs is included in kernel 2.4.x now, and SGI's linux port of their xfs is available as a patch. i've been using reiserfs on production servers for ages with no problems (even using it on mission critical mail servers), and have been trialling xfs since the 1.0 release...with no problems so far, so i'm starting to use it on non-mission-critical servers (e.g. my anonymous ftp server / debian mirror). if it lives up to expectations, i'll start replacing reiserfs with xfs over the next 6-12 months. BTW, even sendmail lets you set the hash queue depth (to use postfix terminology, which i am more comfortable with :) these days. sendmail used to have just one directory for all queue fileswhich made for lousy performance. craig -- craig sanders <[EMAIL PROTECTED]> Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Qmail
On Wed, Dec 06, 2000 at 06:26:50PM +0100, Guido Bozzetto wrote: > > > > Qmail is, by default, sending double-bounces to postmaster@server if the >email-address at @server is incorrect and the address is invalid. > > > > Is there any way to disable double bounces for certain domains? > > > with .qmail-default !!! > I use the vchkpw and vpopmail for virtual POP3 mail server. Well > in this case to avoid collecting bouncing email I've changed the > .qmail-default of the virtual domain from > > | /usr/bin/vdelivermail '' /var/state/vchkpw/domains//postmaster > > to > > | /usr/bin/vdelivermail > > Another way is to make an empty ~alias/.qmail-default or create a > .qmail-default with: > > | exit 0 > > and so on. > I hope that this is usefull. Thanks. -- Christofer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Qmail
Christofer Algotsson wrote: > > Hello list! > > Qmail is, by default, sending double-bounces to postmaster@server if the >email-address at @server is incorrect and the address is invalid. > > Is there any way to disable double bounces for certain domains? > > Yours, > Christofer with .qmail-default !!! I use the vchkpw and vpopmail for virtual POP3 mail server. Well in this case to avoid collecting bouncing email I've changed the .qmail-default of the virtual domain from | /usr/bin/vdelivermail '' /var/state/vchkpw/domains//postmaster to | /usr/bin/vdelivermail Another way is to make an empty ~alias/.qmail-default or create a .qmail-default with: | exit 0 and so on. I hope that this is usefull. Guido. -- |Guido Bozzetto|Office ph./fax:+39 0432 477588/486157| | \/ I|E-mail: :-) mailto:[EMAIL PROTECTED]| Il puâr content | OO like |Web: http://www.e-company.it/gb/| al è avonde siôr + -- Linux -- +-- Advertising: http://www.gnu.org --+ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Qmail and Debian
On Wed, Sep 13, 2000 at 12:10:30PM -0600, Art Sackett wrote: > On Wed, Sep 13, 2000 at 10:19:48AM -0500, Nathan E Norman wrote: > > > > Huh? Why would you need to deinstall at, mailx, logrotate and mail > > readers in the first place? > > Well, you wouldn't *need* to, strictly speaking, but if you remove > exim, those things that depend upon mail-transport-agent will want > to go with it unless you work around it somehow. > > I'm one who'd just as soon never use dpkg --force, and can't see > installing the equivs package when I'm only going to need it for > about a minute. So don't use dpkg --force ... use dpkg --ignore-depends. It's the only way to fly when doing stuff like this. -- Nathan E Norman "Eschew Obfuscation" email:[EMAIL PROTECTED] http://incanus.net/~nnorman Please don't Cc: me on list mail pgp6FgAfJaDlE.pgp Description: PGP signature
Re: Qmail and Debian
On Wed, Sep 13, 2000 at 12:10:30PM -0600, Art Sackett wrote: > On Wed, Sep 13, 2000 at 10:19:48AM -0500, Nathan E Norman wrote: > > > > Huh? Why would you need to deinstall at, mailx, logrotate and mail > > readers in the first place? > > Well, you wouldn't *need* to, strictly speaking, but if you remove > exim, those things that depend upon mail-transport-agent will want > to go with it unless you work around it somehow. > > I'm one who'd just as soon never use dpkg --force, and can't see > installing the equivs package when I'm only going to need it for > about a minute. So don't use dpkg --force ... use dpkg --ignore-depends. It's the only way to fly when doing stuff like this. -- Nathan E Norman "Eschew Obfuscation" email:[EMAIL PROTECTED] http://incanus.net/~nnorman Please don't Cc: me on list mail PGP signature
Re: Qmail and Debian
On Wed, Sep 13, 2000 at 10:19:48AM -0500, Nathan E Norman wrote: > > Huh? Why would you need to deinstall at, mailx, logrotate and mail > readers in the first place? Well, you wouldn't *need* to, strictly speaking, but if you remove exim, those things that depend upon mail-transport-agent will want to go with it unless you work around it somehow. I'm one who'd just as soon never use dpkg --force, and can't see installing the equivs package when I'm only going to need it for about a minute. Art Sackett
Re: Qmail and Debian
On Wed, 13 Sep 2000, Nathan E Norman wrote: > On Tue, Sep 12, 2000 at 04:59:12PM -0600, Art Sackett wrote: > > I haven't tried any of the web-based stuff, but have found that the > > .debs of ucspi-tcp, ezmlm, rmlsmtpd, fastforward, and vchkpw have > > all gone in flawlessly. Well, almost -- there's still a niggling > > little problem where any other existing mail-transport-agent being > > on the system will cause dpkg to bail out thinking qmail causes a > > conflict. So after yanking out the default exim, you have to go back > > and reinstall any you need of at, mailx, logrotate, and mail readers. > > There may be others, which will be installation dependent. > > Huh? Why would you need to deinstall at, mailx, logrotate and mail > readers in the first place? > No need, really. :) Compile qmail from qmail-src, and ucspi-tcp from ucspi-tcp-src. # dpkg --ignore-depends=mail-transfer-agent \ --ignore-depends=mail-transport-agent --purge exim ... # dpkg -i ucspi-tcp qmail That's all :) Robert Varga
Re: Qmail and Debian
On Wed, Sep 13, 2000 at 10:19:48AM -0500, Nathan E Norman wrote: > > Huh? Why would you need to deinstall at, mailx, logrotate and mail > readers in the first place? Well, you wouldn't *need* to, strictly speaking, but if you remove exim, those things that depend upon mail-transport-agent will want to go with it unless you work around it somehow. I'm one who'd just as soon never use dpkg --force, and can't see installing the equivs package when I'm only going to need it for about a minute. Art Sackett -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Qmail and Debian
On Wed, 13 Sep 2000, Nathan E Norman wrote: > On Tue, Sep 12, 2000 at 04:59:12PM -0600, Art Sackett wrote: > > I haven't tried any of the web-based stuff, but have found that the > > .debs of ucspi-tcp, ezmlm, rmlsmtpd, fastforward, and vchkpw have > > all gone in flawlessly. Well, almost -- there's still a niggling > > little problem where any other existing mail-transport-agent being > > on the system will cause dpkg to bail out thinking qmail causes a > > conflict. So after yanking out the default exim, you have to go back > > and reinstall any you need of at, mailx, logrotate, and mail readers. > > There may be others, which will be installation dependent. > > Huh? Why would you need to deinstall at, mailx, logrotate and mail > readers in the first place? > No need, really. :) Compile qmail from qmail-src, and ucspi-tcp from ucspi-tcp-src. # dpkg --ignore-depends=mail-transfer-agent \ --ignore-depends=mail-transport-agent --purge exim ... # dpkg -i ucspi-tcp qmail That's all :) Robert Varga -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Qmail and Debian
On Tue, Sep 12, 2000 at 04:59:12PM -0600, Art Sackett wrote: > I haven't tried any of the web-based stuff, but have found that the > .debs of ucspi-tcp, ezmlm, rmlsmtpd, fastforward, and vchkpw have > all gone in flawlessly. Well, almost -- there's still a niggling > little problem where any other existing mail-transport-agent being > on the system will cause dpkg to bail out thinking qmail causes a > conflict. So after yanking out the default exim, you have to go back > and reinstall any you need of at, mailx, logrotate, and mail readers. > There may be others, which will be installation dependent. Huh? Why would you need to deinstall at, mailx, logrotate and mail readers in the first place? -- Nathan E Norman "Eschew Obfuscation" email:[EMAIL PROTECTED] http://incanus.net/~nnorman pgpJeWOLRgwYx.pgp Description: PGP signature
Re: Qmail and Debian
On Tue, Sep 12, 2000 at 04:59:12PM -0600, Art Sackett wrote: > I haven't tried any of the web-based stuff, but have found that the > .debs of ucspi-tcp, ezmlm, rmlsmtpd, fastforward, and vchkpw have > all gone in flawlessly. Well, almost -- there's still a niggling > little problem where any other existing mail-transport-agent being > on the system will cause dpkg to bail out thinking qmail causes a > conflict. So after yanking out the default exim, you have to go back > and reinstall any you need of at, mailx, logrotate, and mail readers. > There may be others, which will be installation dependent. Huh? Why would you need to deinstall at, mailx, logrotate and mail readers in the first place? -- Nathan E Norman "Eschew Obfuscation" email:[EMAIL PROTECTED] http://incanus.net/~nnorman PGP signature
Re: Qmail and Debian
On Tue, Sep 12, 2000 at 03:08:43PM -0700, Eric Jennings wrote: > As for qmail, I attempted an install of qmail from dselect, and I had > nothing but problems. After several days of pulling my hair out, I > opted to download the qmail source from qmail.org and install from > scratch. The current .deb (for potato) works well -- apparently somebody fixed the problem (not setting the execute bits on the files in /tmp/qmail/ needed for proper compilation). > Sure enough, it works flawlessly. Since then we've > installed ezmlm, and a slew of web-based admin tools for each. I haven't tried any of the web-based stuff, but have found that the .debs of ucspi-tcp, ezmlm, rmlsmtpd, fastforward, and vchkpw have all gone in flawlessly. Well, almost -- there's still a niggling little problem where any other existing mail-transport-agent being on the system will cause dpkg to bail out thinking qmail causes a conflict. So after yanking out the default exim, you have to go back and reinstall any you need of at, mailx, logrotate, and mail readers. There may be others, which will be installation dependent. It might also be handy if the rblsmtpd installer modified /etc/init.d/qmail to put the thing to work, which now requires going in and manually editing. It's easy if you know to do it, but it would be easier if the installer asked which services you wanted to enable. Art Sackett
Re: Qmail and Debian
umm, vpopmail first. I installed the latest version from source, and it was seamless. I did not use a debian package to install it. As for qmail, I attempted an install of qmail from dselect, and I had nothing but problems. After several days of pulling my hair out, I opted to download the qmail source from qmail.org and install from scratch. Sure enough, it works flawlessly. Since then we've installed ezmlm, and a slew of web-based admin tools for each. It was only later that week that someone mentioned that the qmail .deb packages are broken. That's why I decided to install vpopmail from scratch as well. It takes a bit longer, but you *know* you have a clean good install. Eric Hi, just a quick email to find out. 1. is the vchkpw/vpopmial package still being maintained under Debian, doesn't look like it as vchkpw is several versions behind what is on the inter7 site. 2. is there still a qmail list for Debian that anyone knows about. etc Have been using exim for the last 12 months or so but require a switch to qmail and just seeing where Debian's possition on it was. Any info greatly appreciated. From Mitchell -- Eric JenningsDirector of Internet Strategy Loopshot, LLC P.O. Box 71388 | Reno, NV 89570 | 775.856.3455 [EMAIL PROTECTED] http://www.loopshot.com
Re: Qmail and Debian
On Tue, Sep 12, 2000 at 03:08:43PM -0700, Eric Jennings wrote: > As for qmail, I attempted an install of qmail from dselect, and I had > nothing but problems. After several days of pulling my hair out, I > opted to download the qmail source from qmail.org and install from > scratch. The current .deb (for potato) works well -- apparently somebody fixed the problem (not setting the execute bits on the files in /tmp/qmail/ needed for proper compilation). > Sure enough, it works flawlessly. Since then we've > installed ezmlm, and a slew of web-based admin tools for each. I haven't tried any of the web-based stuff, but have found that the .debs of ucspi-tcp, ezmlm, rmlsmtpd, fastforward, and vchkpw have all gone in flawlessly. Well, almost -- there's still a niggling little problem where any other existing mail-transport-agent being on the system will cause dpkg to bail out thinking qmail causes a conflict. So after yanking out the default exim, you have to go back and reinstall any you need of at, mailx, logrotate, and mail readers. There may be others, which will be installation dependent. It might also be handy if the rblsmtpd installer modified /etc/init.d/qmail to put the thing to work, which now requires going in and manually editing. It's easy if you know to do it, but it would be easier if the installer asked which services you wanted to enable. Art Sackett -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Qmail and Debian
umm, vpopmail first. I installed the latest version from source, and it was seamless. I did not use a debian package to install it. As for qmail, I attempted an install of qmail from dselect, and I had nothing but problems. After several days of pulling my hair out, I opted to download the qmail source from qmail.org and install from scratch. Sure enough, it works flawlessly. Since then we've installed ezmlm, and a slew of web-based admin tools for each. It was only later that week that someone mentioned that the qmail .deb packages are broken. That's why I decided to install vpopmail from scratch as well. It takes a bit longer, but you *know* you have a clean good install. Eric >Hi, just a quick email to find out. > >1. is the vchkpw/vpopmial package still being maintained under Debian, >doesn't look like it as vchkpw is several versions behind what is on the >inter7 site. > >2. is there still a qmail list for Debian that anyone knows about. > >etc > > >Have been using exim for the last 12 months or so but require a switch >to qmail and just seeing where Debian's possition on it was. > >Any info greatly appreciated. > >From Mitchell > -- Eric JenningsDirector of Internet Strategy Loopshot, LLC P.O. Box 71388 | Reno, NV 89570 | 775.856.3455 [EMAIL PROTECTED] http://www.loopshot.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Qmail Environment
On Fri, 4 Aug 2000, Florian Lohoff wrote: | > Just wanted to know if there was a Debian way of installing qmail for a | > large ISP environment :) I haven´t seemed to found any info on | > partitioning recomendations, and such and such... Any ideas ? | | The lack of answers might be due to a IMHO immense shift from | qmail to postfix - Identical performance but even my Mum can configure | it which becomes more important the larger the company gets ... | | I am using postfix on ~300 Maschines and i am VERY happy with it. | | Flo I seriously doubt that more likely is the fact that the qmail admins are not really reading the debian list. I run qmail and love it, adminning the system is easy, fast, reliable and secure... Might want to join the qmail list for qmail related questions tho, www.qmail.org -- ___ _ __ _ __ /___ ___ /__ John Gonzalez/Net.Tech __ __ \ __ \ __/_ __ `__ \/ __ /_ ___/ MDC Computers/netMDC! _ / / / `__/ /_ / / / / / / /_/ / / /__ (505)437-7600/fax-437-3052 /_/ /_/\___/\__/ /_/ /_/ /_/\__,_/ \___/ http://www.netmdc.com [-[system info]---] 6:45pm up 88 days, 48 min, 3 users, load average: 0.08, 0.05, 0.05
Re: Qmail Environment
On Fri, 4 Aug 2000, Florian Lohoff wrote: | > Just wanted to know if there was a Debian way of installing qmail for a | > large ISP environment :) I haven´t seemed to found any info on | > partitioning recomendations, and such and such... Any ideas ? | | The lack of answers might be due to a IMHO immense shift from | qmail to postfix - Identical performance but even my Mum can configure | it which becomes more important the larger the company gets ... | | I am using postfix on ~300 Maschines and i am VERY happy with it. | | Flo I seriously doubt that more likely is the fact that the qmail admins are not really reading the debian list. I run qmail and love it, adminning the system is easy, fast, reliable and secure... Might want to join the qmail list for qmail related questions tho, www.qmail.org -- ___ _ __ _ __ /___ ___ /__ John Gonzalez/Net.Tech __ __ \ __ \ __/_ __ `__ \/ __ /_ ___/ MDC Computers/netMDC! _ / / / `__/ /_ / / / / / / /_/ / / /__ (505)437-7600/fax-437-3052 /_/ /_/\___/\__/ /_/ /_/ /_/\__,_/ \___/ http://www.netmdc.com [-[system info]---] 6:45pm up 88 days, 48 min, 3 users, load average: 0.08, 0.05, 0.05 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Qmail Environment
On Thu, Aug 03, 2000 at 10:31:37AM +0200, Neil D. Roberts wrote: > Hi ! > > Just wanted to know if there was a Debian way of installing qmail for a > large ISP environment :) I haven´t seemed to found any info on > partitioning recomendations, and such and such... Any ideas ? The lack of answers might be due to a IMHO immense shift from qmail to postfix - Identical performance but even my Mum can configure it which becomes more important the larger the company gets ... I am using postfix on ~300 Maschines and i am VERY happy with it. Flo -- Florian Lohoff [EMAIL PROTECTED] +49-5201-669912 "If you're not having fun right now, you're wasting your time."
Re: Qmail Environment
On Thu, Aug 03, 2000 at 10:31:37AM +0200, Neil D. Roberts wrote: > Hi ! > > Just wanted to know if there was a Debian way of installing qmail for a > large ISP environment :) I haven´t seemed to found any info on > partitioning recomendations, and such and such... Any ideas ? The lack of answers might be due to a IMHO immense shift from qmail to postfix - Identical performance but even my Mum can configure it which becomes more important the larger the company gets ... I am using postfix on ~300 Maschines and i am VERY happy with it. Flo -- Florian Lohoff [EMAIL PROTECTED] +49-5201-669912 "If you're not having fun right now, you're wasting your time." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
