qmail Digest 19 Feb 1999 11:00:00 -0000 Issue 556 Topics (messages 22139 through 22184): qreceipt for all 22139 by: Franky Van Liedekerke <[EMAIL PROTECTED]> 22163 by: Brad Shelton <[EMAIL PROTECTED]> Qmail Documentation (was addresses containing . ) 22140 by: [EMAIL PROTECTED] 22146 by: Keith Burdis <[EMAIL PROTECTED]> 22150 by: Peter van Dijk <[EMAIL PROTECTED]> 22151 by: Peter van Dijk <[EMAIL PROTECTED]> 22165 by: [EMAIL PROTECTED] (Anthony DeBoer) Qmail (as seen on a not so good day). 22141 by: Mark Delany <[EMAIL PROTECTED]> 22142 by: "Timothy L. Mayo" <[EMAIL PROTECTED]> 22143 by: Jere Cassidy <[EMAIL PROTECTED]> 22144 by: "Timothy L. Mayo" <[EMAIL PROTECTED]> 22145 by: Jere Cassidy <[EMAIL PROTECTED]> 22148 by: Mark Delany <[EMAIL PROTECTED]> 22153 by: "Sam" <[EMAIL PROTECTED]> 22157 by: John Gonzalez/netMDC admin <[EMAIL PROTECTED]> Qmail, Majordomo, and virtual domains 22147 by: Chuck Milam <[EMAIL PROTECTED]> Qmail mailing list and ReplyTo: 22149 by: Bruno Wolff III <[EMAIL PROTECTED]> 22159 by: Tim Pierce <[EMAIL PROTECTED]> 22167 by: Russell Nelson <[EMAIL PROTECTED]> 22172 by: Mate Wierdl <[EMAIL PROTECTED]> 22174 by: "Racer X" <[EMAIL PROTECTED]> 22175 by: Russell Nelson <[EMAIL PROTECTED]> 22177 by: "Racer X" <[EMAIL PROTECTED]> 22181 by: "Rok Papez" <[EMAIL PROTECTED]> 22182 by: "Rok Papez" <[EMAIL PROTECTED]> 22183 by: "Roman V. Isaev" <[EMAIL PROTECTED]> 22184 by: Russell Nelson <[EMAIL PROTECTED]> vacation (again!) 22152 by: Samuel Dries-Daffner <[EMAIL PROTECTED]> ~control/defaultdomain question 22154 by: Matt Garrett <[EMAIL PROTECTED]> 22155 by: Chris Johnson <[EMAIL PROTECTED]> Installation questions 22156 by: [EMAIL PROTECTED] 22166 by: "Sam" <[EMAIL PROTECTED]> virtualhosts and relaying 22158 by: Colin Coller <[EMAIL PROTECTED]> 22161 by: Chris Johnson <[EMAIL PROTECTED]> Maildir/cur ??? 22160 by: Eric Dahnke <[EMAIL PROTECTED]> qmail-smtp and error messages 22162 by: Markus Stumpf <[EMAIL PROTECTED]> 22164 by: Harald Hanche-Olsen <[EMAIL PROTECTED]> Pine, Qmail, and time zones 22168 by: Chuck Milam <[EMAIL PROTECTED]> 22180 by: Harald Hanche-Olsen <[EMAIL PROTECTED]> /bin/mail 22169 by: <[EMAIL PROTECTED]> rcpthosts error. 22170 by: Bob Ross <[EMAIL PROTECTED]> 22171 by: Scott Schwartz <[EMAIL PROTECTED]> Qmail for NT again 22173 by: "Racer X" <[EMAIL PROTECTED]> 22178 by: [EMAIL PROTECTED] binmail procmail Linux 22176 by: <[EMAIL PROTECTED]> qmail configuration problems. 22179 by: Glen Ward <[EMAIL PROTECTED]> Administrivia: To subscribe to the digest, e-mail: [EMAIL PROTECTED] To unsubscribe from the digest, e-mail: [EMAIL PROTECTED] To bug my human owner, e-mail: [EMAIL PROTECTED] To post to the list, e-mail: [EMAIL PROTECTED] ----------------------------------------------------------------------
Hi, is it possible to use qreceipt for all users and all emailadresses at once? I have thousands of popusers and I don't want to put qreceipt in everybody's .qmail file.
On Thu, Feb 18, 1999 at 01:29:20PM +0100, Franky Van Liedekerke wrote: > Hi, > > is it possible to use qreceipt for all users and all emailadresses at > once? I have thousands of popusers and I don't want to put qreceipt in > everybody's .qmail file. I just it in my default statement: --cut-- #!/bin/sh # Using splogger to send the log through syslog. # Using qmail-local to deliver messages to ~/Mailbox by default. # exec env - PATH="/var/qmail/bin:$PATH" \ # qmail-start ./Mailbox splogger qmail export PATH="/var/qmail/bin:$PATH:/usr/local/bin" qmail-start "| /usr/local/bin/mailquotacheck |test -d ./Maildir || maildirmake ./Maildir |qreceipt \$USER@\$HOST ./Maildir/ " splogger qmail --cut-- Which is one way of doing it without having to edit EVERYBODY's .qmail file.. or even create one for everybody, for that matter. `*8> -- Brad Shelton [EMAIL PROTECTED] On Line Exchange http://ole.net Detroit News http://detnews.com
On Thu, 18 Feb 1999, Peter van Dijk wrote: > On Wed, Feb 17, 1999 at 12:33:04PM -0500, [EMAIL PROTECTED] wrote: > > On Wed, 17 Feb 1999, Chris Naden wrote: > > > > for qmail-send: for its description of locals to explicitly say that > > virtual domains should *not* be placed in locals? > > > > for qmail-smtpd: for its description of rcpthosts to say that it > > should contain all the hosts in locals and virtualdomains plus > > those hosts you act as MX for. > > > > Actually, in stead of the latter suggestion, I'd prefer that there be > > another control file: mxhosts, and drop rcpthosts, which is just > > confusing everyone. Then we have simple explanations for what goes where. > You're not saying that qmail-smtpd should just read in locals and > virtualdomains and accept mail for all domains in there, right? No. I was suggesting replacing rcpthosts with mxhosts and having smail-smtpd read virtualdomains, locals and mxhosts. Having looked at "man qmail-control" I've decided that the reason Dan did things this way is that qmail-smtpd only has to read/check one file (rcpthosts), rather than three (virtualdomains, locals and mxhosts). It's a typical tradeoff: simpler program vs requiring people to read the documentation and put the right things in rcpthosts. I think I'll just make things work the way I want by making my own mxhosts and having an automatic procedure which builds rcpthosts appropriately. Or better yet, make the procedure which builds morercpthosts do it my way. > Greetz, Peter. > -- > .| Peter van Dijk | <mo|VERWEG> stoned worden of coden > .| [EMAIL PROTECTED] | <mo|VERWEG> dat is de levensvraag > | <mo|VERWEG> coden of stoned worden > | <mo|VERWEG> stonend worden En coden > | <mo|VERWEG> hmm > | <mo|VERWEG> dan maar stoned worden en slashdot lezen:) > -- "Life is much too important to be taken seriously." Thomas Erskine <[EMAIL PROTECTED]> (613) 998-2836
On Thu 1999-02-18 (08:10), [EMAIL PROTECTED] wrote: > On Thu, 18 Feb 1999, Peter van Dijk wrote: > > > On Wed, Feb 17, 1999 at 12:33:04PM -0500, [EMAIL PROTECTED] wrote: > > > On Wed, 17 Feb 1999, Chris Naden wrote: > > > > > > for qmail-send: for its description of locals to explicitly say that > > > virtual domains should *not* be placed in locals? > > > > > > for qmail-smtpd: for its description of rcpthosts to say that it > > > should contain all the hosts in locals and virtualdomains plus > > > those hosts you act as MX for. > > > > > > Actually, in stead of the latter suggestion, I'd prefer that there be > > > another control file: mxhosts, and drop rcpthosts, which is just > > > confusing everyone. Then we have simple explanations for what goes where. > > > You're not saying that qmail-smtpd should just read in locals and > > virtualdomains and accept mail for all domains in there, right? > > No. I was suggesting replacing rcpthosts with mxhosts and having > smail-smtpd read virtualdomains, locals and mxhosts. Having looked at > "man qmail-control" I've decided that the reason Dan did things this way > is that qmail-smtpd only has to read/check one file (rcpthosts), rather > than three (virtualdomains, locals and mxhosts). It's a typical tradeoff: > simpler program vs requiring people to read the documentation and put the > right things in rcpthosts. I quite like the way Dan has made rcpthosts work. It allows you to easily specify who you'll receive mail for in one place. The only thing that I'd like is for the behaviour when rcpthosts doesn't exist to change. Since the "normal" thing is for rcpthosts to be locals + virtualdomains I think that this should be the default if rcpthosts doesn't exist. - Keith -- Keith Burdis - MSc (Com Sci) - Rhodes University, South Africa Email : [EMAIL PROTECTED] WWW : http://www.rucus.ru.ac.za/~keith/ IRC : Panthras JAPH "Any technology sufficiently advanced is indistinguishable from a perl script" Standard disclaimer. ---
On Thu, Feb 18, 1999 at 12:03:33AM -0000, Russell Nelson wrote: > Scott Schwartz writes: > > Peter van Dijk <[EMAIL PROTECTED]> writes: > > | You're not saying that qmail-smtpd should just read in locals and >virtualdomains and > > | accept mail for all domains in there, right? > > > > Of course it should! (cdb optional.) That avoids the whole multiple > > redundancy plus illogical defaults problem that the current scheme > > suffers from. > > > > If you want an optional rcpthosts or mxhosts for special cases, then > > fine, that's a special case, which mostly no one will ever need to know > > about. > > You still need to be able to subtract local-only domain names, and add > non-local domain names. I would say that qmail-smtpd should access a > cdb which is constructed from locals + virtualdomains + a new file > named receivebysmtp, which has lines that start with a + if the host > should be acceptable for receipt via SMTP, and a minus if the host > should not be acceptable (which is another way of saying "was found in > locals or virtualdomains but we wish to reject"). Amen to that! Greetz, Peter. -- .| Peter van Dijk | <mo|VERWEG> stoned worden of coden .| [EMAIL PROTECTED] | <mo|VERWEG> dat is de levensvraag | <mo|VERWEG> coden of stoned worden | <mo|VERWEG> stonend worden En coden | <mo|VERWEG> hmm | <mo|VERWEG> dan maar stoned worden en slashdot lezen:)
On Thu, Feb 18, 1999 at 08:10:20AM -0500, [EMAIL PROTECTED] wrote: > On Thu, 18 Feb 1999, Peter van Dijk wrote: > > > On Wed, Feb 17, 1999 at 12:33:04PM -0500, [EMAIL PROTECTED] wrote: > > > On Wed, 17 Feb 1999, Chris Naden wrote: > > > > > > for qmail-send: for its description of locals to explicitly say that > > > virtual domains should *not* be placed in locals? > > > > > > for qmail-smtpd: for its description of rcpthosts to say that it > > > should contain all the hosts in locals and virtualdomains plus > > > those hosts you act as MX for. > > > > > > Actually, in stead of the latter suggestion, I'd prefer that there be > > > another control file: mxhosts, and drop rcpthosts, which is just > > > confusing everyone. Then we have simple explanations for what goes where. > > > You're not saying that qmail-smtpd should just read in locals and > > virtualdomains and accept mail for all domains in there, right? > > No. I was suggesting replacing rcpthosts with mxhosts and having > smail-smtpd read virtualdomains, locals and mxhosts. Having looked at > "man qmail-control" I've decided that the reason Dan did things this way > is that qmail-smtpd only has to read/check one file (rcpthosts), rather > than three (virtualdomains, locals and mxhosts). It's a typical tradeoff: > simpler program vs requiring people to read the documentation and put the > right things in rcpthosts. err.. aahhhhhhhhhh!!!!!!! I have local-only domains that _are_ in locals or virtualdomains, but not in rcpthosts. And I don't want 'm to either. The suggestion Russ posted is what I'm looking for (no rcpthosts, but smtpd accepting mail for all domains in locals, virtualdomains and mxhosts, and a way to list domains _not_ to accept mail for, even though they are in one of the first two files). Greetz, Peter. -- .| Peter van Dijk | <mo|VERWEG> stoned worden of coden .| [EMAIL PROTECTED] | <mo|VERWEG> dat is de levensvraag | <mo|VERWEG> coden of stoned worden | <mo|VERWEG> stonend worden En coden | <mo|VERWEG> hmm | <mo|VERWEG> dan maar stoned worden en slashdot lezen:)
Russell Nelson <[EMAIL PROTECTED]> writes: > ... I would say that qmail-smtpd should access a > cdb which is constructed from locals + virtualdomains + a new file > named receivebysmtp, which has lines that start with a + if the host > should be acceptable for receipt via SMTP, and a minus if the host > should not be acceptable (which is another way of saying "was found in > locals or virtualdomains but we wish to reject"). I'd like to consider going a step further, with a single CDB that contains the *entire* site configuration policy. This would include rcpthosts, localhosts, virtualdomains, users, aliases, and smtproutes. This would be used by qmail-smtpd, to decide what to accept (both for "I don't relay" and "Unknown user" purposes) and by qmail-send as it routes mail. As a bonus, a small tool could query this and allow an admin to check how qmail is going to handle a given address. It would presumably require progressively stripping an address until a match came up, possibly along the lines of: [EMAIL PROTECTED]: accept, local ~adb [EMAIL PROTECTED]: accept, alias [EMAIL PROTECTED] @onramp.ca: reject 550 Unknown user {since no specific-user records matched} .example.com: accept, relay { for a customer } .private.onramp.ca: accept, route 10.11.12.13 @virtual.example.com: accept, virtual ~exam default: norelay { unless RELAYCLIENT is set } Hmm, it might also be nice to check MAIL FROM: against that database, and refuse to relay for users who have set their address to a local one that we know does not exist; that way their POP client tells them the error of their ways immediately. Configuration errors like that are the second largest source of doublebounces. -- Anthony DeBoer <[EMAIL PROTECTED]>
>Yes, 700 connections seems high, but after some period of down time, it seems to Just to emphasize what I was saying. I reckon for 30K users (was that the number-ish?), 700 is far higher than normal. I know there is no such thing as normal, but... > tcpserver -l$hostvalue -q -b100 -H -R -D 0 pop-3 > tcpserver -l$hostvalue -q -b50 -H -R -D 0 2001 > tcpserver -l$hostvalue -t8 -q -b5000 -D -u502 -g2108 > tcpserver -l$hostvalue -t8 -q -b50 -D -u502 -g2108 In all cases, change the -b to a -c >After reading "man listen" I am reminded of the help this list gave us when we >had this problem before. Our connections were being artificially limited by >Linux to 5 at a time! This was solved with adding the -b20 (then later upping It *may* be worth upping it beyond the default, but the listen queue really only comes into effect if tcpserver isn't keeping up with the inbound connection rate. As long as tcpserver is doing the accept and passoff to qmail-smtpd in enough time, the backlog doesn't apply. the concurrency with -c does of course. >If one server reaches this limit, it is overloaded and if lucky it is dropped >out of the rotation by the alteon. This causes the other servers to overload >and reach the same state. Is the alteon configured to load balance of switch on no response? Also, is it possible to bypass the Alteon for a while? There may be some unknown interaction there. Regards.
YES, USE THE -c OPTION TO TCPSERVER. The -b sets the backlog. -c sets the number of simultaneous TCP sessions that tcpserver will process. You have increased the backlog but have not increased the number of sessions each server will accept. The default is 40! On Thu, 18 Feb 1999, Jere Cassidy wrote: > > What is wrong with the following setup: > > less than 30K customers: > > qmail 1.03 running on 3 high speed alpha's (each with 128MB ram) > Running 4 TCPSERVER daemon processes. > > > 1 SMTP (port 25) > 1 POP3 (port 110) > 1 SMTP (port 2001) > 1 POP3 (port 2002) > > These 3 servers running these 4 daemons share a Netapp filer for backend > storage. > > We have done major tuning to these servers time after time. Here is the > current situation: > 3 of the daemons run fine. the SMTP (on regular port 25) does not > respond. > > I have set the -b option for TCPserver(this helped us immensely before) > to 5000 (supposedly allowing tcpserver to respond to 5000 connections). > > Is there some default limit somewhere that would only allow tcpserver to > pass so many connections to qmail-smtpd? The downtime on the servers is > getting rediculous because of this problem. > > If I run /var/qmail/bin/qmail-smtpd it comes right up. > If I telnet localhost 2002 (simply another instance of tcpserver) it > comes right up. > Both POP3 connections come right up > > If i do a "netstat -n|grep ":25 " I get almost 700 connections although > most of these are in the "CLOSE WAIT" stage or something similar. > > On one of the servers, when this happens and qmail is totally > unresponsive on port 25, the load drops to 0.00 and the server just sits > there. > > restarting qmail seems to help for about 5 minutes... then the imaginary > limit is hit and everything goes to hell. > > Anyone have any suggestions for the current situation? > > > > > > > > > -- > ------------------------------------------------------------------------ > > // Jere Cassidy - System Administration - D&E SuperNet > email: [EMAIL PROTECTED] phone: (717)738-7054 > web: http://www.desupernet.net/jere > pager/pcs: [EMAIL PROTECTED] - (717)203-0042 > ~~~ "While sowing the seeds of Utopia, > you invoked a convenient amnesia" -BR ~~~ > ------------------------------------------------------------------------ > > > > --------------------------------- Timothy L. Mayo mailto:[EMAIL PROTECTED] Senior Systems Manager localconnect(sm) http://www.localconnect.net/ The National Business Network Inc. http://www.nb.net/ One Monroeville Center, Suite 850 Monroeville, PA 15146 (412) 810-8888 Phone (412) 810-8886 Fax
Mark, We removed the -c options because we are currently using qmail/control/concurrencyremote and qmail/control/concurrencylocal. should we also add -c options to tcpserver? I know that the backlog _is_ an issue. Our performance increased so much when we did -b30 instead of letting the default take over (5). Every time we have upped this number, we get performance gains. The problem is that if only one server is left in the Alteon's rotation, it seems to get more than 128 connections in a matter of minutes. These then seem to have a logarythmic effect. The more connections queue up, the more connections are delayed, the more connections are queued up... etc... This leads to the 700 number (which i do admit is extermely high-- netstat showed some 590 smtp connects). During the slow time this morning after i got all 3 servers handling mail, we had about 24 connections total (not just smtp). Now that i think about it... it seems if the connections eclispse approximately 200, we start to have incredible delay on the smtp connects. (this leads me to believe that 128 limit mentioned in Redhat Linux 5.2's `man listen` might be our problem). I am unsure what to do next.... is there a way to up this limit (besides hacking the kernel somewhere)? Do other unices perform better in this area? Doesn't anyone else have this problem ? The alteon takes out servers that are not responsive to its SMTP and/or POP3 connects. It would be difficult to take it out at this point. It has helped us immensely in system availability, but I truly believe that our main server (an alpha633) would be able to handle _all_ the load if it didnt run into these tcpserver/max connection issues. Thanks again for the help Mark and anyone else who wishes to contribute! -Jere Mark Delany wrote: > >Yes, 700 connections seems high, but after some period of down time, it seems to > > Just to emphasize what I was saying. I reckon for 30K users (was that the > number-ish?), 700 is far higher than normal. I know there is no such thing > as normal, but... > > > tcpserver -l$hostvalue -q -b100 -H -R -D 0 pop-3 > > tcpserver -l$hostvalue -q -b50 -H -R -D 0 2001 > > tcpserver -l$hostvalue -t8 -q -b5000 -D -u502 -g2108 > > tcpserver -l$hostvalue -t8 -q -b50 -D -u502 -g2108 > > In all cases, change the -b to a -c > > >After reading "man listen" I am reminded of the help this list gave us when we > >had this problem before. Our connections were being artificially limited by > >Linux to 5 at a time! This was solved with adding the -b20 (then later upping > > It *may* be worth upping it beyond the default, but the listen queue really > only comes into effect if tcpserver isn't keeping up with the inbound > connection rate. > > As long as tcpserver is doing the accept and passoff to qmail-smtpd in > enough time, the backlog doesn't apply. the concurrency with -c does of course. > > >If one server reaches this limit, it is overloaded and if lucky it is dropped > >out of the rotation by the alteon. This causes the other servers to overload > >and reach the same state. > > Is the alteon configured to load balance of switch on no response? > > Also, is it possible to bypass the Alteon for a while? There may be some > unknown interaction there. > > Regards. -- ------------------------------------------------------------------------ // Jere Cassidy - System Administration - D&E SuperNet email: [EMAIL PROTECTED] phone: (717)738-7054 web: http://www.desupernet.net/jere pager/pcs: [EMAIL PROTECTED] - (717)203-0042 ~~~ "While sowing the seeds of Utopia, you invoked a convenient amnesia" -BR ~~~ ------------------------------------------------------------------------
Yes, you NEED the -c option. The qmail concurency limits are for OUTGOING mail (either local or remote). The tcpserver -c option set concurrency for INCOMING TCP connections which is where you are having the problem..... The default is 40, I would try 80 or 100 and see what happens. On Thu, 18 Feb 1999, Jere Cassidy wrote: > Mark, > We removed the -c options because we are currently using > qmail/control/concurrencyremote and qmail/control/concurrencylocal. should we also > add -c options to tcpserver? > > I know that the backlog _is_ an issue. Our performance increased so much when we did > -b30 instead of letting the default take over (5). Every time we have upped this > number, we get performance gains. The problem is that if only one server is left in > the Alteon's rotation, it seems to get more than 128 connections in a matter of > minutes. These then seem to have a logarythmic effect. The more connections queue > up, the more connections are delayed, the more connections are queued up... etc... > This leads to the 700 number (which i do admit is extermely high-- netstat showed > some 590 smtp connects). During the slow time this morning after i got all 3 servers > handling mail, we had about 24 connections total (not just smtp). > > Now that i think about it... it seems if the connections eclispse approximately 200, > we start to have incredible delay on the smtp connects. (this leads me to believe > that 128 limit mentioned in Redhat Linux 5.2's `man listen` might be our problem). I > am unsure what to do next.... is there a way to up this limit (besides hacking the > kernel somewhere)? Do other unices perform better in this area? Doesn't anyone else > have this problem ? > > The alteon takes out servers that are not responsive to its SMTP and/or POP3 > connects. > It would be difficult to take it out at this point. It has helped us immensely in > system availability, but I truly believe that our main server (an alpha633) would be > able to handle _all_ the load if it didnt run into these tcpserver/max connection > issues. > Thanks again for the help Mark and anyone else who wishes to contribute! > > -Jere > > > Mark Delany wrote: > > > >Yes, 700 connections seems high, but after some period of down time, it seems to > > > > Just to emphasize what I was saying. I reckon for 30K users (was that the > > number-ish?), 700 is far higher than normal. I know there is no such thing > > as normal, but... > > > > > tcpserver -l$hostvalue -q -b100 -H -R -D 0 pop-3 > > > tcpserver -l$hostvalue -q -b50 -H -R -D 0 2001 > > > tcpserver -l$hostvalue -t8 -q -b5000 -D -u502 -g2108 > > > tcpserver -l$hostvalue -t8 -q -b50 -D -u502 -g2108 > > > > In all cases, change the -b to a -c > > > > >After reading "man listen" I am reminded of the help this list gave us when we > > >had this problem before. Our connections were being artificially limited by > > >Linux to 5 at a time! This was solved with adding the -b20 (then later upping > > > > It *may* be worth upping it beyond the default, but the listen queue really > > only comes into effect if tcpserver isn't keeping up with the inbound > > connection rate. > > > > As long as tcpserver is doing the accept and passoff to qmail-smtpd in > > enough time, the backlog doesn't apply. the concurrency with -c does of course. > > > > >If one server reaches this limit, it is overloaded and if lucky it is dropped > > >out of the rotation by the alteon. This causes the other servers to overload > > >and reach the same state. > > > > Is the alteon configured to load balance of switch on no response? > > > > Also, is it possible to bypass the Alteon for a while? There may be some > > unknown interaction there. > > > > Regards. > > -- > ------------------------------------------------------------------------ > // Jere Cassidy - System Administration - D&E SuperNet > email: [EMAIL PROTECTED] phone: (717)738-7054 > web: http://www.desupernet.net/jere > pager/pcs: [EMAIL PROTECTED] - (717)203-0042 > ~~~ "While sowing the seeds of Utopia, > you invoked a convenient amnesia" -BR ~~~ > ------------------------------------------------------------------------ > > > --------------------------------- Timothy L. Mayo mailto:[EMAIL PROTECTED] Senior Systems Manager localconnect(sm) http://www.localconnect.net/ The National Business Network Inc. http://www.nb.net/ One Monroeville Center, Suite 850 Monroeville, PA 15146 (412) 810-8888 Phone (412) 810-8886 Fax
Doh! I did not realize that this was the issue. my esteemed co-worker decided to start using the concurrency files in qmail/control and i assumed these were the same. ( a really stupid assumption) I will set these up and perform test on the servers. Thanks Mark John and Tim. I guess I really should have rechecked the tcpserver man pages as you guys suggested! RTFM! Thanks again. If this doesn't work I am going to join my Luddite pals in Canada! "Timothy L. Mayo" wrote: > YES, USE THE -c OPTION TO TCPSERVER. The -b sets the backlog. -c sets > the number of simultaneous TCP sessions that tcpserver will process. You > have increased the backlog but have not increased the number of sessions > each server will accept. The default is 40! > > On Thu, 18 Feb 1999, Jere Cassidy wrote: > > > > > What is wrong with the following setup: > > > > less than 30K customers: > > > > qmail 1.03 running on 3 high speed alpha's (each with 128MB ram) > > Running 4 TCPSERVER daemon processes. > > > > > > 1 SMTP (port 25) > > 1 POP3 (port 110) > > 1 SMTP (port 2001) > > 1 POP3 (port 2002) > > > > These 3 servers running these 4 daemons share a Netapp filer for backend > > storage. > > > > We have done major tuning to these servers time after time. Here is the > > current situation: > > 3 of the daemons run fine. the SMTP (on regular port 25) does not > > respond. > > > > I have set the -b option for TCPserver(this helped us immensely before) > > to 5000 (supposedly allowing tcpserver to respond to 5000 connections). > > > > Is there some default limit somewhere that would only allow tcpserver to > > pass so many connections to qmail-smtpd? The downtime on the servers is > > getting rediculous because of this problem. > > > > If I run /var/qmail/bin/qmail-smtpd it comes right up. > > If I telnet localhost 2002 (simply another instance of tcpserver) it > > comes right up. > > Both POP3 connections come right up > > > > If i do a "netstat -n|grep ":25 " I get almost 700 connections although > > most of these are in the "CLOSE WAIT" stage or something similar. > > > > On one of the servers, when this happens and qmail is totally > > unresponsive on port 25, the load drops to 0.00 and the server just sits > > there. > > > > restarting qmail seems to help for about 5 minutes... then the imaginary > > limit is hit and everything goes to hell. > > > > Anyone have any suggestions for the current situation? > > > > > > > > > > > > > > > > > > -- > > ------------------------------------------------------------------------ > > > > // Jere Cassidy - System Administration - D&E SuperNet > > email: [EMAIL PROTECTED] phone: (717)738-7054 > > web: http://www.desupernet.net/jere > > pager/pcs: [EMAIL PROTECTED] - (717)203-0042 > > ~~~ "While sowing the seeds of Utopia, > > you invoked a convenient amnesia" -BR ~~~ > > ------------------------------------------------------------------------ > > > > > > > > > > --------------------------------- > Timothy L. Mayo mailto:[EMAIL PROTECTED] > Senior Systems Manager > localconnect(sm) > http://www.localconnect.net/ > > The National Business Network Inc. http://www.nb.net/ > One Monroeville Center, Suite 850 > Monroeville, PA 15146 > (412) 810-8888 Phone > (412) 810-8886 Fax -- ------------------------------------------------------------------------ // Jere Cassidy - System Administration - D&E SuperNet email: [EMAIL PROTECTED] phone: (717)738-7054 web: http://www.desupernet.net/jere pager/pcs: [EMAIL PROTECTED] - (717)203-0042 ~~~ "While sowing the seeds of Utopia, you invoked a convenient amnesia" -BR ~~~ ------------------------------------------------------------------------
At 09:01 AM 2/18/99 -0500, Jere Cassidy wrote: >Mark, >We removed the -c options because we are currently using >qmail/control/concurrencyremote and qmail/control/concurrencylocal. should we also >add -c options to tcpserver? Correct. They are two different controls. The -c option defines how many inbound connections you will accept at one time. concurrencyremote defines how many *outbound* connetions you will initiate at one time. >Now that i think about it... it seems if the connections eclispse approximately 200, >we start to have incredible delay on the smtp connects. (this leads me to believe >that 128 limit mentioned in Redhat Linux 5.2's `man listen` might be our problem). I >am unsure what to do next.... is there a way to up this limit (besides hacking the >kernel somewhere)? Do other unices perform better in this area? Doesn't anyone else >have this problem ? As I've said previously. I'd be surprised if backlog is a problem. Now that I think about it, limits may be a problem if tcpserver has inherited low limits. But that's additional to changing to -c. One thing at a time. >It would be difficult to take it out at this point. It has helped us immensely in Right. Well let's just get the local settings right first and see what happens. >system availability, but I truly believe that our main server (an alpha633) would be >able to handle _all_ the load if it didnt run into these tcpserver/max connection >issues. I agree. You have a lot more horsepower than I've used for much larger user bases. So, change the tcpserver to use -c and restart tcpserver. There is no need to restart qmail. Regards.
Jere Cassidy writes: > Mark, > We removed the -c options because we are currently using > qmail/control/concurrencyremote and qmail/control/concurrencylocal. should we also > add -c options to tcpserver? Bad boy! concurrencyremote/local are for outgoing E-mail. -c option to tcpserver sets the limit for incoming E-mail. You were defaulting to a maximum of 40 inbound connections at the same time. I'd say you should bump it up to about 300. -- Sam
On Thu, 18 Feb 1999, Jere Cassidy wrote: -| If i do a "netstat -n|grep ":25 " I get almost 700 connections although -| most of these are in the "CLOSE WAIT" stage or something similar. What kernel revision are you running? I know some of the 2.0.3X kernels pre .36 supposedly have a problem with never dropping connections. So, even though the client side has dropped, the server keeps it alive, and this is counted in tcp servers max. Here's an example: tcp 32696 645 ns1.netmdc.com:17117 pm3-1.netmdc.com:telnet FIN_WAIT1 tcp 32696 555 ns1.netmdc.com:17162 pm3-1.netmdc.com:telnet FIN_WAIT1 tcp 32696 675 ns1.netmdc.com:25151 pm3-1.netmdc.com:telnet FIN_WAIT1 tcp 32216 638 ns1.netmdc.com:25351 pm3-1.netmdc.com:telnet FIN_WAIT1 tcp 32696 670 ns1.netmdc.com:26194 pm3-1.netmdc.com:telnet FIN_WAIT1 tcp 32696 625 ns1.netmdc.com:14393 pm3-1.netmdc.com:telnet FIN_WAIT1 tcp 32696 625 ns1.netmdc.com:16940 pm3-1.netmdc.com:telnet FIN_WAIT1 tcp 32696 630 ns1.netmdc.com:16948 pm3-1.netmdc.com:telnet FIN_WAIT1 tcp 32696 615 ns1.netmdc.com:17031 pm3-1.netmdc.com:telnet FIN_WAIT1 tcp 32696 689 ns1.netmdc.com:17204 pm3-1.netmdc.com:telnet FIN_WAIT1 tcp 32696 615 ns1.netmdc.com:17531 pm3-1.netmdc.com:telnet FIN_WAIT1 tcp 32696 576 ns1.netmdc.com:18093 pm3-1.netmdc.com:telnet FIN_WAIT1 tcp 0 14706 ns1.netmdc.com:telnet byu006601wks.rn.b:61165 ESTABLISHED tcp 19 0 ns1.netmdc.com:5299 pm2-4.netmdc.com:telnet CLOSE_WAIT This happened when i had to reboot the portmaster, the connections never cleaned up properly. This was WELL over a week ago ;) _ __ _____ __ _________ ______________ /_______ ___ ____ /______ John Gonzalez/Net.Tech __ __ \ __ \ __/_ __ `__ \/ __ /_ ___/ MDC Computers/netMDC! _ / / / `__/ /_ / / / / / / /_/ / / /__ (505)437-7600/fax-437-3052 /_/ /_/\___/\__/ /_/ /_/ /_/\__,_/ \___/ http://www.netmdc.com [---------------------------------------------[system info]-----------] 12:30pm up 13 days, 19:10, 3 users, load average: 0.25, 0.48, 0.27
On Mon, 15 Feb 1999, John R. Levine wrote: > If this sounds interesting, let me know and I'll pack up my scripts. > There's a perl script to handle the bounces, and a shell script that > creates the lists and makes the .qmail files. Yes, this sounds interesting! I'd like to see your scripts. ---------------------------------------------------------- Chuck Milam I.T. Division - Academic Computing [EMAIL PROTECTED] University of Wisconsin at Oshkosh
On Wed, Feb 17, 1999 at 02:48:44PM -0800, Kai MacTane <[EMAIL PROTECTED]> wrote: > At 04:00 PM 2/17/99 -0600, Bruno Wolff III wrote: > > > >That is why people should add Mail-Followup-To headers when posting to lists. > >That way the responder doesn't need to worry about whether the author > >was on the list or not, that header will indicate where group replies > >should go. > > Interestingly, I just got two copies of this message. If you were using the > feature you mention, it wasn't handled properly by this list. You got two copies because you didn't use a Mail-Followup-To header to indicate you were on the list. I manually removed you this time since it seems you are on the list. > > And I don't see any Mail-Followup-To header in either of the messages I got. That is because I didn't change my lists list when the qmail and ezmlm lists moved. Thanks for pointing this out.
On Wed, Feb 17, 1999 at 11:52:22PM -0000, Russell Nelson wrote: > Tim Pierce writes: > > Unfortunately, there's an awful lot of unreasonable mailers in the > > world, which makes that philosophy impractical. > > Pandering to the unreasonable mailers doesn't help. The chief cost is > one of embarrassment to the poor slob who forgot that he was replying > to a mailing list. We've all seen it happen. I can't imagine that > anybody thinks that's a good thing. > > How's about we get the unreasonable mailers fixed? Sounds great! I'm all ears. Where do we submit bug reports for Microsoft Internet Mail, Microsoft Outlook, and WebTV? The sad reality is that mailers for the consumer world are getting worse and not better, and we have little power to fix that. Mailers that lack "group-reply" are only the tip of the iceberg; they also lack any useful filtering or filing capability, they fail to identify the message sender, they send replies to the wrong address, they send replies with broken return addresses. Managing a mailing list means making the decision about how to handle people like this. If you're a toy site, you can probably get away with telling all your users to lose the broken software. You can't get away with telling 50,000 users to lose their broken software. Pandering to these users doesn't necessarily help, but ignoring them is no better a solution. Ultimately you have to find some way to cope with their brain damage, until we figure out how to fix it. Like I said, I'm all ears. -- Regards, Tim Pierce RootsWeb Genealogical Data Cooperative system obfuscator and hack-of-all-trades
Tim Pierce writes: > Sounds great! I'm all ears. Where do we submit bug reports for > Microsoft Internet Mail, Microsoft Outlook, and WebTV? The problem (as I see it) is that there is no requirements or even guidelines for MUAs. How's about we get all the mailing list manager people together, and bash out a set of requirements that a mailing list-friendly MUA will have. Then we either find a group to publish them, or else create our own group, and publish them ourselves. Yeah, it's work, but arguing about inserting reply-to is also work. :) I'll be happy to run the mailing list, only ... I'm going to ban the topic of inserting reply-to. :) Anybody have a laundry list of mailing list managers, along with the appropriate places to contact the maintainers? -- -russ nelson <[EMAIL PROTECTED]> http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | There is good evidence 521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace.
On Thu, Feb 18, 1999 at 11:03:26PM -0000, Russell Nelson wrote: > Tim Pierce writes: > > Sounds great! I'm all ears. Where do we submit bug reports for > > Microsoft Internet Mail, Microsoft Outlook, and WebTV? > > The problem (as I see it) is that there is no requirements or even > guidelines for MUAs. How's about we get all the mailing list manager > people together, and bash out a set of requirements that a mailing > list-friendly MUA will have. Then we either find a group to publish > them, or else create our own group, and publish them ourselves. > If all the freely available MUAs and MTAs and list managers decide that they will stick to certain reasonable standards, there will be enough protest from frustrated subscribers to force Microsoft and friends to make their MUAs compatible with these standards. ISPs instead of lowering their standards, perhaps should start giving away smart (and friendly) MUAs to their customers. If these do not exist yet---sponsor projects that would make them. -- --- Mate Wierdl | Dept. of Math. Sciences | University of Memphis
>The problem (as I see it) is that there is no requirements or even >guidelines for MUAs. How's about we get all the mailing list manager >people together, and bash out a set of requirements that a mailing >list-friendly MUA will have. Then we either find a group to publish >them, or else create our own group, and publish them ourselves. But there ARE requirements and guidelines for MUAs. They're called RFCs :) Of course, I know plenty of people choose to ignore RFCs. I can offer some suggestions: * Publicize it as much as possible that XYZ Company makes defective software, or if you can't say "defective" say "non-compliant with generally accepted Internet standards". * Get companies (starting with your own) to adopt RFCs or similar as real standards, bound by contractual agreements with an industry association. Consumer electronics companies have done this for years. Everyone's VHS players read tapes the same way. Everyone's CD players read CDs the same way. * Refuse to help people who insist on using broken software. This is a matter of principle more than anything. The minute you start patching your good server against their bad client, you've lost the battle and it's only a matter of time before they ask you to fix this, and this, and this, and... * If that's not an option, support only the stuff you have to and make it clear that in the future you won't be supporting broken code. * If you're an ISP, don't distribute crappy software. Find something free or tell your users what works and what doesn't. I have no problem with software that has extra features to be able to take advantage of more featureful servers. But those clients should be able to handle servers without the features. shag
Racer X writes: > But there ARE requirements and guidelines for MUAs. They're called RFCs :) Which RFC says ``Thou shalt have separate "Reply to Sender", "Reply to List"[1], and "Reply to All" buttons''? [1] which, of course, really means "Reply to Recipient", but that action only makes sense when the To: address is a mailing list, so better to say "Reply to List". -- -russ nelson <[EMAIL PROTECTED]> http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | There is good evidence 521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace.
>Which RFC says ``Thou shalt have separate "Reply to Sender", "Reply to >List"[1], and "Reply to All" buttons''? > >[1] which, of course, really means "Reply to Recipient", but that >action only makes sense when the To: address is a mailing list, so >better to say "Reply to List". Well, okay, I suppose if people aren't going to bother to do anything with the information provided by the RFC-compliant servers, there's not a lot we can do about that. As for this particular issue, I think it's a much bigger pain that all mailing list software handles Reply-To in a different way. As long as they either all honored Reply-To or all threw it out, this wouldn't be nearly as big a deal. I don't think it would be too hard to come up with a "baseline" standard of what a mail client should do. I'm sure people would claw and scratch over just what would go in the standard, but as a wise man once said "Better to have a bad standard than no standard at all". There is, after all, some basic level of functionality that all SMTP MUAs have (they all talk SMTP, for starters); why not build on that? shag
On Wed, 17 Feb 1999 18:09:39 -0500, Tim Pierce wrote: >Unfortunately, there's an awful lot of unreasonable mailers in the >world, which makes that philosophy impractical. While I sympathize >with the opinions offered in "Reply-to Considered Harmful," it's >mostly ivory tower theorizing. I use (MUA) PMMail and it works beautifly with mailinglists that set Reply-To to their adress. When I hit reply it tells me that From: and Reply-To: fields differ and asks me to what e-mail adress do I want to reply (to mailing list or to the author personal mailbox). -> Now that's a smart MUA. And nearly all responses to my post that I got were delivered to me twice: Once thru mailing list and once directly. What a waste of my time and bandwidth :(. So please if you reply... I'm on the mailing list.. no need to send me another copy directly. Not to mention the need to type the mailing list name into the To: field. Actualy... I've almost sent a few reply that I wanted to go to the mailing list personaly to the original poster. best regards, Rok Papez, Student at Faculty of Computer and Information Science, University of Ljubljana, Slovenia.
On 18 Feb 1999 23:03:26 -0000, Russell Nelson wrote: >The problem (as I see it) is that there is no requirements or even >guidelines for MUAs. How's about we get all the mailing list manager >people together, and bash out a set of requirements that a mailing >list-friendly MUA will have. Then we either find a group to publish >them, or else create our own group, and publish them ourselves. > >Yeah, it's work, but arguing about inserting reply-to is also work. :) It already works grat with PMMail (it is also available for Windows). The mailing list sets the Reply-To: address to the mailing list, the From: field is preserved. When I hit the Reply buttin in PMMail (MUA), he notices the difference between the "From:" and "Reply-To:" list, pops up a quick dialog asking me to choose to whom to reply; to the list (Reply-To) or to the poster (From:). Voila.. problem solved. Of course.. we could define.. if Reply-To is already set, maybe the mailing list should preserve it (so the people not subscribed to the mailing list could set the Reply-To to their private mailbox or some place else). best regards, Rok Papez, Student at Faculty of Computer and Information Science, University of Ljubljana, Slovenia.
On 02/19, Rok Papez wrote: > >The problem (as I see it) is that there is no requirements or even > >guidelines for MUAs. How's about we get all the mailing list manager > >people together, and bash out a set of requirements that a mailing > >list-friendly MUA will have. Then we either find a group to publish > >them, or else create our own group, and publish them ourselves. > >Yeah, it's work, but arguing about inserting reply-to is also work. :) > It already works grat with PMMail (it is also available for Windows). > The mailing list sets the Reply-To: address to the mailing list, the > From: field is preserved. When I hit the Reply buttin in PMMail (MUA), > he notices the difference between the "From:" and "Reply-To:" list, > pops up a quick dialog asking me to choose to whom to reply; to the > list > (Reply-To) or to the poster (From:). AFAIK most windoze programs handle Reply-To: properly. Unfortunately, it's not a technical problem. > Voila.. problem solved. No! Solved for you only. You might cope with it just fine, but once in a while someone hit the wrong button... and oops, we all see some pretty interesting comments flying through the list. Let 'em insert list addres deliberately. It also helps to keep traffic a little lower. -- Roman V. Isaev http://www.gunlab.com.ru Moscow, Russia
Racer X writes: > >Which RFC says ``Thou shalt have separate "Reply to Sender", "Reply to > >List"[1], and "Reply to All" buttons''? > > > >[1] which, of course, really means "Reply to Recipient", but that > >action only makes sense when the To: address is a mailing list, so > >better to say "Reply to List". > > Well, okay, I suppose if people aren't going to bother to do anything with > the information provided by the RFC-compliant servers, there's not a lot we > can do about that. As for this particular issue, I think it's a much > bigger pain that all mailing list software handles Reply-To in a different > way. As long as they either all honored Reply-To or all threw it out, this > wouldn't be nearly as big a deal. Um, no. Everybody honors Reply-To. The problem is that most MUAs don't include the concept of "Reply to Recipient". Why? Because, on the face of it, it looks like a stupid idea. Why would you want to reply to yourself? You wouldn't. But you *might* want to Reply To List, which is implemented the same way. > I don't think it would be too hard to come up with a "baseline" standard of > what a mail client should do. I'm sure people would claw and scratch over > just what would go in the standard, but as a wise man once said "Better to > have a bad standard than no standard at all". There is, after all, some > basic level of functionality that all SMTP MUAs have (they all talk SMTP, > for starters); why not build on that? Right, well, we can do it ourselves. Who else do we need to convince? -- -russ nelson <[EMAIL PROTECTED]> http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | There is good evidence 521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace.
We had the "other" vacation working under IRIX 5.3 but since we have moved to 6.5 it doesn't work. Our qmail config is the same, so I can't really say why it doesn't work. I have read both the IRIX (sendmail) vacation and the Peter Samuel vacation manuals, but can't make the old one work again. We have a sendmail wrapper that does this: ella 1# more /usr/lib/sendmail #!/bin/sh cat | /var/qmail/bin/predate /var/qmail/bin/qmail-inject ...and as stated (below) we were using preline like this: |preline vacation YourLogin Peter's vacation works great, but I am instructed to fix the "other" vacation (if possible)...any help would be appreciated :) Samuel Daffner Mills College ITS On Mon, 15 Feb 1999, Peter Samuel wrote: > On Fri, 12 Feb 1999, Len Budney wrote: > > > "Peter Samuel" <[EMAIL PROTECTED]> wrote: > > > It doesn't ship as an rpm. It ships as source code and you have to > > > build it yourself. This is a trivial task as all you need to do is > > > modify the Makefile and tell it where you want to install it and where > > > perl lives. > > > > Though it doesn't ship as an RPM, there are user-contributed RPMs. > > You can get the latest on from: > > > > <http://rufus.w3.org/linux/RPM/VByName.html> > > None of these is the one I wrote (modified) specifically for use with > qmail. My guess is that they'll all require the use of preline which > will cause failures. (See www.qmail.org for an explanation as to why > it will fail). > > Regards > Peter > ---------- > Peter Samuel [EMAIL PROTECTED] > Technical Consultant or at present: > Uniq Professional Services, [EMAIL PROTECTED] > a division of X-Direct Pty Ltd > Phone: +61 2 9206 3410 Fax: +61 2 9281 1301 > > "If you kill all your unhappy customers, you'll only have happy ones left" > >
I'll soon (read: before the close of business today) be running several virtual domains on my one qmail server, domain.net, domain1.com, domain2.com, etc. Presently, I have domain.net set as the defaultdomain in the control files. Does that mean that when [EMAIL PROTECTED] send email thought the smtp side that his address will be munged to [EMAIL PROTECTED], and the same for all of the other users of all of the other domains? This is unacceptable. I need for users in domain1.com to remain seperate from users in domain2.com. I just want to use a single point of administration for them all. Is this a real problem, or am I just barking up the wrong man page again? -- Matt Garrett, Network Engineer (with Laryngitis) Superior Open Systems [EMAIL PROTECTED]
On Thu, Feb 18, 1999 at 12:22:45PM +0000, Matt Garrett wrote: > I'll soon (read: before the close of business today) be running several virtual > domains on my one qmail server, domain.net, domain1.com, domain2.com, etc. > Presently, I have domain.net set as the defaultdomain in the control files. Does > that mean that when [EMAIL PROTECTED] send email thought the smtp side that his > address will be munged to [EMAIL PROTECTED], and the same for all of the other > users of all of the other domains? This is unacceptable. I need for users in > domain1.com to remain seperate from users in domain2.com. I just want to use > a single point of administration for them all. Nope. qmail won't screw around with address headers on SMTP-injected mail. It won't screw with address headers on anything if they're fully specified, i.e. they have a local part and an @ sign and a domain part with a dot in it. defaultdomain only comes into play if the supplied domain in an address header is missing or has no dots. Chris
I am running Linux and I am removing sendmail because of the recurring security problems with it. I am finding the installation of qmail however a little difficult because of the complex interplay between a large variety of programs. I do not want to install using the rpms. The questions I have are: 1. assuming that I want a basic setup and don't want to use inetd which programs other than qmail and ucspi-tcp are required to be installed? What about daemontools and functions? Why do I need these? 2. what is qmail-smtp as opposed to qmail? What are the sendmail equivalents if any. For sendmail there is only the sendmail binary which acts as both transport and server. 3. assuming I want a simple basic setup, is there an easy todo list that someone can refer me to? I don't have a lot of time to look into the many programs (i.e., functions, daemontools,etc). Thanks in advance, Mark
[EMAIL PROTECTED] writes: > 1. assuming that I want a basic setup and don't want to > use inetd which programs other than qmail and ucspi-tcp are > required to be installed? What about daemontools and functions? > Why do I need these? This depends on what exactly you wish to do. To duplicate sendmail functionality exactly, all you need are qmail and ucspi-tcp. If you also need to provide POP3 access, or something else of that nature, you'll need other stuff too. > 2. what is qmail-smtp as opposed to qmail? What are the sendmail > equivalents if any. For sendmail there is only the sendmail binary > which acts as both transport and server. qmail-smtp handles incoming mail via SMTP. qmail refers to the entire package. > 3. assuming I want a simple basic setup, is there an easy todo > list that someone can refer me to? I don't have a lot of time > to look into the many programs (i.e., functions, daemontools,etc). RTFM, and follow the INSTALL docs. -- Sam
I'm providing mail hosting for several domains (mydomain.com, foodomain.com, and bardomain.com) with the following configuration: locals: mail.mydomain.com mydomain.com me: mail.mydomain.com rcpthosts: mail.mydomain.com mydomain.com foodomain.com bardomain.com virtualdomains: foodomain.com:foouser bardomain.com:baruser This is great for incoming mail. When foouser or baruser try to send mail from foodomain.com or bardomain.com, however, qmail refuses to relay it. Is there a simple way to make qmail relay mail from domains in virtualdomains? Colin
On Thu, Feb 18, 1999 at 10:19:05AM -0800, Colin Coller wrote: > I'm providing mail hosting for several domains (mydomain.com, foodomain.com, > and bardomain.com) with the following configuration: > > locals: > mail.mydomain.com > mydomain.com > > me: > mail.mydomain.com > > rcpthosts: > mail.mydomain.com > mydomain.com > foodomain.com > bardomain.com > > virtualdomains: > foodomain.com:foouser > bardomain.com:baruser > > This is great for incoming mail. When foouser or baruser try to send mail > from foodomain.com or bardomain.com, however, qmail refuses to relay it. Is > there a simple way to make qmail relay mail from domains in virtualdomains? That depends on what you mean by "mail from domains in virtualdomains." If you mean that you want selected hosts to be able to relay (which is really how things ought to be set up) then see ftp://koobera.math.uic.edu/www/qmail/faq/servers.html#authorized-relay. I suspect that that's not what you mean, and that you'd like people to be able to relay based on a message's envelope sender domain being in virtualdomains. There's no built-in way for qmail to do this, and most people would tell you that it's not a good idea--since anyone can inject mail via SMTP with any envelope sender he wants, anyone could use your host as a relay. You may find patches at http://www.qmail.org to allow relaying based on envelope sender. A better idea might be to implement SMTP-after-POP, where a host would be able to relay for a short period after authenticating by POP. The best idea is for people to use the SMTP servers provided by their ISPs to relay their mail. (Some ISPs are getting stupid these days, though, and requiring for relaying that the domain of the envelope sender to be one of their domains. This is causing me headaches with some of my users, who have various ISPs but who want to use the addresses we provide.) Chris
A related question. In what order does a pop client get messages from a maildir? First all contents of new then cur? does it look into tmp? I'm using pop3d and checkpassword I looked at man maildir and few other man pop3d and man popup. Found an explanation for an MUA, but not for a pop client. cheers - eric
If I get the error message e.g. 503 RCPT first (#5.5.1) what does the "(#5.5.1)" mean? I thought I'd read somewhere it refers to the section 5.5.1 in RFC 1123, but, I can't find such a section in RFC 1123 (neither in RFC 821). I've grep'ed through my private qmail archive, searched the list archives, read the man pages and the FAQs, looked at qmail.org but I can't find the reference any more :( Someone please enlighten me (and put the info on qmail.org?) Thanks \Maex
- Markus Stumpf <[EMAIL PROTECTED]>: | If I get the error message e.g. | 503 RCPT first (#5.5.1) | what does the "(#5.5.1)" mean? I thought I'd read somewhere it refers | to the section 5.5.1 in RFC 1123, but, I can't find such a section in | RFC 1123 (neither in RFC 821). <URL:ftp://koobera.math.uic.edu/www/proto/hcmssc.txt> refers to RFC 1893. - Harald
I have a nagging time zone problem on a RHL 5.2 box using Pine as the MUA and Qmail as the MTA. Take a look at the time stamp on this message to see what I mean. Notice how it says "-0600 (EST)" in the date field. That's not a valid time zone. The box thinks it's in the US-Central time zone, but something (I'm guessing Pine?) is tacking that annoying "EST" on. All the little hacks like making the symbolic link between /usr/lib/zoneinfo and /usr/share/zoneinfo have been done on this box. Can anyone shed some light on this problem? More info that might be useful: Kernel version: 2.0.36 or 2.2.1 Pine version: 4.05 or 4.10 Qmail version: 1.03, installed via the "Memphis" SRPMS. ---------------------------------------------------------- Chuck Milam I.T. Division - Academic Computing [EMAIL PROTECTED] University of Wisconsin at Oshkosh
- Chuck Milam <[EMAIL PROTECTED]>: | Take a look at the time stamp on this message to see what I mean. | Notice how it says "-0600 (EST)" in the date field. That's not a | valid time zone. Nor is it generated by qmail. Date: header fields are only generated in two places within qmail: In qmail-inject, which always uses time zone -0000, and in predate. Both of them print only the numeric time zone. So this is a pine and/or a library problem, not a qmail one. - Harald
I am setting up qmail and chose to use /bin/mail. There are two rc/boot script variations for /bin/mail in /var/qmail/boot: 1. which uses /bin/mail with -r and -d parameters 2. which uses /bin/mail with -f and -d parameters I cannot use the first option since my /bin/mail does not take a parameter "-r". I tried the second option, here is my rc script: ----> exec env - PATH="/var/qmail/bin:$PATH" \ ----> qmail-start \ ----> '|preline -f /bin/mail -f "${SENDER:-MAILER-DAEMON}" -d "$USER"' \ ----> splogger qmail Now, when I issue the command: echo to: myself | /var/qmail/bin/qmail-inject ... this is what shows up in my maillog Feb 18 18:13:49 machine qmail: 919379629.233753 status: local 1/10 remote 0/20 Feb 18 18:13:49 machine qmail: 919379629.253407 delivery 3: deferral: Cannot_give_-f_and_people_to_send_to./ It appears that my /bin/mail cannot be used with -f for sending mail (the man page states "-f Read in the contents of your mbox"). I am running linux - redhat5.1. Does anyone know how to use /bin/mail on redhat5.1?? Has anyone had similar problems?? Thanks in advance, Mark
I have a co-located server in my building route66web.com I have qmail setup on this server. I thought I copied all the files and changed everything for their service. All in-bound mail shows up fine. When they try to send any email they receive this error. 553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1) What did I miss??. Thanks in advance. Bob Ross
Bob Ross <[EMAIL PROTECTED]> writes: | I have qmail setup on this server. I thought I copied all the files and | changed everything for their service. All in-bound mail shows up fine. | When they try to send any email they receive this error. | | 553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1) | | What did I miss??. It's fascinating how often this comes up. Bob, did you read *ALL* of the qmail documentation. What does "when they try to send" mean? Does it mean, "mail injected locally, right into the queue", or does it mean "open a tcp connection to port 25 on your server"? In the latter case, how do you distinguish one of "your" users from some random stranger out on the internet? When you know that answer, and you've read the FAQ (and *ALL* the other docs), you'll know what to do.
Sorry for not jumping in earlier, I was out of town. Anyway, I'm very interested in the idea of running qmail on NT. A couple of people have pointed out that there are some places where NT comes up short as compared to (for instance) Linux, and also that some real reworking of qmail might be necessary to get it to run on NT. That said, there are some places where Linux comes up short as compared to NT. I don't want to get into a holy war over this so if you disagree with the preceeding statement mail me privately, but I can think of some good reasons to run qmail on NT, and I'm of the opinion that any architecture changes can be done with a minimum of fuss and quite possible modularized in some fashion to make it easier to keep source trees in sync. There is a lack of a good, stable, highly configurable, fast, and free MTA for NT. There's a number of things out there for NT that fit a couple of these, but nothing like qmail. NT may have its quirks, but it offers a lot of the features and services of high-end Unix systems while running on commodity hardware. I've been sort of toying with the idea of a port to NT, but I wanted to see if there was any interest or work being done on this yet. So if anyone can give me any info on any current development efforts, I'd like to know about it. Failing that, I'd love to hear from you if you're interested in helping out with my own effort. shag ===== Judd Bourgeois | CNM Network +1 (805) 520-7170 Software Architect | 1900 Los Angeles Avenue, 2nd Floor [EMAIL PROTECTED] | Simi Valley, CA 93065 To ignore evil is to become an accomplice to it. -- Martin Luther King, Jr.
On Thu, Feb 18, 1999 at 06:37:51PM -0800, Racer X wrote: > > That said, there are some places where Linux comes up short as compared to > NT. I don't want to get into a holy war over this so if you disagree with > the preceeding statement mail me privately, Of course you don't want to start a holy war. That's why you made a statement like that. > but I can think of some good > reasons to run qmail on NT, and I'm of the opinion that any architecture > changes can be done with a minimum of fuss and quite possible modularized > in some fashion to make it easier to keep source trees in sync. I for one think this is terrific. When you're done, I'm sure there will be people interested. Good luck. -- John White [EMAIL PROTECTED] PGP Public Key: http://www.triceratops.com/john/public-key.pgp
Hello, The INSTALL.vsm document says that: "sendmail uses binmail to deliver to /var/spool/mail. binmail is shipped with the operating system as /bin/mail...." This does not appear to be the case with Linux (redhat5.2). Instead procmail seems to be the local delivery agent, though linux does have a /bin/mail (which btw takes none of the parameters in the binmail examples in /var/qmail/boot). Due to the large number of redhat users, perhaps indicating this in one of the proc boot examples could be helpful. Mark
Can anyone help me? We currently use a Sparc 20 box running as a sendmail mailhost talking to the outside world on a PPP connection. What I am trying to do is to put a Linux RH5.2 box in as a firewall between the Sparc and the outside world. I can get the connection, DNS, Netscape working fine but the e-mail is eluding me. I need the qmail 1.03-3 on the Linux box to receive mail for the domain rothgard.com and relay it to the Sparc (which will be setup as a sendmail client). Mail from the Sparc will go directly to the Linux box, and from there to the outside world. I have no users setup on the Linux box. I have tried various configurations with various results (some just bouncing mail between the two servers). Has anyone done anything similar? I would appreciate ANY help. -- Regards, Glen Ward