qmail Digest 28 Dec 1999 11:00:01 -0000 Issue 863

Topics (messages 34809 through 34843):

Server cluster
        34809 by: Michael Boman
        34810 by: petervd.vuurwerk.nl
        34811 by: Dave Sill
        34812 by: Michael Boman
        34813 by: Dave Sill
        34814 by: Michael Boman
        34815 by: lbudney-lists-qmail.nb.net
        34816 by: Michael Boman
        34820 by: John Simpson
        34826 by: Brian Grossman
        34832 by: Richard Letts
        34838 by: John Simpson
        34839 by: Russell Nelson
        34842 by: Alex Bederov

Strange mail deliver
        34817 by: Puck

Using mutt and qmail.
        34818 by: Arne Hanssen
        34819 by: Magnus Bodin
        34821 by: Bruno Wolff III
        34822 by: Aaron L. Meehan

QPopper3.0b26 with Mailbox
        34823 by: Luis Bezerra
        34824 by: Vince Vielhaber
        34836 by: David Uzzell

Re: Corel Linux ships with qmail installed, but not running
        34825 by: David L. Nicol

trouble with unusually high mbuf usage?
        34827 by: Delanet Administration

Qmail is driving me nuts!
        34828 by: Jake Reynolds
        34829 by: Martin A. Brown

Forcing the queue.
        34830 by: M. Richardson \( Technical Support - Big Net Au \)
        34833 by: Richard Letts

qmail-inject
        34831 by: Kristina
        34835 by: Mikko Hänninen
        34837 by: Kristina

error with my startup script
        34834 by: Ismal Hisham Darus

Re: qmail blackout [again]
        34840 by: Claudiu Balciza

Re: new list.cr.yp.to DNS software
        34841 by: Andy Bradford
        34843 by: Giles Lean

Administrivia:

To unsubscribe from the digest, e-mail:
        [EMAIL PROTECTED]

To subscribe to the digest, e-mail:
        [EMAIL PROTECTED]

To bug my human owner, e-mail:
        [EMAIL PROTECTED]

To post to the list, e-mail:
        [EMAIL PROTECTED]


----------------------------------------------------------------------


I am writing to you all looking for some answers for a future project.. Is
it possible to do a cluster of qmail servers using DNS and NFS?

This is what I am planning to do: 

DNS: 
====

Add serveral MX records in the DNS

Add a few mashines with different IP but the same hostname in the DNS
(So the DNS will switch between the servers).

The computers:
==============

mail00: The master server, using raid 5, have allot of diskspace,
memory etc..

mail01-xx: Slave servers. Same software configuration except that the
/home/vpopmail and /var/qmail/ is NFS mounted from mail00. Running on
a cheaper computer (no raid).

I am running:

qmail 1.03 
ezmlm 0.53 
vpopmail 3.4.10 
sqwebmail 0.26 
qmailadmin 0.25

Services provided: SMTP/POP3/IMAP(?)/WebBased mail

Can you see any problems with this setup? What should I think about?

Please advice 

/Michael Boman

-- 
W I Z O F F I C E . C O M  -  Your Online Wizard 
16 Tannery Lane, Cristal Time Building, #06-00, Singapore 347778
Ring  : (65) 844 3228 [ext 118]  Fax : (65) 842 7228
email : [EMAIL PROTECTED]    URL : http://www.wizoffice.com




On Mon, Dec 27, 1999 at 07:06:36PM +0800, Michael Boman wrote:
> I am writing to you all looking for some answers for a future project.. Is
> it possible to do a cluster of qmail servers using DNS and NFS?
> 
> This is what I am planning to do: 
> 
> DNS: 
> ====
> 
> Add serveral MX records in the DNS
> 
> Add a few mashines with different IP but the same hostname in the DNS
> (So the DNS will switch between the servers).

I'm doing the same thing with one MX record which points to a name with
multiple IPs on it. Same idea, more transparent.

> The computers:
> ==============
> 
> mail00: The master server, using raid 5, have allot of diskspace,
> memory etc..

Like our comin-up NetApp :)

> mail01-xx: Slave servers. Same software configuration except that the
> /home/vpopmail and /var/qmail/ is NFS mounted from mail00. Running on
> a cheaper computer (no raid).
> 
> I am running:
> 
> qmail 1.03 
> ezmlm 0.53 
> vpopmail 3.4.10 
> sqwebmail 0.26 
> qmailadmin 0.25
> 
> Services provided: SMTP/POP3/IMAP(?)/WebBased mail
> 
> Can you see any problems with this setup? What should I think about?

The big problem is your mail00 - if that one goes down, all is gone.

There are basically 2 ways to solve your problem: this one, or having front-end
mailservers that know which users are on which system, and something similar
to that for POP. casema.net is running this, for example.

Greetz, Peter.
-- 
Peter van Dijk - student/sysadmin/ircoper/madly in love/pretending coder 
|  
| 'C makes it easy to shoot yourself in the foot;
|  C++ makes it harder, but when you do it blows your whole leg off.'
|                             Bjarne Stroustrup, Inventor of C++




Michael Boman <[EMAIL PROTECTED]> wrote:

>mail01-xx: Slave servers. Same software configuration except that the
>/home/vpopmail and /var/qmail/ is NFS mounted from mail00. Running on
>a cheaper computer (no raid).

/var/qmail can't be shared, and shouldn't be remote.

-Dave




On Mon, Dec 27, 1999 at 07:08:01AM -0500, Dave Sill wrote:
> Michael Boman <[EMAIL PROTECTED]> wrote:
> 
> >mail01-xx: Slave servers. Same software configuration except that the
> >/home/vpopmail and /var/qmail/ is NFS mounted from mail00. Running on
> >a cheaper computer (no raid).
> 
> /var/qmail can't be shared, and shouldn't be remote.
> 
> -Dave

How can the mailservers help each other with outgoing mail then? Is
/var/qmail/queue enough to share for that, or is each server for itself?

Please advice

/Michael Boman

-- 
W I Z O F F I C E . C O M  -  Your Online Wizard 
16 Tannery Lane, Cristal Time Building, #06-00, Singapore 347778
Ring  : (65) 844 3228 [ext 118]  Fax : (65) 842 7228
email : [EMAIL PROTECTED]    URL : http://www.wizoffice.com




Michael Boman <[EMAIL PROTECTED]> wrote:

>On Mon, Dec 27, 1999 at 07:08:01AM -0500, Dave Sill wrote:
>> 
>> /var/qmail can't be shared, and shouldn't be remote.
>
>How can the mailservers help each other with outgoing mail then?

There's really no way to have multiple servers responsible for
delivering the same message. You can spread the load across multiple
servers, but each server will be solely responsible for its messages.

>Is /var/qmail/queue enough to share for that, or is each server for
>itself?

You can't share /var/qmail/queue.

-Dave




On Mon, Dec 27, 1999 at 08:33:10AM -0500, Dave Sill wrote:
> Michael Boman <[EMAIL PROTECTED]> wrote:
> 
> >On Mon, Dec 27, 1999 at 07:08:01AM -0500, Dave Sill wrote:
> >> 
> >> /var/qmail can't be shared, and shouldn't be remote.
> >
> >How can the mailservers help each other with outgoing mail then?
> 
> There's really no way to have multiple servers responsible for
> delivering the same message. You can spread the load across multiple
> servers, but each server will be solely responsible for its messages.
> 
> >Is /var/qmail/queue enough to share for that, or is each server for
> >itself?
> 
> You can't share /var/qmail/queue.
> 
> -Dave

