> <...> 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"
>
