Re: sendmail is slow for mass mail
Craig Sanders wrote: > i see qmail's incompatibility with other MTAs as a huge trap - and the > same kind of trap as proprietary mailers, or proprietary software in > generalonce you convert to it, you're basically stuck there because > it's going to be an enormous pain to convert to anything else. That's very true. My qmail system served only a few users, a few ezmlm mailing lists; probably 300 .qmail files total -- and it took me 24 hours solid to convert it to postfix with no downtime. I had a transition plan with 30 or so items on it, and only maybe 3 of those hours were spent in grokking postfix; it was crazy. Never again. -- see shy jo
Re: sendmail is slow for mass mail
Craig Sanders wrote: > i see qmail's incompatibility with other MTAs as a huge trap - and the > same kind of trap as proprietary mailers, or proprietary software in > generalonce you convert to it, you're basically stuck there because > it's going to be an enormous pain to convert to anything else. That's very true. My qmail system served only a few users, a few ezmlm mailing lists; probably 300 .qmail files total -- and it took me 24 hours solid to convert it to postfix with no downtime. I had a transition plan with 30 or so items on it, and only maybe 3 of those hours were spent in grokking postfix; it was crazy. Never again. -- see shy jo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sendmail is slow for mass mail
On Tue, Apr 03, 2001 at 09:42:01AM -0400, Richard A Nelson wrote: > Sendmail *is* the kitchen sink of MTAs [...] if sendmail is the kitchen-sink then postfix is the dish-washer. an hour of drudgery with your hands in filthy water versus push-button automation. :-) craig -- craig sanders <[EMAIL PROTECTED]> GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: sendmail is slow for mass mail
On Tue, Apr 03, 2001 at 09:42:01AM -0400, Richard A Nelson wrote: > On Tue, 3 Apr 2001, Craig Sanders wrote: > > * it's slow. > > * it doesn't scale well. > > Short: FUD, spread by one who's not kept up with current developements - > Look at whats being done in 8.12 wrt multi-queues and > multi-runners/queue. 8.12 is faster than 8.9.3 ever was (much faster > than 8.10/11), and has a hell of lot more function that's not saying a lot. > Long: Sendmail was basically in `maintenance' mode for several years, > and a few of its competitors (who didn't have legacy concerns) were able > to leapfrog it in performance and scalability. Sendmail has had quite > a bit of rework... read as: bugger all was done on sendmail for years until the authors noticed that: a) people had got sick of all it's problems and written vastly superior alternatives like qmail and then postfix and, more importantly, b) there was a chance to become dot-com millionaires. too little, too late. > No, but it has come a long way since then, a significant portion has > been rewritten since 8.9.3 The last incident I can recall turned out > to actually be the kernel capability bug... too little, too late. > > * it's configuration language is overly complex for the task at hand > > (the m4 macros helped a lot, but it's still way more complex than it > > needs to be) > > Depends upon the task at hand eh? For a end-node, sure sendmail.cf > hacking isn't needed - sendmail.cf hacking is never needed. anything you can do with .cf hackery can be done in postfix with plain-english configuration and appropriate use of map files. > but the provided m4 features cover that pretty > well with FEATURE(nullclient, `') -- what could be easier. "relayhost = smart.host.example.com" in /etc/postfix/main.cf and you've got to admit - m4 isn't exactly the easiest or most pleasant of languages to work with...in fact, it's ugly. and that's sendmail's *easier* configuration style. > Sendmail *is* the kitchen sink of MTAs - and yes, there is a cost to > that, but significant tuning *is* going on... The other side is that > with the kitchen sink comes everything: you miss the point. you don't *need* anything near as complicated as sendmail.cf or even sendmail.mc to provide the features of sendmail. > Mixing/matching of DB, LDAP, text, HESIOD, PH (not on Debian), etc. > for *ANY* map: aliases, access, etc. postfix does all that and more: including mysql, postgres maps, posix and pcre regexp maps and more. > Why suffer with `sendmail compatible' when you can have the > `REAL thing'? because the 'REAL thing' sucks. postfix isn't sendmail-compatible because sendmail is the pinnacle of MTAs and must be emulated. postfix is sendmail-compatible because there are a lot of people running sendmail systems who will not change from their legacy software if it requires a complete re-implementation of their mail system...qmail proved that. why suffer with sendmail when you can have postfix, which can do everything that sendmail can do only faster and better and securely? look, if you're happy to use obsolete software that's fine by me, doesn't bother me at all...but to insist that it's anywhere near as good as the alternatives is annoying and ridiculous. sendmail had it's day. that day is over. it should just retire gracefully. the phrase "mutton dressed up as lamb" seems appropriate - sendmail's recent facelifts are like an old woman whacking on way too much makeup and pretending/insisting she's as young and pretty as the 20 year olds. it really doesn't fool many people. craig -- craig sanders <[EMAIL PROTECTED]> GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: sendmail is slow for mass mail
On Tue, Apr 03, 2001 at 09:42:01AM -0400, Richard A Nelson wrote: > Mixing/matching of DB, LDAP, text, HESIOD, PH (not on Debian), etc. > for *ANY* map: aliases, access, etc. Ah, but postfix does that, and does it better, adding posix and pcre regex's and SQL or whatever to the mix. > Why suffer with `sendmail compatible' when you can have the `REAL > thing'? Because Postfix is simpler, therefore easier to audit and trust. It runs less stuff as root. It isn't a fight to make it run chrooted (and even does so as default in Debian) and generally is trivial to make it do stupid mta tricks. After installing it on a couple play machines, it was the obvious replacement for sendmail... fast, trustworthy, and a pleasure to play with. (The code is actually understandable!) Oh, and I'd trust Wietse with a root shell on any of my machines.
Re: sendmail is slow for mass mail
On Tue, Apr 03, 2001 at 09:42:01AM -0400, Richard A Nelson wrote: > Sendmail *is* the kitchen sink of MTAs [...] if sendmail is the kitchen-sink then postfix is the dish-washer. an hour of drudgery with your hands in filthy water versus push-button automation. :-) craig -- craig sanders <[EMAIL PROTECTED]> GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sendmail is slow for mass mail
On Tue, Apr 03, 2001 at 09:42:01AM -0400, Richard A Nelson wrote: > On Tue, 3 Apr 2001, Craig Sanders wrote: > > * it's slow. > > * it doesn't scale well. > > Short: FUD, spread by one who's not kept up with current developements - > Look at whats being done in 8.12 wrt multi-queues and > multi-runners/queue. 8.12 is faster than 8.9.3 ever was (much faster > than 8.10/11), and has a hell of lot more function that's not saying a lot. > Long: Sendmail was basically in `maintenance' mode for several years, > and a few of its competitors (who didn't have legacy concerns) were able > to leapfrog it in performance and scalability. Sendmail has had quite > a bit of rework... read as: bugger all was done on sendmail for years until the authors noticed that: a) people had got sick of all it's problems and written vastly superior alternatives like qmail and then postfix and, more importantly, b) there was a chance to become dot-com millionaires. too little, too late. > No, but it has come a long way since then, a significant portion has > been rewritten since 8.9.3 The last incident I can recall turned out > to actually be the kernel capability bug... too little, too late. > > * it's configuration language is overly complex for the task at hand > > (the m4 macros helped a lot, but it's still way more complex than it > > needs to be) > > Depends upon the task at hand eh? For a end-node, sure sendmail.cf > hacking isn't needed - sendmail.cf hacking is never needed. anything you can do with .cf hackery can be done in postfix with plain-english configuration and appropriate use of map files. > but the provided m4 features cover that pretty > well with FEATURE(nullclient, `') -- what could be easier. "relayhost = smart.host.example.com" in /etc/postfix/main.cf and you've got to admit - m4 isn't exactly the easiest or most pleasant of languages to work with...in fact, it's ugly. and that's sendmail's *easier* configuration style. > Sendmail *is* the kitchen sink of MTAs - and yes, there is a cost to > that, but significant tuning *is* going on... The other side is that > with the kitchen sink comes everything: you miss the point. you don't *need* anything near as complicated as sendmail.cf or even sendmail.mc to provide the features of sendmail. > Mixing/matching of DB, LDAP, text, HESIOD, PH (not on Debian), etc. > for *ANY* map: aliases, access, etc. postfix does all that and more: including mysql, postgres maps, posix and pcre regexp maps and more. > Why suffer with `sendmail compatible' when you can have the > `REAL thing'? because the 'REAL thing' sucks. postfix isn't sendmail-compatible because sendmail is the pinnacle of MTAs and must be emulated. postfix is sendmail-compatible because there are a lot of people running sendmail systems who will not change from their legacy software if it requires a complete re-implementation of their mail system...qmail proved that. why suffer with sendmail when you can have postfix, which can do everything that sendmail can do only faster and better and securely? look, if you're happy to use obsolete software that's fine by me, doesn't bother me at all...but to insist that it's anywhere near as good as the alternatives is annoying and ridiculous. sendmail had it's day. that day is over. it should just retire gracefully. the phrase "mutton dressed up as lamb" seems appropriate - sendmail's recent facelifts are like an old woman whacking on way too much makeup and pretending/insisting she's as young and pretty as the 20 year olds. it really doesn't fool many people. craig -- craig sanders <[EMAIL PROTECTED]> GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sendmail is slow for mass mail
On Tue, Apr 03, 2001 at 09:42:01AM -0400, Richard A Nelson wrote: > Mixing/matching of DB, LDAP, text, HESIOD, PH (not on Debian), etc. > for *ANY* map: aliases, access, etc. Ah, but postfix does that, and does it better, adding posix and pcre regex's and SQL or whatever to the mix. > Why suffer with `sendmail compatible' when you can have the `REAL > thing'? Because Postfix is simpler, therefore easier to audit and trust. It runs less stuff as root. It isn't a fight to make it run chrooted (and even does so as default in Debian) and generally is trivial to make it do stupid mta tricks. After installing it on a couple play machines, it was the obvious replacement for sendmail... fast, trustworthy, and a pleasure to play with. (The code is actually understandable!) Oh, and I'd trust Wietse with a root shell on any of my machines. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sendmail is slow for mass mail
On Tue, Apr 03, 2001 at 07:11:06AM -0400, Chris Wagner wrote: > So, what happened to sendmail? How did it earn it's fall from grace? > When I got into it, sendmail was it. I've never looked closely at the > mail system since. * it's slow. * it doesn't scale well. if you've ever seen sendmail boxes repeatedly crash under the load of processing bounces from a 30,000+ subscriber mailing list you'll understand what this means. by way of contrast, the same mailing list on the same machine but with postfix as the MTA ran perfectly fine (no crashes, no problems, and all the mail *delivered* in a fraction of the time sendmail took) and it even scaled up to 450,000+ subscribers over the next 6 months or so before we had to switch the MLM from smartlist to listar. smartlist also doesn't scale very gracefully...but that's another issue. * it suffers from security-flaw-of-the-month-itis. sendmail was not designed with security in mind (the net was a much nicer place back then), and it shows. * it's configuration language is overly complex for the task at hand (the m4 macros helped a lot, but it's still way more complex than it needs to be) * postfix is a nearly drop-in replacement for it which doesn't suffer from any of the above problems. craig -- craig sanders <[EMAIL PROTECTED]> GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: sendmail is slow for mass mail
So, what happened to sendmail? How did it earn it's fall from grace? When I got into it, sendmail was it. I've never looked closely at the mail system since. ---==--- ___/``\___ 0100
Re: sendmail is slow for mass mail
On Tue, Apr 03, 2001 at 07:11:06AM -0400, Chris Wagner wrote: > So, what happened to sendmail? How did it earn it's fall from grace? > When I got into it, sendmail was it. I've never looked closely at the > mail system since. * it's slow. * it doesn't scale well. if you've ever seen sendmail boxes repeatedly crash under the load of processing bounces from a 30,000+ subscriber mailing list you'll understand what this means. by way of contrast, the same mailing list on the same machine but with postfix as the MTA ran perfectly fine (no crashes, no problems, and all the mail *delivered* in a fraction of the time sendmail took) and it even scaled up to 450,000+ subscribers over the next 6 months or so before we had to switch the MLM from smartlist to listar. smartlist also doesn't scale very gracefully...but that's another issue. * it suffers from security-flaw-of-the-month-itis. sendmail was not designed with security in mind (the net was a much nicer place back then), and it shows. * it's configuration language is overly complex for the task at hand (the m4 macros helped a lot, but it's still way more complex than it needs to be) * postfix is a nearly drop-in replacement for it which doesn't suffer from any of the above problems. craig -- craig sanders <[EMAIL PROTECTED]> GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sendmail is slow for mass mail
So, what happened to sendmail? How did it earn it's fall from grace? When I got into it, sendmail was it. I've never looked closely at the mail system since. ---==--- ___/``\___ 0100 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sendmail is slow for mass mail
On Tue, Apr 03, 2001 at 12:31:27AM -0400, Haim Dimermanas wrote: > Foreword : I *really* don't want to start a flame war on that. I > am just _very_ curious. I am currently using Exim. I don't really > know a whole lot about it. I just think that it's nice to have a > human readable config file and a good documentation. I am considering > switching to qmail or postfix (I don't know which one yet) and I would > love to know more. i've used pretty nearly every freely available unix MTA over the last 8 or 9 years. smail for a few years, then sendmail for a few more years, then some experimentation with zmailer and exim before settling on qmail for a year or so. then postfix came along and i just don't use anything else any more. i still have a few qmail systems, but only because it's more trouble than it's worth to convert them to postfix. all my sendmail systems got converted to postfix long ago. qmail doesn't offer anything that postfix doesn't have, but has licensing problems that limit it's usefulness and it's rate of improvement. actually, that's not quite true. the one thing that qmail has which postfix can't do is that ezmlm only works with qmail. ezmlm is a very nice mailing list manager in some ways...but not that much nicer than listar or mailman that it's worth locking yourself into qmail. i see qmail's incompatibility with other MTAs as a huge trap - and the same kind of trap as proprietary mailers, or proprietary software in generalonce you convert to it, you're basically stuck there because it's going to be an enormous pain to convert to anything else. > > > The answer? qmail :) > > I heard that answer a LOT of times. I read (please confirm) that qmail was > the best when it came to having a cluster of pop toasters and also that it > was the best when it comes to virtual hosting. After all, AOL - Yahoo - > Netscape and all are using qmail AFAIK. > > > actually, the answer is postfix - especially since the original message > > said: > > Again, from what I read, postfix's main priority was security. and speed. and a reasonable level of backwards compatibility with sendmail/exim/smail/etc. > I read your very interresting post about the differences between > qmail and postfix when it comes to licensing issues and backward > compatibility with sendmail. What I would like to know is your opinion > on how postfix performs on the following points: > > - Ease of configuration. postfix's main config file (/etc/postfix/main.cf) is plain english and well commented. it's very easy to read and understand, and the default settings are quite sensible (i.e. it will not relay by default - in fact, you have to go to a lot of trouble to misconfigure postfix before it will act as an open relay). imo, it's easier to understand and configure than exim. YMMV. exim is mostly compatible with sendmail in a very similar way - it can use the same kinds of map files. > I don't want to read a whole book to find out how I can enable relay > for a range of IP. e.g. in /etc/postfix/main.cf: mynetworks = 127.0.0.0/8, 192.168.0.0/24 smtpd_recipient_restrictions = ..., permit_mynetworks, ... that's simplified because there are a lot of available options. mine looks something like this: smtpd_recipient_restrictions = hash:/etc/postfix/junk, reject_non_fqdn_recipient, reject_unknown_recipient_domain, reject_non_fqdn_sender, reject_unknown_sender_domain, reject_invalid_hostname, permit_mynetworks, reject_maps_rbl, check_relay_domains the order of the rules is significant...which is why, for example, reject_maps_rbl appears AFTER permit_mynetworks. one of the RBL services i use is the MAPS DUL and i don't want to block my own dialup users from relaying mail through the mail server. i also have header_checks and body_checks rules which use PCRE regexps to block common signs of spam and viruses (e.g. block all mail to/from [EMAIL PROTECTED], or all mail containing an executable attachment). > The fact that it is sendmail compatible scares me on that one. it doesn't use sendmail.cf or anything like it. the compatibility is that it can use the same format files that sendmail used to use - aliases, virtual, transports, etc. for some, like /etc/aliases it can use the exact same file. for others, they might need to be renamed (e.g. from /etc/mail/virtusertable to /etc/postfix/virtual). > - Scalability. Comparing apples to apples, does postfix provide the > tools when it comes to hosting tens of thousands of virtual domains? yes. it scales extremely well. > - Reliability. Email is like dial tone these days, it's important to > know how postfix performs on this particular topic. wellexim's a nice little MTA for small leafnode sites - it's basically smail do
Re: sendmail is slow for mass mail
On Tue, Apr 03, 2001 at 02:20:51PM +0900, ARAKI Yasuhiro wrote: > Folks, > > > > postfix is also faster than qmail. and more flexible. and with much > > > better anti-spam features. > > > > Could you elaborate on that? > > Postfix use piggyback mail transfer. > If two or more recipients are in the same domain, postfix/smtp use > ONLY ONE smtp connection for sending message.(like a sendmail, exim..) > BUT qmail use newly qmail-smtp each message. And, as I recall, postfix has less file accesses than qmail. (And a LOT less than sendmail.) I love postfix: it's been a pleasure to fiddle with (with a READABLE config) and is amazingly clear code with a wide range of versatility: one of my favorite things is that you can mix and match flat files with db files (usually a hash) with regex's with perl-compatble regexs... Want to have your aliases done "normally" as a hash? Sure.. but you can also add in a pcre file or two, and maybe even a flat file... other than the speed issues for each, postfix doesn't care what sort of 'map' you use. (You can even toss in an ldap or sql map if you want, but I haven't needed that.) The 'sendmail compatible' is overstated. It doesn't read sendmail.cf. It -does- act normally with things like .forward file, and the format of the alias file is the same and that sort of thing. It's actually much easier to get postfix to do Stupid MTA Tricks than it is to do the same with sendmail (did I mention I love pcre's? It's nice to refuse mail from all-numeric 'local parts' in email addresses)
Re: sendmail is slow for mass mail
On Tue, 3 Apr 2001, Haim Dimermanas wrote: > - Ease of configuration. I don't want to read a whole book to find out how I > can enable relay for a range of IP. The fact that it is sendmail compatible > scares me on that one. Postfix's configuration files and syntax are entirely different than sendmail. Postfix's configurations are very easy to use and understand. Postfix usage is also very different (other than common sendmail arguments and switches). Visit www.postfix.org and read one or two documentation pages. Jeremy C. Reed ... ISP-FAQ.com -- find answers to your questions http://www.isp-faq.com/
Re: sendmail is slow for mass mail
Folks, Subject: Re: sendmail is slow for mass mail Date: Tue, 03 Apr 2001 00:31:27 -0400 Message-ID: <[EMAIL PROTECTED]> > - Ease of configuration. I don't want to read a whole book to find out how I > can enable relay for a range of IP. The fact that it is sendmail compatible > scares me on that one. If you want to stop smtp relay for all other hosts, use # postconf -e "mynetworks_style = host" > - Scalability. Comparing apples to apples, does postfix provide the tools > when it comes to hosting tens of thousands of virtual domains? Postfix can receive huge domains. # postconf -e "mydestination = $myhostname, localhost.localdomain, \ hash:/etc/postfix/virtual" You list your virtual domains in /etc/postfix/virtual file. The function of the Virtual domains mainly provided by MDA. You can use any MDA which is starting by lmtp, pipe, INET, UNIX domain socket. > > postfix is also faster than qmail. and more flexible. and with much > > better anti-spam features. > > Could you elaborate on that? Postfix use piggyback mail transfer. If two or more recipients are in the same domain, postfix/smtp use ONLY ONE smtp connection for sending message.(like a sendmail, exim..) BUT qmail use newly qmail-smtp each message. --- ARAKI Yasuhiro [EMAIL PROTECTED]
Re: sendmail is slow for mass mail
On Tue, Apr 03, 2001 at 12:31:27AM -0400, Haim Dimermanas wrote: > Foreword : I *really* don't want to start a flame war on that. I > am just _very_ curious. I am currently using Exim. I don't really > know a whole lot about it. I just think that it's nice to have a > human readable config file and a good documentation. I am considering > switching to qmail or postfix (I don't know which one yet) and I would > love to know more. i've used pretty nearly every freely available unix MTA over the last 8 or 9 years. smail for a few years, then sendmail for a few more years, then some experimentation with zmailer and exim before settling on qmail for a year or so. then postfix came along and i just don't use anything else any more. i still have a few qmail systems, but only because it's more trouble than it's worth to convert them to postfix. all my sendmail systems got converted to postfix long ago. qmail doesn't offer anything that postfix doesn't have, but has licensing problems that limit it's usefulness and it's rate of improvement. actually, that's not quite true. the one thing that qmail has which postfix can't do is that ezmlm only works with qmail. ezmlm is a very nice mailing list manager in some ways...but not that much nicer than listar or mailman that it's worth locking yourself into qmail. i see qmail's incompatibility with other MTAs as a huge trap - and the same kind of trap as proprietary mailers, or proprietary software in generalonce you convert to it, you're basically stuck there because it's going to be an enormous pain to convert to anything else. > > > The answer? qmail :) > > I heard that answer a LOT of times. I read (please confirm) that qmail was > the best when it came to having a cluster of pop toasters and also that it > was the best when it comes to virtual hosting. After all, AOL - Yahoo - > Netscape and all are using qmail AFAIK. > > > actually, the answer is postfix - especially since the original message > > said: > > Again, from what I read, postfix's main priority was security. and speed. and a reasonable level of backwards compatibility with sendmail/exim/smail/etc. > I read your very interresting post about the differences between > qmail and postfix when it comes to licensing issues and backward > compatibility with sendmail. What I would like to know is your opinion > on how postfix performs on the following points: > > - Ease of configuration. postfix's main config file (/etc/postfix/main.cf) is plain english and well commented. it's very easy to read and understand, and the default settings are quite sensible (i.e. it will not relay by default - in fact, you have to go to a lot of trouble to misconfigure postfix before it will act as an open relay). imo, it's easier to understand and configure than exim. YMMV. exim is mostly compatible with sendmail in a very similar way - it can use the same kinds of map files. > I don't want to read a whole book to find out how I can enable relay > for a range of IP. e.g. in /etc/postfix/main.cf: mynetworks = 127.0.0.0/8, 192.168.0.0/24 smtpd_recipient_restrictions = ..., permit_mynetworks, ... that's simplified because there are a lot of available options. mine looks something like this: smtpd_recipient_restrictions = hash:/etc/postfix/junk, reject_non_fqdn_recipient, reject_unknown_recipient_domain, reject_non_fqdn_sender, reject_unknown_sender_domain, reject_invalid_hostname, permit_mynetworks, reject_maps_rbl, check_relay_domains the order of the rules is significant...which is why, for example, reject_maps_rbl appears AFTER permit_mynetworks. one of the RBL services i use is the MAPS DUL and i don't want to block my own dialup users from relaying mail through the mail server. i also have header_checks and body_checks rules which use PCRE regexps to block common signs of spam and viruses (e.g. block all mail to/from [EMAIL PROTECTED], or all mail containing an executable attachment). > The fact that it is sendmail compatible scares me on that one. it doesn't use sendmail.cf or anything like it. the compatibility is that it can use the same format files that sendmail used to use - aliases, virtual, transports, etc. for some, like /etc/aliases it can use the exact same file. for others, they might need to be renamed (e.g. from /etc/mail/virtusertable to /etc/postfix/virtual). > - Scalability. Comparing apples to apples, does postfix provide the > tools when it comes to hosting tens of thousands of virtual domains? yes. it scales extremely well. > - Reliability. Email is like dial tone these days, it's important to > know how postfix performs on this particular topic. wellexim's a nice little MTA for small leafnode sites - it's basically smail d
Re: sendmail is slow for mass mail
Foreword : I *really* don't want to start a flame war on that. I am just _very_ curious. I am currently using Exim. I don't really know a whole lot about it. I just think that it's nice to have a human readable config file and a good documentation. I am considering switching to qmail or postfix (I don't know which one yet) and I would love to know more. > > The answer? qmail :) I heard that answer a LOT of times. I read (please confirm) that qmail was the best when it came to having a cluster of pop toasters and also that it was the best when it comes to virtual hosting. After all, AOL - Yahoo - Netscape and all are using qmail AFAIK. > actually, the answer is postfix - especially since the original message > said: Again, from what I read, postfix's main priority was security. I read your very interresting post about the differences between qmail and postfix when it comes to licensing issues and backward compatibility with sendmail. What I would like to know is your opinion on how postfix performs on the following points: - Ease of configuration. I don't want to read a whole book to find out how I can enable relay for a range of IP. The fact that it is sendmail compatible scares me on that one. - Scalability. Comparing apples to apples, does postfix provide the tools when it comes to hosting tens of thousands of virtual domains? - Reliability. Email is like dial tone these days, it's important to know how postfix performs on this particular topic. > postfix is also faster than qmail. and more flexible. and with much > better anti-spam features. Could you elaborate on that? > by contrast, postfix has an extremely active development community with > new features and patches being created for it all the time...some of > which even make it into the mainline postfix release if they meet wietse > venema's standards. This is a very important point. I had no idea that qmail's development was so slow and that postfix's was so active. Again, can you give more infos? Again, I appreciate your help in helping people like me get their foot in this door. Sincerely, Haim. -- Whatthehellhashappenedtomydamnspacebar?!?!? -- [EMAIL PROTECTED] --
Re: sendmail is slow for mass mail
On Tue, Apr 03, 2001 at 02:20:51PM +0900, ARAKI Yasuhiro wrote: > Folks, > > > > postfix is also faster than qmail. and more flexible. and with much > > > better anti-spam features. > > > > Could you elaborate on that? > > Postfix use piggyback mail transfer. > If two or more recipients are in the same domain, postfix/smtp use > ONLY ONE smtp connection for sending message.(like a sendmail, exim..) > BUT qmail use newly qmail-smtp each message. And, as I recall, postfix has less file accesses than qmail. (And a LOT less than sendmail.) I love postfix: it's been a pleasure to fiddle with (with a READABLE config) and is amazingly clear code with a wide range of versatility: one of my favorite things is that you can mix and match flat files with db files (usually a hash) with regex's with perl-compatble regexs... Want to have your aliases done "normally" as a hash? Sure.. but you can also add in a pcre file or two, and maybe even a flat file... other than the speed issues for each, postfix doesn't care what sort of 'map' you use. (You can even toss in an ldap or sql map if you want, but I haven't needed that.) The 'sendmail compatible' is overstated. It doesn't read sendmail.cf. It -does- act normally with things like .forward file, and the format of the alias file is the same and that sort of thing. It's actually much easier to get postfix to do Stupid MTA Tricks than it is to do the same with sendmail (did I mention I love pcre's? It's nice to refuse mail from all-numeric 'local parts' in email addresses) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sendmail is slow for mass mail
On Tue, 3 Apr 2001, Haim Dimermanas wrote: > - Ease of configuration. I don't want to read a whole book to find out how I > can enable relay for a range of IP. The fact that it is sendmail compatible > scares me on that one. Postfix's configuration files and syntax are entirely different than sendmail. Postfix's configurations are very easy to use and understand. Postfix usage is also very different (other than common sendmail arguments and switches). Visit www.postfix.org and read one or two documentation pages. Jeremy C. Reed ... ISP-FAQ.com -- find answers to your questions http://www.isp-faq.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sendmail is slow for mass mail
Folks, Subject: Re: sendmail is slow for mass mail Date: Tue, 03 Apr 2001 00:31:27 -0400 Message-ID: <[EMAIL PROTECTED]> > - Ease of configuration. I don't want to read a whole book to find out how I > can enable relay for a range of IP. The fact that it is sendmail compatible > scares me on that one. If you want to stop smtp relay for all other hosts, use # postconf -e "mynetworks_style = host" > - Scalability. Comparing apples to apples, does postfix provide the tools > when it comes to hosting tens of thousands of virtual domains? Postfix can receive huge domains. # postconf -e "mydestination = $myhostname, localhost.localdomain, \ hash:/etc/postfix/virtual" You list your virtual domains in /etc/postfix/virtual file. The function of the Virtual domains mainly provided by MDA. You can use any MDA which is starting by lmtp, pipe, INET, UNIX domain socket. > > postfix is also faster than qmail. and more flexible. and with much > > better anti-spam features. > > Could you elaborate on that? Postfix use piggyback mail transfer. If two or more recipients are in the same domain, postfix/smtp use ONLY ONE smtp connection for sending message.(like a sendmail, exim..) BUT qmail use newly qmail-smtp each message. --- ARAKI Yasuhiro [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sendmail is slow for mass mail
Foreword : I *really* don't want to start a flame war on that. I am just _very_ curious. I am currently using Exim. I don't really know a whole lot about it. I just think that it's nice to have a human readable config file and a good documentation. I am considering switching to qmail or postfix (I don't know which one yet) and I would love to know more. > > The answer? qmail :) I heard that answer a LOT of times. I read (please confirm) that qmail was the best when it came to having a cluster of pop toasters and also that it was the best when it comes to virtual hosting. After all, AOL - Yahoo - Netscape and all are using qmail AFAIK. > actually, the answer is postfix - especially since the original message > said: Again, from what I read, postfix's main priority was security. I read your very interresting post about the differences between qmail and postfix when it comes to licensing issues and backward compatibility with sendmail. What I would like to know is your opinion on how postfix performs on the following points: - Ease of configuration. I don't want to read a whole book to find out how I can enable relay for a range of IP. The fact that it is sendmail compatible scares me on that one. - Scalability. Comparing apples to apples, does postfix provide the tools when it comes to hosting tens of thousands of virtual domains? - Reliability. Email is like dial tone these days, it's important to know how postfix performs on this particular topic. > postfix is also faster than qmail. and more flexible. and with much > better anti-spam features. Could you elaborate on that? > by contrast, postfix has an extremely active development community with > new features and patches being created for it all the time...some of > which even make it into the mainline postfix release if they meet wietse > venema's standards. This is a very important point. I had no idea that qmail's development was so slow and that postfix's was so active. Again, can you give more infos? Again, I appreciate your help in helping people like me get their foot in this door. Sincerely, Haim. -- Whatthehellhashappenedtomydamnspacebar?!?!? -- [EMAIL PROTECTED] -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sendmail is slow for mass mail
On Thu, Mar 29, 2001 at 01:44:27AM +0100, Gavin Hamill wrote: > > My problem: The emails are being sent out at an UNBELIEVABLY SLOW rate. > > > > There must be a better way! > > The answer? qmail :) actually, the answer is postfix - especially since the original message said: : Also, I won't use qmail because I have too much invested in sendmail : at this point, and I dislike the DJB's licensing terms. postfix addresses both issues. firstly, unlike qmail, it is a true open source / free software program. anyone can modify it and redistribute their modified version if they wish. the license isn't GPL (it's IBM's Public License) but it is GPL compatible...the main difference is that IBM's license has some clauses covering patent issues (requiring royalty-free licensing of any associated patents so that it is impossible to "embrace and extend" postfix with patented code). secondly, it is mostly backwards compatible with sendmail. for almost all sendmail installations, upgrading to postfix is a very simple and straight-forward operation. you can use your old aliases, virtual user, transport and other tables with little or no modification - the file formats are either identical or backwards compatible (e.g. the virtual table allows multiple addresses on the RHS). the main thing to remember is that postfix will refuse to run any pipe alias as root so if you have aliases which depend on being run as root you will have to think of some other way. postfix is also faster than qmail. and more flexible. and with much better anti-spam features. > It takes a bit of getting used to because it's configuration is like > nothing else, but give it a go this, apart from the licensing issue, is the major problem with qmail. DJB's attitude is that you have to throw out all your previous work on your mail system and start from scratch...reimplementing it in his One True Way. if you don't want to do it exactly as he demands then you're both wrong and a complete moron because djb is always right. apparently, bernstein knows your system and your needs better than you do. the licensing issue causes a second major problem - it forces a reversion to the bad old days when you had to download a tarball and then spend ages hunting for numerous patches from various sites all over the net, download and apply them and hope that none of the patches conflict with each other. as a result, qmail has basically stagnated for the last few years...there is very little active development being done on or for it. by contrast, postfix has an extremely active development community with new features and patches being created for it all the time...some of which even make it into the mainline postfix release if they meet wietse venema's standards. for a while, if you wanted a fast secure MTA then qmail was really the only option available...but that was 3 years ago. now, though, postfix is a much better option - especially if you have old sendmail (or sendmail-compatible) systems you want to upgrade. i can't think of any valid reason to switch to qmail now...and the only reason for staying with qmail if you already have it installed is that it's so incompatible with the way other MTAs work that it would be a PITA to switch. craig -- craig sanders <[EMAIL PROTECTED]> GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0
Re: sendmail is slow for mass mail
On Thu, Mar 29, 2001 at 01:44:27AM +0100, Gavin Hamill wrote: > > My problem: The emails are being sent out at an UNBELIEVABLY SLOW rate. > > > > There must be a better way! > > The answer? qmail :) actually, the answer is postfix - especially since the original message said: : Also, I won't use qmail because I have too much invested in sendmail : at this point, and I dislike the DJB's licensing terms. postfix addresses both issues. firstly, unlike qmail, it is a true open source / free software program. anyone can modify it and redistribute their modified version if they wish. the license isn't GPL (it's IBM's Public License) but it is GPL compatible...the main difference is that IBM's license has some clauses covering patent issues (requiring royalty-free licensing of any associated patents so that it is impossible to "embrace and extend" postfix with patented code). secondly, it is mostly backwards compatible with sendmail. for almost all sendmail installations, upgrading to postfix is a very simple and straight-forward operation. you can use your old aliases, virtual user, transport and other tables with little or no modification - the file formats are either identical or backwards compatible (e.g. the virtual table allows multiple addresses on the RHS). the main thing to remember is that postfix will refuse to run any pipe alias as root so if you have aliases which depend on being run as root you will have to think of some other way. postfix is also faster than qmail. and more flexible. and with much better anti-spam features. > It takes a bit of getting used to because it's configuration is like > nothing else, but give it a go this, apart from the licensing issue, is the major problem with qmail. DJB's attitude is that you have to throw out all your previous work on your mail system and start from scratch...reimplementing it in his One True Way. if you don't want to do it exactly as he demands then you're both wrong and a complete moron because djb is always right. apparently, bernstein knows your system and your needs better than you do. the licensing issue causes a second major problem - it forces a reversion to the bad old days when you had to download a tarball and then spend ages hunting for numerous patches from various sites all over the net, download and apply them and hope that none of the patches conflict with each other. as a result, qmail has basically stagnated for the last few years...there is very little active development being done on or for it. by contrast, postfix has an extremely active development community with new features and patches being created for it all the time...some of which even make it into the mainline postfix release if they meet wietse venema's standards. for a while, if you wanted a fast secure MTA then qmail was really the only option available...but that was 3 years ago. now, though, postfix is a much better option - especially if you have old sendmail (or sendmail-compatible) systems you want to upgrade. i can't think of any valid reason to switch to qmail now...and the only reason for staying with qmail if you already have it installed is that it's so incompatible with the way other MTAs work that it would be a PITA to switch. craig -- craig sanders <[EMAIL PROTECTED]> GnuPG Key: 1024D/CD5626F0 Key fingerprint: 9674 7EE2 4AC6 F5EF 3C57 52C3 EC32 6810 CD56 26F0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sendmail is slow for mass mail
I've just been researching the same problem myself, and came accross a program called SMTPfeed. Don't know anything more about it, except for a mailer comparison page which claimed that it was one of the better high volume mail thingies. Supposedly plugs into sendmail somehow, so you won't have to abandon your setup. It's a Debian package in the current distro so you should be able to apt-get it. Let me know if you try it because I have to do the same in a few weeks. >From: JPS <[EMAIL PROTECTED]> >To: debian-isp@lists.debian.org >Subject: sendmail is slow for mass mail >Date: Wed, 28 Mar 2001 19:32:12 -0500 > >I have a sendmail installation using sendmail_8.11.3+8.12.0.Beta5-4_i386.deb >+ SASL on a linux 2.4.3-pre4 i686. > >I am attempting to process very high volume mailingslists (10-100K >multiples) on this server. > >My problem: The emails are being sent out at an UNBELIEVABLY SLOW rate. > >First, during the initial esmtp dialogue, sendmail checks each and every >recipient address and after 1 or more seconds it says: > >"250 2.1.5 <[EMAIL PROTECTED]>... Recipient ok" > >for each recipient. Unfortunately, there are 100K recipients, >and my MUA has to maintain that open connection for hours. >There must be a better way! > >Second, once the dialogue is complete, sendmail puts the whole >envelope into the queue. Then, by drips and drabs, sendmail selects a handfull >of recipients and sends them the email. It does this during every >queue-flush-run (every 10 minutes) in my case. How can I get sendmail >to process the whole envelope at once? Is it supposed to take days to >process large mailinglists? What am I doing wrong? > >BTW: this machine has its own BIND. >Also, I won't use qmail because I have too much invested in sendmail at this >point, and I dislike the DJB's licensing terms. > >-- >Jean-Paul Stewart >Senior Systems Administrator > >CarbonMedia, Inc. >114 East 25th Street, Eighth Floor >New York, NY 10010 >Phone: 212.253.7180 >Fax: 212.253.8467 >http://www.carbonmedia.com/ > >For my PGP/GPG public key: >`finger [EMAIL PROTECTED]' ><< attach3 >> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com.
Re: sendmail is slow for mass mail
JPS, Here's a few things to try... 1) Try multiple queues... that will help greately. Also sort your queues by host (to insure that your sendmail doesn't keep reconnecting to AOL for example) 2) Move BIND to a dedecated server, unless you've got an obscene ammount of RAM. Don't make that machine (the DNS machine) authoritative for any domains. Probably best to not point any other clients at it either. 3) What's your hard drive setup? If /var/spool and /var/log are on the same disk... you're hurting. Seperate the spools from the log dir. 4) Tune /etc/syslog.conf to only log errors to the syslog.. all other mail logs should go to /var/log/mail.info and mail.err (or whatever). Also, don't synch the mail log files (put a "-" in front of the filename). 5) Try toggling the Host Status option on and off. Also make sure the status directory is on a fast disk. If your status/com subdirectory gets huge (mine sure does), you may want to consider putting it on something other than an ext2 fs. 5) Tune your timeouts! Some suggested changes (some are particular for a server that's heavily loaded on outgoing only): ConnectionCacheTimeout = 30 (or less... default is 5 min... if your queue is sorted by destination, you're wasting time holding the SMTP dialogue open for five minutes). QueueTimeout: If this is a fairly stable mailing list, you may want to dump messages that have sat for a while... your call. May also want to change retry factor, to de-prioritize old messages. TimeoutConnect = 1m (if we can't connect within 1 minute, the host is probably down or temporarily unreachable... don't wait 90min). TimoutIconnect = 10s (Be real picky on the Initial connection... let's get mail out to the easiest hosts first.) 6) Check some metrics to see where else you're bottled up. Run MRTG or something to watch capacity on your connection. Check top every now and then to see what your memory usage is (if you insist on leaving BIND on that box be sure BIND never has to swap...). 7) IDE or SCSI drives? If you're running off of one or two poky old IDE drives you're in tough shape... spring for a hardware RAID card and a couple of SCSI drives. Or... if you're only doing outgoing email, and you could tolerate losing a couple of messages in the event of a disk crash (not too unlikely... losing a few messages shouldn't hurt as long as you can get back up quickly), you can set up the drives in RAID 0 (striping) for a wicked fast disk setup. 8) Do you really need SASL on a mailing list server? Just checking... That's a load to dig into, but it should get you a start on things. Good luck! --Rich JPS wrote: > > I have a sendmail installation using sendmail_8.11.3+8.12.0.Beta5-4_i386.deb > + SASL on a linux 2.4.3-pre4 i686. > > I am attempting to process very high volume mailingslists (10-100K > multiples) on this server. > > My problem: The emails are being sent out at an UNBELIEVABLY SLOW rate. > > First, during the initial esmtp dialogue, sendmail checks each and every > recipient address and after 1 or more seconds it says: > > "250 2.1.5 <[EMAIL PROTECTED]>... Recipient ok" > > for each recipient. Unfortunately, there are 100K recipients, > and my MUA has to maintain that open connection for hours. > There must be a better way! > > Second, once the dialogue is complete, sendmail puts the whole > envelope into the queue. Then, by drips and drabs, sendmail selects a handfull > of recipients and sends them the email. It does this during every > queue-flush-run (every 10 minutes) in my case. How can I get sendmail > to process the whole envelope at once? Is it supposed to take days to > process large mailinglists? What am I doing wrong? > > BTW: this machine has its own BIND. > Also, I won't use qmail because I have too much invested in sendmail at this > point, and I dislike the DJB's licensing terms. > > -- > Jean-Paul Stewart > Senior Systems Administrator > > CarbonMedia, Inc. > 114 East 25th Street, Eighth Floor > New York, NY 10010 > Phone: 212.253.7180 > Fax: 212.253.8467 > http://www.carbonmedia.com/ > > For my PGP/GPG public key: > `finger [EMAIL PROTECTED]' > > >Part 1.2Type: application/pgp-signature -- _ Rich Puhek ETN Systems Inc. _
Re: sendmail is slow for mass mail
I've just been researching the same problem myself, and came accross a program called SMTPfeed. Don't know anything more about it, except for a mailer comparison page which claimed that it was one of the better high volume mail thingies. Supposedly plugs into sendmail somehow, so you won't have to abandon your setup. It's a Debian package in the current distro so you should be able to apt-get it. Let me know if you try it because I have to do the same in a few weeks. >From: JPS <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: sendmail is slow for mass mail >Date: Wed, 28 Mar 2001 19:32:12 -0500 > >I have a sendmail installation using sendmail_8.11.3+8.12.0.Beta5-4_i386.deb >+ SASL on a linux 2.4.3-pre4 i686. > >I am attempting to process very high volume mailingslists (10-100K >multiples) on this server. > >My problem: The emails are being sent out at an UNBELIEVABLY SLOW rate. > >First, during the initial esmtp dialogue, sendmail checks each and every >recipient address and after 1 or more seconds it says: > >"250 2.1.5 <[EMAIL PROTECTED]>... Recipient ok" > >for each recipient. Unfortunately, there are 100K recipients, >and my MUA has to maintain that open connection for hours. >There must be a better way! > >Second, once the dialogue is complete, sendmail puts the whole >envelope into the queue. Then, by drips and drabs, sendmail selects a handfull >of recipients and sends them the email. It does this during every >queue-flush-run (every 10 minutes) in my case. How can I get sendmail >to process the whole envelope at once? Is it supposed to take days to >process large mailinglists? What am I doing wrong? > >BTW: this machine has its own BIND. >Also, I won't use qmail because I have too much invested in sendmail at this >point, and I dislike the DJB's licensing terms. > >-- >Jean-Paul Stewart >Senior Systems Administrator > >CarbonMedia, Inc. >114 East 25th Street, Eighth Floor >New York, NY 10010 >Phone: 212.253.7180 >Fax: 212.253.8467 >http://www.carbonmedia.com/ > >For my PGP/GPG public key: >`finger [EMAIL PROTECTED]' ><< attach3 >> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sendmail is slow for mass mail
JPS, Here's a few things to try... 1) Try multiple queues... that will help greately. Also sort your queues by host (to insure that your sendmail doesn't keep reconnecting to AOL for example) 2) Move BIND to a dedecated server, unless you've got an obscene ammount of RAM. Don't make that machine (the DNS machine) authoritative for any domains. Probably best to not point any other clients at it either. 3) What's your hard drive setup? If /var/spool and /var/log are on the same disk... you're hurting. Seperate the spools from the log dir. 4) Tune /etc/syslog.conf to only log errors to the syslog.. all other mail logs should go to /var/log/mail.info and mail.err (or whatever). Also, don't synch the mail log files (put a "-" in front of the filename). 5) Try toggling the Host Status option on and off. Also make sure the status directory is on a fast disk. If your status/com subdirectory gets huge (mine sure does), you may want to consider putting it on something other than an ext2 fs. 5) Tune your timeouts! Some suggested changes (some are particular for a server that's heavily loaded on outgoing only): ConnectionCacheTimeout = 30 (or less... default is 5 min... if your queue is sorted by destination, you're wasting time holding the SMTP dialogue open for five minutes). QueueTimeout: If this is a fairly stable mailing list, you may want to dump messages that have sat for a while... your call. May also want to change retry factor, to de-prioritize old messages. TimeoutConnect = 1m (if we can't connect within 1 minute, the host is probably down or temporarily unreachable... don't wait 90min). TimoutIconnect = 10s (Be real picky on the Initial connection... let's get mail out to the easiest hosts first.) 6) Check some metrics to see where else you're bottled up. Run MRTG or something to watch capacity on your connection. Check top every now and then to see what your memory usage is (if you insist on leaving BIND on that box be sure BIND never has to swap...). 7) IDE or SCSI drives? If you're running off of one or two poky old IDE drives you're in tough shape... spring for a hardware RAID card and a couple of SCSI drives. Or... if you're only doing outgoing email, and you could tolerate losing a couple of messages in the event of a disk crash (not too unlikely... losing a few messages shouldn't hurt as long as you can get back up quickly), you can set up the drives in RAID 0 (striping) for a wicked fast disk setup. 8) Do you really need SASL on a mailing list server? Just checking... That's a load to dig into, but it should get you a start on things. Good luck! --Rich JPS wrote: > > I have a sendmail installation using sendmail_8.11.3+8.12.0.Beta5-4_i386.deb > + SASL on a linux 2.4.3-pre4 i686. > > I am attempting to process very high volume mailingslists (10-100K > multiples) on this server. > > My problem: The emails are being sent out at an UNBELIEVABLY SLOW rate. > > First, during the initial esmtp dialogue, sendmail checks each and every > recipient address and after 1 or more seconds it says: > > "250 2.1.5 <[EMAIL PROTECTED]>... Recipient ok" > > for each recipient. Unfortunately, there are 100K recipients, > and my MUA has to maintain that open connection for hours. > There must be a better way! > > Second, once the dialogue is complete, sendmail puts the whole > envelope into the queue. Then, by drips and drabs, sendmail selects a handfull > of recipients and sends them the email. It does this during every > queue-flush-run (every 10 minutes) in my case. How can I get sendmail > to process the whole envelope at once? Is it supposed to take days to > process large mailinglists? What am I doing wrong? > > BTW: this machine has its own BIND. > Also, I won't use qmail because I have too much invested in sendmail at this > point, and I dislike the DJB's licensing terms. > > -- > Jean-Paul Stewart > Senior Systems Administrator > > CarbonMedia, Inc. > 114 East 25th Street, Eighth Floor > New York, NY 10010 > Phone: 212.253.7180 > Fax: 212.253.8467 > http://www.carbonmedia.com/ > > For my PGP/GPG public key: > `finger [EMAIL PROTECTED]' > > >Part 1.2Type: application/pgp-signature -- _ Rich Puhek ETN Systems Inc. _ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sendmail is slow for mass mail
> My problem: The emails are being sent out at an UNBELIEVABLY SLOW rate. > > There must be a better way! The answer? qmail :) Dan Bernstein originally wrote a package designed purely to deal with huge mailing lists.. and people loved it.. It's popularity grew.. and gradually more features crept in... so he renamed it to qmail, and it became a fully-fledged e-mail system. I utterly swear by it's extreme reliability, speed and tiny footprint. OK, so it's not fully GPL'd - he doesn't want binaries distributed.. but apt-get install qmail will download the source and build a .deb for you right away :) It takes a bit of getting used to because it's configuration is like nothing else, but give it a go I can only speak for qmail.. I'm sure other mailers like exim and zmailer are also very capable, but I've never used them.. Kind regards, Gavin
Re: sendmail is slow for mass mail
> My problem: The emails are being sent out at an UNBELIEVABLY SLOW rate. > > There must be a better way! The answer? qmail :) Dan Bernstein originally wrote a package designed purely to deal with huge mailing lists.. and people loved it.. It's popularity grew.. and gradually more features crept in... so he renamed it to qmail, and it became a fully-fledged e-mail system. I utterly swear by it's extreme reliability, speed and tiny footprint. OK, so it's not fully GPL'd - he doesn't want binaries distributed.. but apt-get install qmail will download the source and build a .deb for you right away :) It takes a bit of getting used to because it's configuration is like nothing else, but give it a go I can only speak for qmail.. I'm sure other mailers like exim and zmailer are also very capable, but I've never used them.. Kind regards, Gavin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