Let me see if I get this right, it is OK to share the /home/vpopmail
directory, but not the others? Anyone have ideas how to keep the qmail
controlfiles etc up-to-date on each computer, or can I just share that
directory (/var/qmail/control and maybe /var/qmail/alias).

Please advice

/Michael

-- 
W I Z O F F I C E . C O M  -  Your Online Wizard 
16 Tannery Lane, Cristal Time Building, #06-00, Singapore 347778
Ring  : (65) 844 3228 [ext 118]  Fax : (65) 842 7228
email : [EMAIL PROTECTED]    URL : http://www.wizoffice.com





Michael Boman spake unto me and said:
> Let me see if I get this right, it is OK to share the /home/vpopmail
> directory, but not the others? Anyone have ideas how to keep the qmail
> controlfiles etc up-to-date on each computer, or can I just share that
> directory (/var/qmail/control and maybe /var/qmail/alias).


/var/qmail/queue

  /var/qmail/queue is the one thing you simply CANNOT share; qmail cannot
  queue messages through NFS. (Read INSTALL.maildir; you'll see that Dan
  takes a dim view of NFS.)


/var/qmail/control

  Sharing /var/qmail/control is possible, if you're careful. It probably
  means that home directories are NFS mounted, and passwords are NIS
  shared.  This in turn means:

  1. mbox delivery is deprecated; use Maildir.  See INSTALL.maildir,
     INSTALL.mbox and INSTALL.vsm.

  2. Mail will bounce unless you follow the steps in FAQ 4.9: "How do
     I make qmail defer messages during NFS or NIS outages?"

  An alternative to sharing is to use sed and rsync (with "-e ssh").
  The qmail Makefile contains an elegant use of sed for that purpose.


/var/qmail/bin

  You certainly can share /var/qmail/bin if you want. Make sure the
  qmail users and groups have the same IDs on every host. Also, paths
  need to agree: for example /var/qmail/queue should always get you to
  the right place.


/var/qmail/alias

  Can be shared. Remember, it's a home directory; use Maildir. Also,
  it's your problem to make sure that .qmail-* files work everywhere.


HTH,
Len.




On Mon, Dec 27, 1999 at 10:07:04AM -0500, [EMAIL PROTECTED] wrote:
> 
> Michael Boman spake unto me and said:
> > Let me see if I get this right, it is OK to share the /home/vpopmail
> > directory, but not the others? Anyone have ideas how to keep the qmail
> > controlfiles etc up-to-date on each computer, or can I just share that
> > directory (/var/qmail/control and maybe /var/qmail/alias).
> 
> 
> /var/qmail/queue
> 
>   /var/qmail/queue is the one thing you simply CANNOT share; qmail cannot
>   queue messages through NFS. (Read INSTALL.maildir; you'll see that Dan
>   takes a dim view of NFS.)
> 
> 
> /var/qmail/control
> 
>   Sharing /var/qmail/control is possible, if you're careful. It probably
>   means that home directories are NFS mounted, and passwords are NIS
>   shared.  This in turn means:
> 
>   1. mbox delivery is deprecated; use Maildir.  See INSTALL.maildir,
>      INSTALL.mbox and INSTALL.vsm.
> 
>   2. Mail will bounce unless you follow the steps in FAQ 4.9: "How do
>      I make qmail defer messages during NFS or NIS outages?"
> 
>   An alternative to sharing is to use sed and rsync (with "-e ssh").
>   The qmail Makefile contains an elegant use of sed for that purpose.
> 
> 
> /var/qmail/bin
> 
>   You certainly can share /var/qmail/bin if you want. Make sure the
>   qmail users and groups have the same IDs on every host. Also, paths
>   need to agree: for example /var/qmail/queue should always get you to
>   the right place.
> 
> 
> /var/qmail/alias
> 
>   Can be shared. Remember, it's a home directory; use Maildir. Also,
>   it's your problem to make sure that .qmail-* files work everywhere.
> 
> 
> HTH,
> Len.

The boxes will be identical clones of each other except the hostname and the 
hardware...

/Mike

-- 
W I Z O F F I C E . C O M  -  Your Online Wizard 
16 Tannery Lane, Cristal Time Building, #06-00, Singapore 347778
Ring  : (65) 844 3228 [ext 118]  Fax : (65) 842 7228
email : [EMAIL PROTECTED]    URL : http://www.wizoffice.com




On Mon, 27 Dec 1999, Michael Boman wrote:

> I am writing to you all looking for some answers for a future
> project.. Is it possible to do a cluster of qmail servers using DNS
> and NFS?

yes, although i'm not a big fan of nfs unless it's behind a STRONG
firewall. i set up something similar at the isp where i used to work, to
distribute the load among several mail servers. the system is still
running just as i set it up, although they've re-done one of the machines
(changed it from suse to redhat to match all of the others.) it does not
use nfs at all.

the trick is that we had several "mailhub" machines, with separate servers
for pop3 and virtual domains.

the publicly visible MX records all point to the mailhubs only, and the
/var/qmail/control/smtproutes file on each mailhub points each domain to
the correct machine (pop3 or virtual). this forces all incoming mail to
traverse one of these three machines, but removes that load from the pop3
server entirely.

i wrote a set of perl scripts that used ssh to automatically update the
config files on the various servers so that everything was in sync with
each other. it took a while to put together but once i finished it, it
worked really well (and is still working, even though i'm not there
anymore.)

the MX records for all domains point to "smtp1.blah.net",
"smtp2.blah.net", and "smtp3.blah.net" with non-equal weights. the trick
which distributes the load is that there are multiple A records.

the zone file for the primary domain (here called "blah.net") looks like
this:

smtp1.blah.net.    IN A     10.0.0.5
smtp1.blah.net.    IN A     10.0.0.6
smtp1.blah.net.    IN A     10.0.0.7

smtp2.blah.net.    IN A     10.0.0.6
smtp2.blah.net.    IN A     10.0.0.7
smtp2.blah.net.    IN A     10.0.0.5

smtp3.blah.net.    IN A     10.0.0.7
smtp3.blah.net.    IN A     10.0.0.5
smtp3.blah.net.    IN A     10.0.0.6

blah.net.          IN MX    1 smtp1.blah.net.
blah.net.          IN MX    2 smtp2.blah.net.
blah.net.          IN MX    3 smtp3.blah.net.

smtp.blah.net.     IN CNAME smtp1.blah.net.
pop3.blah.net.     IN A     10.0.0.9
virtual.blah.net.  IN A     10.0.0.13

client domains are configured thusly...

client.com         IN MX 1 smtp1.blah.net.
client.com         IN MX 2 smtp2.blah.net.
client.com         IN MX 3 smtp3.blah.net.

and the "smtproutes" files on the mailhubs looks like this:

blah.net:pop3.blah.net
client.com:virtual.blah.net
client2.com:virtual.blah.net
client3.com:virtual.blah.net

note again that this setup does not need nfs at all. the only need for nfs
would be if you had multiple machines doing pop3 duty, and nfs would
almost be wasted because the machine which physically housed the mailbox
directories would still be a single point of failure.

note also that all machines other than the mail servers (dns servers, web
servers, etc...) are running "mini-qmail" as detailed on one of djb's
pages, and the mailhubs are all running "qmail-qmqpd" under "tcpserver"
with the appropriate access control in order to handle outgoing mail.

the mailhubs should also be running "named", configured to only answer
queries from the localhost interface (i.e. they only serve themselves.) if
your site uses multiple name servers which update each other, the name
servers on the mailhubs should be updated with the name servers' normal
update cycle. this will save the network traffic from DNS queries and will
speed up qmail, since most DNS queries will be answered within the same
machine, and usually from named's cache.

