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


Reply via email to