the mailhubs are running qmail 1.03 with some anti-spam patches. they
don't need to be powerhouses, the ones i set up ranged from a pentium 166
to a pentium 350, each with 128MB RAM and 2-4GB disk each, running redhat.

the pop3 server is running qmail 1.03 with djb's "checkpassword" and the
imap server that comes as part of pine, with the bloodhound maildir
patches applied. the tcp-access list for the smtp/qmtp servers only allows
the mailhubs to send mail into the machine.

sqwebmail with system passwords could probably be installed here, but one
of the other guys there wrote a web-based mail reader in php that uses
imap on the local machine, and he's the one who now maintains the machine
so that's what is running. (i didn't find out about the inter7 programs
until after i left.)

the machine should have fast disks with enough space to store your users'
mailboxes, lots of memory, and enough CPU to drive it all. ours was a
sparc 2000e with 6 cpu's, 1GB RAM, and a 9GB scsi ultra-wide hard drive on
a dedicated differential controller for nothing but mailboxes, running
solaris because linux didn't quite work on the multi-processor sparc
machines when we got it.

the virtual domain server is running a custom-written interface that i did
long ago in perl and c, although the inter7 programs (vpopmail,
qmailadmin, sqwebmail, etc.) could be used here just as easily, and
probably would have smaller cpu and memory loads since the perl
interpreter wouldn't be used. it also only allows incoming messages
directly from the mailhubs.

this machine (when i left) was a pentium 300 with 128MB RAM and 9GB HD, i
hope they've upgraded it since then because the perl stuff, while easy to
write, was hideously slow.

to summarize...

- keep the mailhubs separate from the pop3 server

- make sure the mailhubs are doing nothing but qmail and named

- make sure the named's on the mailhubs are not answering queries from
  other machines

- don't allow any machines other than the mailhubs to connect to the smtp
  and/or qmtp ports on the pop3 and virtual machines

- run qmail-qmqpd on the mailhubs and set up all other internal servers
  (dns servers, web servers, etc.) to run "mini-qmail"

----------------------------------------------------------------
|  John Simpson         |  http://www.depeche.mode.net/~jms1/  |
|  Programmer At Large  |  <[EMAIL PROTECTED]>             |
----------------------------------------------------------------
|  It all seems so stupid, it makes me want to give up.        |
|  But why should I give up when it all seems so stupid?       |
----------------------------------------------------------------






> I am writing to you all looking for some answers for a future project.. Is
> it possible to do a cluster of qmail servers using DNS and NFS?

It's okay to put your home directories on nfs, but don't put /var/qmail/queue
on nfs.

Once you get to a high volume of incoming mail, your first bottleneck will
likely be the disk hosting /var/qmail/queue.

As John Simpson points out, do watch out for nfs as far as security goes.

Brian






Michael Boman wrote:
> 
> On Mon, Dec 27, 1999 at 08:33:10AM -0500, Dave Sill wrote:
> > Michael Boman <[EMAIL PROTECTED]> wrote:
> >
> > >On Mon, Dec 27, 1999 at 07:08:01AM -0500, Dave Sill wrote:
> > >>
> > >> /var/qmail can't be shared, and shouldn't be remote.
> > >
> > >How can the mailservers help each other with outgoing mail then?
> >
> > There's really no way to have multiple servers responsible for
> > delivering the same message. You can spread the load across multiple
> > servers, but each server will be solely responsible for its messages.
> >
> > >Is /var/qmail/queue enough to share for that, or is each server for
> > >itself?
> >
> > You can't share /var/qmail/queue.

> Let me see if I get this right, it is OK to share the /home/vpopmail
> directory, but not the others? Anyone have ideas how to keep the qmail
> controlfiles etc up-to-date on each computer, or can I just share that
> directory (/var/qmail/control and maybe /var/qmail/alias).
> 
> Please advice

Where I worked in the UK we used several machines (post.salford.ac.uk)
which
shared the same configuration; this was periodically updated using two
files, one of which contained the length of the other file to ensure
they were copied correctly between machines. (the copying being
performed using ssh -- so corruption and security was not an issue). The
machines acted purely as message switches storing no messages locally
(unless the destination machine was down) If we needed to add more
switching capacity another machine could be easily added to the cluster.
If a machine blew up or needed upgrading we could take it out of the
cluster and it would not affect the others directly.

I do not think NFS is a reliable mechanism for sharing configuration
files for reliable delivery. I like systems to be minimally dependent on
others during normal operation.

oh, the post servers could have been writing the mail into pop mailboxes
over NFS, except we were using SMTP to move it to the pop mail servers
which wrote locally. If qmtp had been built into the qmail-remote
servers we would probably have used that too.

Richard Letts, 
Austin, Texas




howdy all-

i got a private email from someone asking for more detail about setting up
clusters of qmail machines to work together. i want to respect this
person's privacy- he asked the question privately rather than through a
list. however, i think the answer should be shared with the world, so to
protect this person's identity i'm cutting out his name and such. enjoy.

On Mon, 27 Dec 1999, [someone] wrote:

> 1. When we host & DNS a domain, and we want to mail seomeone that has their
> own mailserver, we need a virtualusertable entry that says:
> @domain.com    [EMAIL PROTECTED] ( we do point dns to send mx records to
> mail.domain.com.... How would qmail deliver and e-mail sent by someone within
> ? would we need a special config as above under sendmail ?

it sounds like you're trying to force all of the domain's mail to come
through your servers. the only reasons i can think of to do this would be:

- you have a kick-ass spam filtering system on your mailhub and want to
have your client use it (in which case i want a copy, that's the one thing
i could never get "maildrop" to do for me, a text-search on every message
to be received regardless of who it's for...) (hint, hint, if the maildrop
guy is on one of these lists, i don't remember your name right now...)

- your client doesn't want the entire world to connect to his mail server,
and has an IP access list which allows only your server(s) to connect.
this could be because they don't want to be an open relay but their
brain-dead mail server program can't be configured that way. (you also
need to set up a packet filter in your routers or terminal servers to make
this work for relay prevention...)

- you are providing ETRN service for a non-dedicated client

anyway, to set this up (so their mail is forced into your servers and your
server then hands it to them) ...

DNS contains records like this, as needed...
  client.com  IN MX 1 mailhub1.isp.com.
  client.com  IN MX 2 mailhub2.isp.com.

/var/qmail/control/rcpthosts (or morercpthosts.cdb) contains
  client.com

/var/qmail/control/smtproutes contains (note that their mail server must
have a static ip in order for mail to be delivered to them)
  client.com:12.34.56.78

if, on the other had, you want to offer the services of your mailhubs as
just a backup when the client's connection goes down, you set it up like
this (and the client would allow incoming connections from anywhere in the
world)

DNS contains:
  client.com  IN MX 1 mail.client.com.
  client.com  IN MX 2 mailhub1.isp.com.
  client.com  IN MX 3 mailhub2.isp.com.

/var/qmail/control/rcpthosts (or morercpthosts.cdb) contains
  client.com

note that setting the MX records this way and having the client set up an
IP restriction list will still accomplish the goal of sending all of their
mail through your servers, but time would be wasted on every message while
the sending server tries first to contact your client's mail server
directly and times out before sending it to your (the ISP's) mail server.
it works but it's less than optimal (and to some that's just as bad as not
working at all.)

> 2. We also want to provide redundant mail service for our clients mail
> servers, and so we want to use etrn to accomplish this, but it seems like
> nobody is doing this under qmail...any ideas ?

long ago i found a patch for ETRN on the qmail.org
mega-page-of-doom(tm)... it works, although i added a few syslog() lines
to it myself so i could tell when it was working and not working. i also
added a line that checks to see if the first character of the domain name
being asked for is "@", and if so it skips the "@" before checking the
control/etrn file. this is because some versions of microsoft exchange
server add an "@" sign to the domain name- not standard ETRN but that's
microsoft for you...

however, i just went and looked at qmail.org again, and it's not there
anymore. (does anyone know why? was there a security hole that i didn't
hear about, do i need to call my old office and tell them about it?)

anyway, i don't have the patch anymore, but there are programs called
"turnmail" and "pullmail" (for unix and NT, respectively) that can be used
to simulate the results of ETRN functionality. i have no experience with
either of them.

i don't have the source file anymore (i don't work for the isp anymore)
but the changes were trivial.

> Also in your redundant solution for mailservers, I agree with the nfs issues
> you bring up, but how often were you ssh coping the files back & forth ? were
> you using rsyc with ssh protocol or is there an update parameter on scp ?

just to clarify, it's only the qmail control files that get copied, no
messages.

the copies were being done several times a day, basically every time a new
domain was added to the virtual mail server. we were using regular old
"scp" without worrying about any "update" parameters- if the master had
new config files, it was guaranteed that the slave needed them so we went
right ahead and overwrote what was on the slave machine. (and we weren't
overwriting the live qmail control directory, so there were no issues
there.)

we ran "scp" and "ssh" using the "-i" parameter and an ssh key pair which
was only used for updating qmail config files. details on how to set up
such a beast follow...

before starting this, you should be familiar with ssh and friends, as well
as file permissions, shell scripts, setuid wrappers, and most importantly
your own servers.

- on the master server, create a key pair using "ssh-keygen -f blah". DO
NOT ENTER A PASSPHRASE FOR THIS KEY PAIR. it will create two files. the
file "blah" is the SECRET half of the key, and "blah.pub" is the PUBLIC
half of the key. "mv" the secret half to somewhere safe, and set the
ownership and permissions so that it's safe (i.e. owned by root, chmod
0400, in a root-owned directory that's chmod 0700, etc.) I CANNOT STRESS
STRONGLY ENOUGH THE NEED FOR SECURITY OF THIS SECRET-KEY FILE! if someone
gets a copy of it, knows what it is and how to use it, they could totally
screw up the qmail control files on your slave machines. you may want to
rotate the key files once a week or once a month, and you definitely don't
want to use this key pair for anything else.

- on each slave server, create a new group-id (in /etc/group) called
"update" or something similar.

- on each slave server, create an account (userid "update" or something
like that) on each "slave" server. the user's group id in /etc/passwd
should be the same as the numeric id of the group you just created. the
password doesn't matter, you're about to throw it out anyway.

you then need to invalidate the password: in /etc/passwd or /etc/shadow,
manually replace the encrypted password with "ZZ@@@@@@@@@@@" or something
similar- it needs to contain at least one character other than letters,
digits, period, and forward slash, but not "*" or "!" since those are
magic characters for some authentication libraries.

- copy the public half of the key pair to the file ".ssh/authorized_keys"
in the user's home directory. make this file owned by the user and chmod
0400.

- write a shell script in the user's home directory to copy any qmail
config files you will be updating from the user's home directory to
/var/qmail/control. it would look something like this...

  #!/bin/sh

  PATH="/bin:/usr/bin:/usr/local/bin:/var/qmail/bin"

  cd /home/update
  cp morercpthosts virtualdomains smtproutes etrn /var/qmail/control/

  chmod 755 /var/qmail/control
  chmod 644 /var/qmail/control/*

  qmail-newmrh

  /etc/rc.d/init.d/qmail restart

the shell script itself should be owned by root and chmod 0700. the script
should either explicitly set its own path or manually specify full
pathnames for all programs (i.e. "/bin/cp" etc.) you should test the
script by running it as root.

- write a specific setuid-root wrapper (feel free to use the attached
"wrapper.c" as a guide, it compiles very small because it doesn't use any
libc functions, just syscalls) which will only run the shell script you
have just written. compile the program, give it a name (like "update"),
make the executable owned by root, set the group id to the group you
created above, and set the permissions to "chmod 4710". this will make it
setuid-root, with only members of the update group (i.e. only the update
user) able to actually run it.

- on the master machine, generate the new files as they should appear on
the slave server(s). copy the file(s) over with something like this:

  scp -i /root/.ssh/update.identity configfile [EMAIL PROTECTED]:

note that you can have multiple filenames on the command line, as long
as the last thing is the "userid@machine:" with the colon.

then, you need to tell the slave to actually update the "live" config
files, like so:

  ssh -i /root/.ssh/update.identity -l update slaveserver.isp.com ./update

> My suggestion was to use an ethernet based hard drive, which is remotely
> mounted not sure wich technology they use, but that way an actual system would
> not be responsible for the shared drive...

hrmmm... like a netapp. we tried one and ran into a few problems...

- they're hideously expensive, starting about $40K for a basic 18GB unit

- they depend on your ethernet. unless you're planning on installing a
100-Base-T private ethernet segment (with a second ethernet card in each
machine and a 100-Base-T switch, not hub) you're going to do a better job
of flooding your own network than any twisted hacker punk could do. these
suckers will use a LOT of bandwidth, because if you buy one and you're
smaller than someone like earthlink, you're going to want to use it for
more than just email. been there, done that, spent almost $6000 of the
company's money upgrading switches.

- did i mention they're horrendously expensive?

> Happy Y2K!

ugh... i'll be SO happy next week when this is all over...

take care all.

----------------------------------------------------------------
|  John Simpson         |  http://www.depeche.mode.net/~jms1/  |
|  Programmer At Large  |  <[EMAIL PROTECTED]>             |
----------------------------------------------------------------
|  It all seems so stupid, it makes me want to give up.        |
|  But why should I give up when it all seems so stupid?       |
----------------------------------------------------------------
/*      wrapper.c
        [EMAIL PROTECTED] 1997-11-20

        general-purpose setuid wrapper

        header files etc. written for unix, compiles ok on solaris 2.6

        set program base name in #define PROG

        set parameters (if any) in ma[]
          (make sure to adjust the size of ma[] to hold your parameters)
*/

#include <sys/types.h>
#include <unistd.h>

#define PROG "/usr/sbin/ndc"

int main ( int argc , char *argv[] )
{
        char *ma[3] ;

        if ( setuid ( 0 ) )
        {
                perror ( "setuid" ) ;
                return 1 ;
        }

        if ( seteuid ( 0 ) )
        {
                perror ( "seteuid" ) ;
                return 1 ;
        }

        ma[0] = PROG ;
        ma[1] = "restart" ;
        ma[2] = 0 ;

        execv ( PROG , ma ) ;

        perror ( "execv" ) ;
        return 1 ;
}




John Simpson writes:
 > > 2. We also want to provide redundant mail service for our clients mail
 > > servers, and so we want to use etrn to accomplish this, but it seems like
 > > nobody is doing this under qmail...any ideas ?
 > 
 > long ago i found a patch for ETRN on the qmail.org
 > mega-page-of-doom(tm)... it works, although i added a few syslog() lines
 > to it myself so i could tell when it was working and not working. i also
 > added a line that checks to see if the first character of the domain name
 > being asked for is "@", and if so it skips the "@" before checking the
 > control/etrn file. this is because some versions of microsoft exchange
 > server add an "@" sign to the domain name- not standard ETRN but that's
 > microsoft for you...
 > 
 > however, i just went and looked at qmail.org again, and it's not there
 > anymore. (does anyone know why? was there a security hole that i didn't
 > hear about, do i need to call my old office and tell them about it?)

It serves no purpose, given serialmail's autoturn facility.

-- 
-russ nelson <[EMAIL PROTECTED]>  http://russnelson.com
Crynwr sells support for free software  | PGPok | "Ask not what your country
521 Pleasant Valley Rd. | +1 315 268 1925 voice | can force other people to
Potsdam, NY 13676-3213  | +1 315 268 9201 FAX   | do for you..."  -Perry M.





> <...> in which case i want a copy, that's the one thing
>i could never get "maildrop" to do for me, a text-search on every message
>to be received regardless of who it's for...) (hint, hint, if the maildrop
>guy is on one of these lists, i don't remember your name right now...)




John:

I use Sam's qmail patches along with maildrop and so far I love it.
I'd say it bounces back 98% of junk mail.  This link used to be on
qmail.org page, however it is not there any more.

http://www.geocities.com/SiliconValley/Peaks/5799/qmail-uce.html

Besides, I am sure that Sam Varshavchik, the maildrop author, is reading
the sqwebmail list. He returns email if you care to ask him a question. 

Regards,
AlexB



At 12:57 AM 12/28/99 -0500, John Simpson wrote:
>howdy all-
>
>i got a private email from someone asking for more detail about setting up
>clusters of qmail machines to work together. i want to respect this
>person's privacy- he asked the question privately rather than through a
>list. however, i think the answer should be shared with the world, so to
>protect this person's identity i'm cutting out his name and such. enjoy.
>
>On Mon, 27 Dec 1999, [someone] wrote:
>
>> 1. When we host & DNS a domain, and we want to mail seomeone that has their
>> own mailserver, we need a virtualusertable entry that says:
>> @domain.com    [EMAIL PROTECTED] ( we do point dns to send mx records to
>> mail.domain.com.... How would qmail deliver and e-mail sent by someone
within
>> ? would we need a special config as above under sendmail ?
>
>it sounds like you're trying to force all of the domain's mail to come
>through your servers. the only reasons i can think of to do this would be:
>
>- you have a kick-ass spam filtering system on your mailhub and want to
>have your client use it (in which case i want a copy, that's the one thing
>i could never get "maildrop" to do for me, a text-search on every message
>to be received regardless of who it's for...) (hint, hint, if the maildrop
>guy is on one of these lists, i don't remember your name right now...)
>
>- your client doesn't want the entire world to connect to his mail server,
>and has an IP access list which allows only your server(s) to connect.
>this could be because they don't want to be an open relay but their
>brain-dead mail server program can't be configured that way. (you also
>need to set up a packet filter in your routers or terminal servers to make
>this work for relay prevention...)
>
>- you are providing ETRN service for a non-dedicated client
>
>anyway, to set this up (so their mail is forced into your servers and your
>server then hands it to them) ...
>
>DNS contains records like this, as needed...
>  client.com  IN MX 1 mailhub1.isp.com.
>  client.com  IN MX 2 mailhub2.isp.com.
>
>/var/qmail/control/rcpthosts (or morercpthosts.cdb) contains
>  client.com
>
>/var/qmail/control/smtproutes contains (note that their mail server must
>have a static ip in order for mail to be delivered to them)
>  client.com:12.34.56.78
>
>if, on the other had, you want to offer the services of your mailhubs as
>just a backup when the client's connection goes down, you set it up like
>this (and the client would allow incoming connections from anywhere in the
>world)
>
>DNS contains:
>  client.com  IN MX 1 mail.client.com.
>  client.com  IN MX 2 mailhub1.isp.com.
>  client.com  IN MX 3 mailhub2.isp.com.
>
>/var/qmail/control/rcpthosts (or morercpthosts.cdb) contains
>  client.com
>
>note that setting the MX records this way and having the client set up an
>IP restriction list will still accomplish the goal of sending all of their
>mail through your servers, but time would be wasted on every message while
>the sending server tries first to contact your client's mail server
>directly and times out before sending it to your (the ISP's) mail server.
>it works but it's less than optimal (and to some that's just as bad as not
>working at all.)
>
>> 2. We also want to provide redundant mail service for our clients mail
>> servers, and so we want to use etrn to accomplish this, but it seems like
>> nobody is doing this under qmail...any ideas ?
>
>long ago i found a patch for ETRN on the qmail.org
>mega-page-of-doom(tm)... it works, although i added a few syslog() lines
>to it myself so i could tell when it was working and not working. i also
>added a line that checks to see if the first character of the domain name
>being asked for is "@", and if so it skips the "@" before checking the
>control/etrn file. this is because some versions of microsoft exchange
>server add an "@" sign to the domain name- not standard ETRN but that's
>microsoft for you...
>
>however, i just went and looked at qmail.org again, and it's not there
>anymore. (does anyone know why? was there a security hole that i didn't
>hear about, do i need to call my old office and tell them about it?)
>
>anyway, i don't have the patch anymore, but there are programs called
>"turnmail" and "pullmail" (for unix and NT, respectively) that can be used
>to simulate the results of ETRN functionality. i have no experience with
>either of them.
>
>i don't have the source file anymore (i don't work for the isp anymore)
>but the changes were trivial.
>
>> Also in your redundant solution for mailservers, I agree with the nfs
issues
>> you bring up, but how often were you ssh coping the files back & forth ?
were
>> you using rsyc with ssh protocol or is there an update parameter on scp ?
>
>just to clarify, it's only the qmail control files that get copied, no
>messages.
>
>the copies were being done several times a day, basically every time a new
>domain was added to the virtual mail server. we were using regular old
>"scp" without worrying about any "update" parameters- if the master had
>new config files, it was guaranteed that the slave needed them so we went
>right ahead and overwrote what was on the slave machine. (and we weren't
>overwriting the live qmail control directory, so there were no issues
>there.)
>
>we ran "scp" and "ssh" using the "-i" parameter and an ssh key pair which
>was only used for updating qmail config files. details on how to set up
>such a beast follow...
>
>before starting this, you should be familiar with ssh and friends, as well
>as file permissions, shell scripts, setuid wrappers, and most importantly
>your own servers.
>
>- on the master server, create a key pair using "ssh-keygen -f blah". DO
>NOT ENTER A PASSPHRASE FOR THIS KEY PAIR. it will create two files. the
>file "blah" is the SECRET half of the key, and "blah.pub" is the PUBLIC
>half of the key. "mv" the secret half to somewhere safe, and set the
>ownership and permissions so that it's safe (i.e. owned by root, chmod
>0400, in a root-owned directory that's chmod 0700, etc.) I CANNOT STRESS
>STRONGLY ENOUGH THE NEED FOR SECURITY OF THIS SECRET-KEY FILE! if someone
>gets a copy of it, knows what it is and how to use it, they could totally
>screw up the qmail control files on your slave machines. you may want to
>rotate the key files once a week or once a month, and you definitely don't
>want to use this key pair for anything else.
>
>- on each slave server, create a new group-id (in /etc/group) called
>"update" or something similar.
>
>- on each slave server, create an account (userid "update" or something
>like that) on each "slave" server. the user's group id in /etc/passwd
>should be the same as the numeric id of the group you just created. the
>password doesn't matter, you're about to throw it out anyway.
>
>you then need to invalidate the password: in /etc/passwd or /etc/shadow,
>manually replace the encrypted password with "ZZ@@@@@@@@@@@" or something
>similar- it needs to contain at least one character other than letters,
>digits, period, and forward slash, but not "*" or "!" since those are
>magic characters for some authentication libraries.
>
>- copy the public half of the key pair to the file ".ssh/authorized_keys"
>in the user's home directory. make this file owned by the user and chmod
>0400.
>
>- write a shell script in the user's home directory to copy any qmail
>config files you will be updating from the user's home directory to
>/var/qmail/control. it would look something like this...
>
>  #!/bin/sh
>
>  PATH="/bin:/usr/bin:/usr/local/bin:/var/qmail/bin"
>
>  cd /home/update
>  cp morercpthosts virtualdomains smtproutes etrn /var/qmail/control/
>
>  chmod 755 /var/qmail/control
>  chmod 644 /var/qmail/control/*
>
>  qmail-newmrh
>
>  /etc/rc.d/init.d/qmail restart
>
>the shell script itself should be owned by root and chmod 0700. the script
>should either explicitly set its own path or manually specify full
>pathnames for all programs (i.e. "/bin/cp" etc.) you should test the
>script by running it as root.
>
>- write a specific setuid-root wrapper (feel free to use the attached
>"wrapper.c" as a guide, it compiles very small because it doesn't use any
>libc functions, just syscalls) which will only run the shell script you
>have just written. compile the program, give it a name (like "update"),
>make the executable owned by root, set the group id to the group you
>created above, and set the permissions to "chmod 4710". this will make it
>setuid-root, with only members of the update group (i.e. only the update
>user) able to actually run it.
>
>- on the master machine, generate the new files as they should appear on
>the slave server(s). copy the file(s) over with something like this:
>
>  scp -i /root/.ssh/update.identity configfile [EMAIL PROTECTED]:
>
>note that you can have multiple filenames on the command line, as long
>as the last thing is the "userid@machine:" with the colon.
>
>then, you need to tell the slave to actually update the "live" config
>files, like so:
>
>  ssh -i /root/.ssh/update.identity -l update slaveserver.isp.com ./update
>
>> My suggestion was to use an ethernet based hard drive, which is remotely
>> mounted not sure wich technology they use, but that way an actual system
would
>> not be responsible for the shared drive...
>
>hrmmm... like a netapp. we tried one and ran into a few problems...
>
>- they're hideously expensive, starting about $40K for a basic 18GB unit
>
>- they depend on your ethernet. unless you're planning on installing a
>100-Base-T private ethernet segment (with a second ethernet card in each
>machine and a 100-Base-T switch, not hub) you're going to do a better job
>of flooding your own network than any twisted hacker punk could do. these
>suckers will use a LOT of bandwidth, because if you buy one and you're
>smaller than someone like earthlink, you're going to want to use it for
>more than just email. been there, done that, spent almost $6000 of the
>company's money upgrading switches.
>
>- did i mention they're horrendously expensive?
>
>> Happy Y2K!
>
>ugh... i'll be SO happy next week when this is all over...
>
>take care all.
>
>----------------------------------------------------------------
>|  John Simpson         |  http://www.depeche.mode.net/~jms1/  |
>|  Programmer At Large  |  <[EMAIL PROTECTED]>             |
>----------------------------------------------------------------
>|  It all seems so stupid, it makes me want to give up.        |
>|  But why should I give up when it all seems so stupid?       |
>----------------------------------------------------------------
>
>Attachment Converted: "d:\eudora\attach\wrapper.c"
>





Hi there,

my system is called "mohawk.n-online.net"

Sometime is recieve (postmaster) mails with the following header :

---------------------------------------------------------------------------

Return-Path: <[EMAIL PROTECTED]>
Delivered-To: [EMAIL PROTECTED]
Received: (qmail 26510 invoked by alias); 27 Dec 1999 14:04:46 -0000
Delivered-To: [EMAIL PROTECTED]
Received: (qmail 26506 invoked from network); 27 Dec 1999 14:04:45 -0000
Received: from unknown (HELO pc1) (195.30.220.10)
  by mohawk.n-online.net with SMTP; 27 Dec 1999 14:04:45 -0000
Message-ID: <001d01bf5073$1e6a3040$2109a8c0@pc1>
From: "mohr" <[EMAIL PROTECTED]>
To: =?iso-8859-1?Q?Sch=F6pe=2C_Alex?= <[EMAIL PROTECTED]>
Subject: Stromabschaltung
Date: Mon, 27 Dec 1999 15:02:51 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
        boundary="----=_NextPart_000_001A_01BF507B.72239FC0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300

---------------------------------------------------------------------------

As you can see, there is a delivered-to "[EMAIL PROTECTED]" 
So i told our customer to check the recipient of the email.
An hour later i receieved the same message again, resend by our customer.
So what could this be the "[EMAIL PROTECTED]", because our customers don't 
know
the realname of our mailserver. Seems that qmail mixes up some adresses ?!?!

Thanks for your Help,
  Thomas







I'm no Linux expert and have some questions regarding mail handling.
My system is PentiumII, RedHat 6.1, kernel 2.2.13 and qmail 1.03
without tcpserver and such recommended stuff (it works without so far).
I'm using KDE 1.1.2 (I think) and qmail was installed before upgrading
RH from 5.2 to 6.x (first 6.0, then 6.1).  After which qmail claims
to be dead, but runs all the same - seems quite ok!  ;-/

1) Some days ago on this list, some guys were discussing whether
   Return-Path is set by the MUA or the MTA.  This is an issue for
me as I have (had?) problems with this, using mutt.  Even if I try
to include a "my_hdr" it will not work; my mail is refused by my
ISP because "sender domain must exist", and of course Return-Path
<[EMAIL PROTECTED]> (my local machine) does not exist.  I want
Return-Path to be <[EMAIL PROTECTED]>.
Reading docs I discover that qmail-inject strips away any occurence
of Return-Path (the person arguing that this header value was solely
a matter of the MUA must be wrong, or I'm missing something?).
I have now made a change in .muttrc (set sendmail="..qmail-inject
[EMAIL PROTECTED]") and it might be working now.  Hopefully there is
no drawbacks(?)
Anyone who wants to comment on this (and perhaps explaing "things"
to me)?  ;-)  Perhaps there are better ways to set the correct
Return-Path.

2) Perhaps this is a mutt question, but is it possible to prevent
   my outoing mail to be sent immediately (my router making a call
for every single mail)?  With KMail this was no problem as KMail did
not send until requested.  If this isn't easily solved from mutt,
is there a way to configure qmail to not send remote mail until
requested or something like that?  Seems to me that that would be
the preferred way.

Thank you!  ;-)
-- 
Vennlig hilsen / Best regards     |\     ___,,--,        _
Arne Hanssen, Senja, Norway       /,`--''        \-,,__,'/
http://home.telia.no/ahh/        |,4   ) )_    ) /~-----'
--------------------------------'---^~(_/-_)--(_/_)-------




On Mon, Dec 27, 1999 at 05:57:30PM +0100, Arne Hanssen wrote:
> I'm no Linux expert and have some questions regarding mail handling.
> My system is PentiumII, RedHat 6.1, kernel 2.2.13 and qmail 1.03
> without tcpserver and such recommended stuff (it works without so far).
> I'm using KDE 1.1.2 (I think) and qmail was installed before upgrading
> RH from 5.2 to 6.x (first 6.0, then 6.1).  After which qmail claims
> to be dead, but runs all the same - seems quite ok!  ;-/
> 
> 1) Some days ago on this list, some guys were discussing whether
>    Return-Path is set by the MUA or the MTA.  This is an issue for
> me as I have (had?) problems with this, using mutt.  Even if I try
> to include a "my_hdr" it will not work; my mail is refused by my
> ISP because "sender domain must exist", and of course Return-Path
> <[EMAIL PROTECTED]> (my local machine) does not exist.  I want
> Return-Path to be <[EMAIL PROTECTED]>.
> Reading docs I discover that qmail-inject strips away any occurence
> of Return-Path (the person arguing that this header value was solely
> a matter of the MUA must be wrong, or I'm missing something?).
> I have now made a change in .muttrc (set sendmail="..qmail-inject
> [EMAIL PROTECTED]") and it might be working now.  Hopefully there is
> no drawbacks(?)
> Anyone who wants to comment on this (and perhaps explaing "things"
> to me)?  ;-)  Perhaps there are better ways to set the correct
> Return-Path.

In your .muttrc:

set hostname = go.telia.no
 


gott nytt år!

/magnus

-- 
http://x42.com/

  \ /  ASCII Ribbon Campaign - Say NO to HTML in email and news       
   x




On Mon, Dec 27, 1999 at 05:57:30PM +0100,
  Arne Hanssen <[EMAIL PROTECTED]> wrote:
> 1) Some days ago on this list, some guys were discussing whether
>    Return-Path is set by the MUA or the MTA.  This is an issue for
> me as I have (had?) problems with this, using mutt.  Even if I try
> to include a "my_hdr" it will not work; my mail is refused by my
> ISP because "sender domain must exist", and of course Return-Path
> <[EMAIL PROTECTED]> (my local machine) does not exist.  I want
> Return-Path to be <[EMAIL PROTECTED]>.

Return-Path is set by the MTA at final delivery (which may include
programs).

> Reading docs I discover that qmail-inject strips away any occurence
> of Return-Path (the person arguing that this header value was solely
> a matter of the MUA must be wrong, or I'm missing something?).

qmail-inject allows you to use this header to set the envelope sender
address. It is possible to set this a couple of different ways.

> I have now made a change in .muttrc (set sendmail="..qmail-inject
> [EMAIL PROTECTED]") and it might be working now.  Hopefully there is
> no drawbacks(?)
> Anyone who wants to comment on this (and perhaps explaing "things"
> to me)?  ;-)  Perhaps there are better ways to set the correct
> Return-Path.

You might want to use the environment variable QMAILHOST to set this for you.




Quoting Magnus Bodin ([EMAIL PROTECTED]):
> On Mon, Dec 27, 1999 at 05:57:30PM +0100, Arne Hanssen wrote:
> > Anyone who wants to comment on this (and perhaps explaing "things"
> > to me)?  ;-)  Perhaps there are better ways to set the correct
> > Return-Path.
> 
> In your .muttrc:
> 
> set hostname = go.telia.no

Hmmm that didn't really work for me.  I've had to take care of this
by setting QMAILSHOST in my environment.

Aaron




Has anyone could help me to configure qpopper3.0b26 using Mailbox

thanks in advance

--
-----------------------------
Luís Bezerra de A. Junior
[EMAIL PROTECTED]
SecrelNet Informática LTDA
Fortaleza - Ceará - Brasil
Fone: 021852882090
-----------------------------






 > Has anyone could help me to configure qpopper3.0b26 using Mailbox
 > 
 > thanks in advance
 
Edit popper.h and uncomment the #define for qmail.  Then build as normal.
Qmail support for mbox style mailboxes is now built in to qpopper ver3.
 
Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH    email: [EMAIL PROTECTED]    http://www.pop4.net
   128K ISDN: $24.95/mo or less - 56K Dialup: $17.95/mo or less at Pop4
        Online Campground Directory    http://www.camping-usa.com
       Online Giftshop Superstore    http://www.cloudninegifts.com
==========================================================================








The only way I have been told to do this is to link all the ~/Mailbox to
/var/mail/(user) or where your sendmail was storing your mail before you
changed your Mailer. Hope this helps.

On Mon, 27 Dec 1999, Luis Bezerra wrote:

> Has anyone could help me to configure qpopper3.0b26 using Mailbox
> 
> thanks in advance
> 
> --
> -----------------------------
> Luís Bezerra de A. Junior
> [EMAIL PROTECTED]
> SecrelNet Informática LTDA
> Fortaleza - Ceará - Brasil
> Fone: 021852882090
> -----------------------------
> 
> 
> 





"Chris L. Mason" wrote:
>
> Perhaps Corel is planning to use qmail in future versions and it just wasn't
> ready for 1.0?  I've been waiting awhile for a Linux distribution to come
> out that uses qmail as the default MTA (or at least offers the choice of
> using it over sendmail in the installation.)
> 
> Chris 


I think linux distributors are waiting for qmail to be able to combine
non-VERP messages for same remote machine into single transmissions;
or perhaps for a configuration GUI. (it would thave to be standard
and extensible, so qmail extensions could extend the GUI as well)




Where's your distribution, then, Chris?

Does not the existence of easily available qmail RPMs qualify?



__________________________________________________
          David Nicol 816.235.1187 [EMAIL PROTECTED]
                           grep -v 0 /proc/*/where




I have a FreeBSD 3.1r server running qmail 1.03 with ezmlm and vchkpw
3.12. It's been running fine for 9 months or so now until last week. The
server crashed (hardware related and fixed) and there was rather
extensive FS corruption..after cleaning it and re-starting qmail, the
mbufs which normally never spike over 300 or so topped 7k, crashed the
server simply trying to start qmail. I raised max-users and thats fixed
it, however for a server to suddently need over twice the mbufs with no
real changes aside from addition of users (not enough to account for
that much change) bothers me. I can find nothing wrong with it..I did
have some 330+ messages in the queue, however I've restarted it with
more before..even a kill -ALRM would cause a crash before I increased
the limit, which never was a problem in the past. Has anyone else
experienced this or have any ideas on where I can look to track it down?

Thanks in advance,

--
Stephen Comoletti
Systems Administrator
Delanet, Inc.  http://www.delanet.com
ph: (302) 326-5800 fax: (302) 326-5802







I've installed per the instructions, and it runs fine... I'm having a
problem though.  I want to set up qmail to forward all our email from
ourdomain.com to mailserver.ourdomain.com

Basicly I want it to act as a cacheing mail forwarder, should our mail
system go down.  I'm trying to avoid bounce messages from being sent over
the internet should the mail server crash.  I assumed I could set up a
virtual domain and then change the MX record, but I can't seem to get the
system to forward the mail properly at this moment, and am therefore
reluctant to change the MX record...

Jake Reynolds
Systems Technician

v ) s t r e a m
1157 Century Drive
Louisville, CO 80027
phone 800.878.7326 ext. 2446
Direct Dial 303.928.2446
fax 303.928.2832
www.vstream.com






Actually, Jake,

The best thing to do in this case is to have all of the mail MX to
this qmail on this machine, and then "smtp" route it to your real
mailserver.

So, include the [sub-]domain in rcpthosts, but don't include (anything?)
the domain name in locals or virtualhosts.

Then add a line in smtproutes that points to your "real" mailserver.

Here's what I would do....

/var/qmail/control/rcpthosts
=================================
everydomain.com
that-you.net
wish-to-receive-mail.for

/var/qmail/control/smtproutes
=================================
everydomain.com:real.mailserver.net
that-you.net:real.mailserver.net
wish-to-receive-mail.for:real.mailserver.net

Now, should your 'real.mailserver.net' go down, qmail will spool the mail
for upto /var/qmail/control/queuelifetime (default = 604800 seconds = 7
days).

You will doubtless want to know about the command 'qmail-qread', and if
you wish any mail to deliver locally, you should read up on the "Life with
Qmail" page...it has a number of gems and solid advice.

http://Web.InfoAve.Net/~dsill/lwq.html

-Martin

-- 
Martin A. Brown --- Wonderfrog Enterprises --- [EMAIL PROTECTED]

On Mon, 27 Dec 1999, Jake Reynolds wrote:

:I've installed per the instructions, and it runs fine... I'm having a
:problem though.  I want to set up qmail to forward all our email from
:ourdomain.com to mailserver.ourdomain.com
:
:Basicly I want it to act as a cacheing mail forwarder, should our mail
:system go down.  I'm trying to avoid bounce messages from being sent over
:the internet should the mail server crash.  I assumed I could set up a
:virtual domain and then change the MX record, but I can't seem to get the
:system to forward the mail properly at this moment, and am therefore
:reluctant to change the MX record...
:
:Jake Reynolds
:Systems Technician
:
:v ) s t r e a m
:1157 Century Drive
:Louisville, CO 80027
:phone 800.878.7326 ext. 2446
:Direct Dial 303.928.2446
:fax 303.928.2832
:www.vstream.com
:
:
:





Hi,
 
    I've looked for this in the FAQ and HOW-TO but to no avail, and I'm hoping somebody here can help me out.
 
    What I'm trying to do is combine 7 existing mail servers into one large (massive) mail server... currently the largest server we have (1400 users) is running a queue at an average of 20mb.... before I merge these seven servers I'm wondering is there a way to have qmail send messages straight from the queue, without waiting. (Much like sending qmail an ALRM signal) ?
 
    Thanks for your time.
 
Michael.
 
 






> "M. Richardson ( Technical Support - Big Net Au )" wrote:
> 
> Hi,
> 
>     I've looked for this in the FAQ and HOW-TO but to no avail, and
> I'm hoping somebody here can help me out.
> 
>     What I'm trying to do is combine 7 existing mail servers into one
> large (massive) mail server... currently the largest server we have
> (1400 users) is running a queue at an average of 20mb.... before I
> merge these seven servers I'm wondering is there a way to have qmail
> send messages straight from the queue, without waiting. (Much like
> sending qmail an ALRM signal) ?
> 

setup qmail on your new server, test it, then put
':big-mail-server.big.net.au' into /var/qmail/control/smtproutes on each
of the little mail servers. Send the qmail-send process a 'ALRM' signal
on each of the little servers.
They should then attempt to deliver all of their outbound SMTP mail to
your big server (thus emptying its queue). You'll then have tested your
big server's ability to cope with large queues and sudden influxes of
mail as well as moved the mail off the smaller machines.

Hope this helps.

Richard Letts





My qmail is starting okay, however when I try to do a mail test:
echo to: kristina | /var/qmail/bin/qmail-inject

The following error is returned:
stty: : No such device or address

Does anyone know what could be causing this?

Thanks in advance,
Kristina





Kristina <[EMAIL PROTECTED]> wrote on Tue, 28 Dec 1999:
> My qmail is starting okay, however when I try to do a mail test:
> echo to: kristina | /var/qmail/bin/qmail-inject
> 
> The following error is returned:
> stty: : No such device or address
> 
> Does anyone know what could be causing this?

I'm not sure, but I'm guessing you have a stty command in either your
personal .profile for that user, or in the /etc/profile file.  The shell
gets invoked for the pipe, including executing the startup file(s), but
there's no attached tty, and so stty complains.

If you're using something else than bash (or relative), adjust the above
by substituting your shell's startup files...


In any case, it's very likely not a qmail problem, qmail doesn't execute
stty.


HTH,
Mikko
-- 
// Mikko Hänninen, aka. Wizzu  //  [EMAIL PROTECTED]  //  http://www.iki.fi/wiz/
// The Corrs list maintainer  //   net.freak  //   DALnet IRC operator /
// Interests: roleplaying, Linux, the Net, fantasy & scifi, the Corrs /
I havent't lost my mind -- I'm sure it is backed up somewhere.




Thanks! I  have the solved the problem by switching to shell instead of cshe
ll.

My new problem is that I get absolutely no response from the system when I
execute the same command:
echo to: kristina | /var/qmail/bin/qmail-inject

Even /var/log/syslog produces nothing!

Why is this command not executing?

Thanks in advance,
Kristina


At 05:37 99/12/28 +0200, you wrote:
> Kristina <[EMAIL PROTECTED]> wrote on Tue, 28 Dec 1999:
> > My qmail is starting okay, however when I try to do a mail test:
> > echo to: kristina | /var/qmail/bin/qmail-inject
> > 
> > The following error is returned:
> > stty: : No such device or address
> > 
> > Does anyone know what could be causing this?
> 
> I'm not sure, but I'm guessing you have a stty command in either your
> personal .profile for that user, or in the /etc/profile file.  The shell
> gets invoked for the pipe, including executing the startup file(s), but
> there's no attached tty, and so stty complains.
> 
> If you're using something else than bash (or relative), adjust the above
> by substituting your shell's startup files...
> 
> 
> In any case, it's very likely not a qmail problem, qmail doesn't execute
> stty.
> 
> 
> HTH,
> Mikko
> -- 
> // Mikko H$BgO(Bninen, aka. Wizzu  //  [EMAIL PROTECTED]  //  http://www.iki.fi/wiz/
> // The Corrs list maintainer  //   net.freak  //   DALnet IRC operator /
> // Interests: roleplaying, Linux, the Net, fantasy & scifi, the Corrs /
> I havent't lost my mind -- I'm sure it is backed up somewhere.
>   




i'm using Life with qmail by dave sill.. everyhting was perfect until 
i execute /usr/local/sbin/qmail start .. and i got the following 
messages ..

[root@pc supervise]# /usr/local/sbin/qmail start                      
                        Starting qmail: svscan.                             
[root@pc supervise]# supervise: fatal: unable to start qmail 
smtpd/run: exec formmat error                                         
supervise: fatal: unable to start qmail-smtpd/run: exec format error  
[[root@pc supervise]# /usr/local/sbin/qmail stop                      
                   Stopping qmail: svscan qmail logging.              
                             
thanks                                                            



Ismal Hisham Mohd Darus
Supervisor, System Support
John Hancock Life Insurance (Malaysia) Berhad




> Hi,
>
> During the Xmas, I seem to have experienced some problems with my qmail
mail
> server.
> This list's ezmlm complains:
>
> ><[EMAIL PROTECTED]>:
> >207.241.173.142 does not like recipient.
> >Remote host said: 553 sorry, that domain isn't in my list of allowed
> rcpthosts (#5.7.1)
> >Giving up on 207.241.173.142.
>
> and I seem to have lost some 40 messages.
> Needless to say, altex.ro is listed in locals and rcpthosts.
>
> There's nothing wrong in the logs.
>
> How can I track down this blackout ?
>
> Claudiu
>
It occured again
Today I got the same message from twistedhumor.com (they're using ezmlm too)

what's up ?

Claudiu






Thus said "D. J. Bernstein" on 19 Dec 1999 16:18:57 GMT:

> If you don't receive any messages on Monday or Tuesday, or if you see a
> message to list.cr.yp.to stuck in a queue on Thursday, let me know by
> sending a message to [EMAIL PROTECTED] I don't anticipate any problems; the
> new software is generally much less fragile than BIND.
So, any hints as to what this new software is??? :)
Andy
-- 
        +====== Andy ====== TiK: garbaglio ======+
        |    Linux is about freedom of choice    |
        +== http://www.xmission.com/~bradipo/ ===+







On Tue, 28 Dec 1999 00:37:59 -0700  Andy Bradford wrote:

> So, any hints as to what this new software is??? :)

http://cr.yp.to/dnscache.html


Reply via email to