RE: Can Qmail handles this.....
Thanks. I am using pine in a mail server running sendmail, I use to: and cc: the same person, that is me. When I check the mail box, I get one email only. I believe sendmail know that the mail is going to the same person. So, it simply send me one copy only. However, in qmail. I created a .qmail file at my directory with content nothing. I use pine and send abc a mail with cc to himself also. The result is abc got two identical mails. Can anyone tell me how to make the qmail sends me one email instead of two. I am using qmail with centralize mail directory. that is /var/mail/user Regards, Marcos Tang. Global Information Networks Ltd. -Original Message- From: Russell Nelson [SMTP:[EMAIL PROTECTED]] Sent: Wednesday, December 23, 1998 12:21 PM To: [EMAIL PROTECTED] Subject:Re: Can Qmail handles this. Marcos writes: > Hello, > > Is it possible for qmail to handle just "To:" but not "cc" & > "bcc"? Basically, no. If the message goes through /usr/lib/sendmail or directly through qmail-inject, qmail-inject sucks up all the addresses it finds into the list of envelope recipients. On the other hand, if the email client is parsing the message itself, it might be handing the envelope recipients to /usr/lib/sendmail or qmail-inject. If that's the case, then qmail-inject isn't grabbing addresses (unless special options are used). -- -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.
RE: Can Qmail handles this.....
Marcos writes: > Thanks. I am using pine in a mail server running sendmail, I use > to: and cc: the same person, that is me. When I check the mail box, > I get one email only. I believe sendmail know that the mail is > going to the same person. It's guessing. Not only is it guessing, but it guesses poorly. What if you CC'ed an alias for yourself on a different machine? > So, it simply send me one copy only. > However, in qmail. I created a .qmail file at my directory with > content nothing. I use pine and send abc a mail with cc to himself > also. The result is abc got two identical mails. Can anyone tell me > how to make the qmail sends me one email instead of two. http://www.qmail.org/index.html#eliminate-dups -- -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.
Re: verifying system binaries, a la R*dh*t
> From: "Sam" <[EMAIL PROTECTED]> writes: > However, I can't blame Red Hat for refusing to ship a software package > without a way to verify the integrity of the installed binaries. > Especially when there is no sound reason why it has to be that way. > According to Dan, his install time config of the uids is fine with Redhat, and moving qmail to a different place is ok, as long as there's a link from /var/qmail... It's hard to see what problems remain. So, perhaps you could bug redhat for a bit. sdb
Re: Relay to Exchange inside a firewall
On Tue, Dec 22, 1998 at 06:30:22PM -0500, Sam wrote: # On Tue, 22 Dec 1998, Justin Bell wrote: # # > On Tue, Dec 22, 1998 at 02:50:02PM -0800, Michael Sage wrote: # > # Hello, # > # # > # As a relative Linux newbie, I need some help setting up qmail to relay ALL # > # mail for 'domain.com' to an Exchange server inside a firewall. The firewall # > # access is easy, and I will have my MX record pointing to the qmail box # > # outside the firewall. What I need help with is: Is there a simple # > # configuration adjustment that I can make to accomplish this? # > # # > # > # > in ~alias # > # > .qmail-default # > |forward "$local"@[exchange server ip address # # Nope, that sends _all_ mail for domain.com, example.com, aol.com, and # everything else, over to exchange. well, sure, if it's in locals it will be forwarded it is how we are setup and is exactly what we need -- /- [EMAIL PROTECTED] --- [EMAIL PROTECTED] -\ |Justin Bell NIC:JB3084| Time and rules are changing. | |Simon & Schuster A&AT | Attention span is quickening.| |Programmer | Welcome to the Information Age. | \ http://www.superlibrary.com/people/justin/ --/
Re: verifying system binaries, a la R*dh*t
Scott Ballantyne writes: > > From: "Sam" <[EMAIL PROTECTED]> writes: > > However, I can't blame Red Hat for refusing to ship a software package > > without a way to verify the integrity of the installed binaries. > > Especially when there is no sound reason why it has to be that way. > > According to Dan, his install time config of the uids is fine with > Redhat, and moving qmail to a different place is ok, as long as > there's a link from /var/qmail... It's hard to see what problems > remain. So, perhaps you could bug redhat for a bit. That would be a waste of time. Dan doesn't trust Redhat; Redhat doesn't trust Dan. Note that Redhat is not unique in this regard. -- -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.
Re: Frivolous forking
Sam <[EMAIL PROTECTED]> writes: > However, this approach does require more code. What you save by > eliminating the few lines of code to read the IDs at startup is offset > by the additional code you have to implement to install the IDs in the > first place. True. But that code is, at least in theory, only ever run once for a given installation, which makes it much harder for that code to be a security hole even if it has bugs. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/>
Re: Frivolous forking
Once upon a midnight dreary, Scott Ballantyne had spoken clearly: >Reinstalling is perfectly acceptable, and you would have to >reinitialize the ids anyway. I think validated backups are a better >way to go, but each to their own. Not picking on you, Scott... but I'd rather reply instead of starting a new msg. fresh... Anywho: As I helped start this whole friggin' mess, I have a question about reinstalling: How do you install a qmail system on a machine *without a compiler*... especially when all you have to work with is a box that already runs qmail; and *that* box has different qmail ID's than the target box? RPM would be nice for that... I have no clue how to do what I propose, other than totally whacking up that other box to do the compile, and if that's a production system, that would be totally unacceptable. Anyway, just another idea for the fray... ;-) Roger "Merch" Merchberger
Re: System integrity verification and other delusions
Sam writes: > In a sitution like this, you just *don't* ship a binary package that, > after it's installed, it scribbles all over its binary files. sendmail's /etc/aliases.db is a security-critical binary file created from user-supplied configuration data. How, pray tell, are you going to check the integrity of /etc/aliases.db? If you can verify /etc/aliases.db, why can't you verify the qmail files? Well, some files are treated as config files (so they are expected to be modified), but apparently RH treats aliases.db in a special way: from the sendmail spec file (used to create the binary distribution) I see %config /etc/aliases %ghost /etc/aliases.db What is %ghost ? A germ of hope? Mate
Re: System integrity verification and other delusions
On 23 Dec 1998, Russell Nelson wrote: > > Probably could. How's about I ask Redhat about distributing a > var-qmail? If they don't have a problem with that, then it's a moot > point, eh? I realize it's a moot point because of the personality conflict between the good folks at Redhat and Dan's ego but I have a question about var-qmail. I finally read http://pobox.com/~djb/qmail/var-qmail.html (I haven't up until this point because I have no need to distribute a qmail package). If I understand it correctly, a var-qmail package is not allowed to enable qmail to send and receive messages. It seems the var-qmail package is allowed to put all the binaries and control files in place but it is not allowed to start qmail. "A user has to follow the instructions in /var/qmail/doc/fastforward/ALIASES and in /var/qmail/doc/INSTALL starting at step 9:" So, does that mean a var-qmail RPM couldn't do those six extra steps FOR the user? If not, how is a user supposed to know what file(s) to read to know what to do next? That seems like a pretty steep restriction to me. Vern -- ,+'^'+, Vern Hart O Creative Design Engineer - The Hungry Programmers `+,.,+' [EMAIL PROTECTED] http://www.hungry.org 11:09pm up 10 day(s), 13:18, 23 users, load average: 0.29, 0.28, 0.27
Why Red Hat is not distributing qmail
Once upon a time, Donnie Barnes said that he needed quick installation, but couldn't assume particular uids, and couldn't rely on the system assembler or linker being available. I added the necessary linking tools to qmail. I described to him how a precompiled package would work, and asked if that settled his concerns. ``Having to get permission on every set of binaries that we compile is *not* an option,'' he said. ``The issue for *me* is to a) be able to build my own binaries without getting permission from *you* before I distribute them and b) be able to allow folks to also do that if they want to redistribute Red Hat.'' He explained that he needed to be able to compile binaries for different architectures and with different optimizers. I explained my concerns about cross-platform compatibility. ``Do you think that you're capable of producing packages meeting these fundamental quality guarantees?'' I asked. He said yes. I put together a public statement granting everyone permission to create precompiled var-qmail packages, subject to compatibility requirements. Russell Nelson writes: > How's about I ask Redhat about distributing a var-qmail? I already did. That was in June 1998. In response, Donnie Barnes demanded that he be given control over the qmail source code. ``I know the point of your licensing is to protect against forks, but you're being paranoid,'' he said. In fact, forks are traditional UNIX vendor behavior. I described how Debian had screwed up cross-platform compatibility by changing the qmail file locations. He dismissed my concerns, and said that he needed to change the paths too. I tried some different explanations of why cross-platform compatibility was so important. Finally I asked him why he felt compelled to break cross-platform compatibility. ``I didn't say I did want to,'' he said. ``I may not. I just want the right to do that and other things you seem to find offensive. Of course, you're just about the only one who finds those things offensive, but I guess it's *possible* that you are right and everyone else is wrong. Sure, it's possible.'' Every sysadmin I know is disgusted at the frivolous incompatibilities introduced by UNIX vendors. Donnie Barnes simply doesn't care. _He_ doesn't benefit from portability. _He_ won't suffer when he toys with the qmail interface. But those of us who deal with multiple systems will be faced with a support nightmare---forever. I tried to work with Donnie Barnes. I put a lot of effort into making qmail distributable in binary form. But he isn't willing to guarantee cross-platform compatibility. It saddens me that he hasn't been honestly telling his users the nature of our disagreement. ---Dan
Re: verifying system binaries, a la R*dh*t
Sam <[EMAIL PROTECTED]> writes: > Why should anyone jump through hoops in order to accomodate just one > software package, out of thousands out there? To make the package maintenance system more flexible and thorough? > So, is it now open season for thousands of developments invent thousands > of different features which are required to verify the integrity of their > packages, and then insist that a single package maintenance tool satisfy > all of them? Um, no. The package maintenance tool provides the *hook*; it executes a script written by the *package maintainer* included in the *package file* that does any custom verification of the installed package. That's the whole point -- the package maintainer can write a script included in the package file to do arbitrary checking, the package maintaintenance tool only needs to know how to execute the script if it exists. > That is downright silly. Yes, it is, which is why I didn't suggest it. [...] > Uh, huh... And would you care to volunteer to write the code which will > know the location of the CD-ROM device on every UNIX system out there, > in addition to knowing the location of the original binaries that are > shipped with every UNIX distribution out there? ... No, because the code is already written -- the Redhat package manager already has the capability to check the on-disk files against the copies on the CD-ROM. This is what spawned the whole thread in the first place, because people were complaining that qmail's embedded uids foiled Redhat's checksum binary verification methods. This is not some pie-in-the-sky suggestion for the base qmail tarball from koobera, or every distribution out there -- this is specific to Redhat's package manager, which is what the discussion was about. You seem to have mistaken me for someone whom you have a fundamental disagreement with, as you've sent a pointless knee-jerk zero-content reply with excessive sarcasm that makes it clear that (a) you didn't comprehend what I was attempting to communicate before you responded, or (b) you haven't been keeping up with the thread. Either way, if you're not interested in being constructive, please don't bother responding. HAND. -- shame is no weapon against the shameless. -- john perry barlow [EMAIL PROTECTED] (michael handler)
Re: verifying system binaries, a la R*dh*t
From: Russell Nelson <[EMAIL PROTECTED]> writes: > > That would be a waste of time. Dan doesn't trust Redhat; Redhat > doesn't trust Dan. Note that Redhat is not unique in this regard. > I've never seen any reason to not trust Dan Bernstein. He may hold the bar higher than some people like, but I don't have a problem with that. sdb
Re: Relay to Exchange inside a firewall
The question is if the following can be done or not: the original recipient is [EMAIL PROTECTED] and the exchanger accepts mail to joe@[1.2.3.4] where 1.2.3.4 is the xchanger's IP. If this is the case, then this should work: put domain.com:alias-domain in control/virtualdomains and domain.com in control/rcpthosts. Then in ~alias/.qmail-domain-default put |forward $LOCAL@[1.2.3.4] See the man page for qmail-command, dot-qmail, forward, qmail-send (for virtualdomain). Mate--- Mate Wierdl | Dept. of Math. Sciences | University of Memphis
Re: verifying system binaries, a la R*dh*t
On 23 Dec 1998, Scott Ballantyne wrote: > > I've never seen any reason to not trust Dan Bernstein. He may hold > the bar higher than some people like, but I don't have a problem with > that. I don't think it's Dan's standards or anything like that. And I don't think it's Dan's inability to include user requests in his software--It sounds like Dan bent over backwards to try and accommodate Redhat. It's Dan's attitude. Even after making all the allowances the guy from Redhat wanted, Redhat still didn't want to include qmail. What that says to me is that Dan fundamentally offended someone and that someone couldn't get over it. While I'm not condoning holding personal grudges it says a lot about how Dan interacts with people--not well. Vern -- ,+'^'+, Vern Hart O Creative Design Engineer - The Hungry Programmers `+,.,+' [EMAIL PROTECTED] http://www.hungry.org 12:14am up 10 day(s), 14:23, 21 users, load average: 0.29, 0.23, 0.24
Re: Red Hat Linux and Frivolous forking
No need to CC me, I'm on the list. See FAQ/1.3. As to make, I guess you don't use make -n install. It doesn't actually install, just shows you what's going to happen. That's one way. Another I case of qmail, you see nothing: make setup check. is to actually look at (and modify if necessary) the makefiles before you even start. In case of qmail, you look at hier.c. Knowing where things are gonna go in advance is something I learned a long time ago with earlier versions of innd. Before you install an rpm, you do rpm -qpl package.rpm to see where things will go. Once the package is installed, you do rpm -ql to see all the files installed. Now, how can you check where your gcc files are when 1 year later you would like to update it, or 2 mos later when a user cannot find a header file for objective C? How can you be certain that when you install a new package it will not nuke some files from other packages? How about config files? You back them up before every upgrade? In any case, I know that one can take care of everything by hand---but terribly errorprone, and repetitive. Mate
Re: Frivolous forking
Russ Allbery writes: > The notion of an NFS-mounted /usr that contains all static binaries All I'm asking for is a single cross-platform location, /var/qmail, where users and scripts and other programs can find the qmail files. That doesn't stop you from symlinking /var/qmail/bin to a shared disk, if you have coordinated all compile-time information, notably the uids. Vendors that include qmail in the base package can easily do this. Debian moved the files _without_ leaving symlinks. That's frivolous incompatibility. Red Hat wants to do the same thing, presumably to a different set of locations. When will they ever learn? ---Dan
Re: Frivolous forking
D J Bernstein <[EMAIL PROTECTED]> writes: > All I'm asking for is a single cross-platform location, /var/qmail, > where users and scripts and other programs can find the qmail files. > That doesn't stop you from symlinking /var/qmail/bin to a shared disk, > if you have coordinated all compile-time information, notably the uids. > Vendors that include qmail in the base package can easily do this. My experience is that having stuff live in more than one canonical location is a disaster waiting to happen. Probably not from a security perspective, but from a maintenance one. It *seems* like a straightforward solution, but I've gotten bitten by symlink forests too many times; they either don't get created right or they end up pointing to the wrong thing or people who don't understand what's going on can't manage to figure out why something isn't working right. I really don't think this particular problem has any good solution. I like to use a single directory tree for some packages; for other packages, I'd rather install everything seperately into standard locations. For package management in AFS, we install every package into its own mini installation tree and create symlink forests, but I've done this for local disk installs and never would again. You sort of have to do this for AFS because you can't fit all of your software in one volume and you want to have separate release control over the different chunks of it, though. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/>
fastforward (HELP)
Help Please...fastforward doesn't work. I already setup q-mail under tcpserver, like this: 17151 p0 S0:00 /var/qmail/bin/splogger smtpd 3 - 17155 p0 S0:00 qmail-lspawn ./Mailbox 17154 p0 S0:00 splogger qmail 17157 p0 S0:00 qmail-clean 17156 p0 S0:00 qmail-rspawn 17153 p0 S0:00 qmail-send 17150 p0 S0:00 /usr/local/bin/tcpserver -c 100 -v -u 501 -g 502 0 smtp /var/qmail/bin/qmail-smtpd and I already install fastforward, and configure it as mention in the manual, like: newaliases /etc/aliases become /etc/aliases.cdb and looks like this engineer@: , &[EMAIL PROTECTED] , &[EMAIL PROTECTED] ; ~alias/.qmail-default looks like this |fastforward -d /etc/aliases.cdb but unfortunatelly it won't work :-( help me please Thanks.
Re: System integrity verification and other delusions
On Wed, Dec 23, 1998 at 02:45:07AM -, D. J. Bernstein wrote: > Peter C. Norton writes: > > As to why I'd rather not have to recreate the files - if I'm following > > a break-in, I have more useful things to do, like find the schmuck who > > did it. Being able to verify binaries on a large number of systems > > helps me do that. > > So what do you do about /etc/aliases.db? Why can't you do the same thing > with the qmail files? I would not need a compiler and associated tools to rebuild /etc/aliases.db. I may instead create an rpm for myself that has the /etc/aliases.db that I use for a site and compare that as well. For sites with sendmail, it's not a bad idea. So why isn't qmail flexible enough to let me do the same thing for its files? > I get the impression that, in fact, you don't verify /etc/aliases.db, > and that you're relying on security through obscurity. That's dangerous. > Promoting such behavior is irresponsible. Throwing out buzzwords like security through obscurity and vaporware (I've definetely got the script I mentioned to read /etc/aliases.db, but you didn't ask) doesn't mean anything at this point. How am I promoting such behavior? You're spouting BS. > > Don't you want to know how you're being attacked? > > How the initial intrusion happened, yes, so that I can explain how to > fix the hole. But there's no hole involved in setting up a trojan horse > once you already have root. You do it your way. I'd like to have that information. > > But it's not possible to do this across multiple systems that have > > different uid's. > > Wrong. All the necessary tools are included in a var-qmail package. Go > read http://pobox.com/~djb/qmail/var-qmail.html. The var-qmail system isn't flexibly enough to work with, extend, or augment my packaging tools, which do accomodate everything else I've packaged. It still doesn't even give me a guarantee that I can compare 2 binaries on 2 systems. I don't like it. BTW, the following: "Of course, these aren't problems for an operating system that includes qmail as the default MTA." is pretty funny. -Peter
var-qmail packages and qmail-run packages
Vern Hart writes: > If I understand it correctly, a var-qmail package is not allowed to > enable qmail to send and receive messages. Right. Those features are handled by a qmail-run package. Different qmail-run packages can offer different features: running qmail under supervise, for example, or using tcpserver instead of inetd. You can freely install a var-qmail package without affecting other MTAs. qmail-run is different: it promotes qmail into the special position of receiving messages on port 25. > If not, how is a user supposed to know what file(s) to read > to know what to do next? See qmail-1.03/BIN.README. This would be README in a typical var-qmail tarball. Other package systems might display a message on the screen. ---Dan
Re: verifying system binaries, a la R*dh*t
From: Vern Hart <[EMAIL PROTECTED]> writes: > It's Dan's attitude. Even after making all the allowances the guy from > Redhat wanted, Redhat still didn't want to include qmail. What that > says to me is that Dan fundamentally offended someone and that someone > couldn't get over it. > It's *Dan's* attitude? This thread has just gone where no thread should have gone. Comments like these, if made at all, should be made privately. I happen to admire the way Dan interacts with people, which I have only seen on the net, I admit. But on the net he's direct, he's honest, and he's smart. When he's wrong, which he almost never is, he admits it. > While I'm not condoning holding personal grudges it says a lot about how > Dan interacts with people--not well. > If this is really what is going on then Redhat should grow up and appreciate talent. sdb
Re: Frivolous forking
[snip] > What happens if there's a security hole in getpwnam(), on a UNIX > system that allows file giveaways? Then the whole system is fucked up, and qmail can't do quite a little about that. > With this patch, the attacker breaks into qmail-getpw, then changes > the owner of /var/qmail/owners/uidp to root, then breaks into root, > then has complete control over your system. The security barrier > around root has been breached. Which could - in that hypothetic case - be achieved by zillion other means. > > When's the last time you reconfigured your system uids? You have to > take the system down and do a massive file conversion. Why is it > such a big deal to reinstall qmail on these rare occasions? See Dan, for you "install" means $less INSTALL.* $vi some_cfg_files $make $su - #make install check or whatever the stuff is really called. For me install means rpm -ivh qmail*rpm. That's one of a hell of a difference. I don't recompile every single thing (hell, I could even live without a gcc installed) I install - I just tend to trust the PGP signatures, MD5 checksums and RedHat fixing holes ASAP. -- Petr Novotny, ANTEK CS [EMAIL PROTECTED] http://www.antek.cz -- Don't you know there ain't no devil there's just God when he's drunk. [Tom Waits]
Re: Frivolous forking
> When's the last time you reconfigured your system uids? You have to > take the system down and do a massive file conversion. Why is it > such a big deal to reinstall qmail on these rare occasions? Almost every site I've been to in the last 3 years could do with a massive overhaul including changing uids. Your attitude only adds to the work that such an overhaul entails. That's why its such a big deal. Other programs can be easily reconfigured with find, grep, and sed. Qmail has to be recompiled and reinstalled, a waste of skilled time. Such time isn't free, or even cheap. -Peter
Re: verifying system binaries, a la R*dh*t
On 23 Dec 1998, Scott Ballantyne wrote: > > It's *Dan's* attitude? This thread has just gone where no thread > should have gone. Comments like these, if made at all, should be made > privately. I happen to admire the way Dan interacts with people, which > I have only seen on the net, I admit. But on the net he's direct, he's > honest, and he's smart. When he's wrong, which he almost never is, he > admits it. This makes me think of Mathew and Bill from the TV show "News Radio." Russ Nelson is one of qmail's biggest advocates and yet he has been offended by Dan. In a recent high-profile, systems administrators conference Russ defended qmail on a panel with representatives for sendmail (Allman), postfix (Venema), and exim (FitzGibbon) and he did a good job. But Russ was afraid to mention the author of qmail's name because he didn't want to alienate anyone. I'm not positive what his exact motivation for not mentioning Dan's name but it goes to show that Dan can have a negative effect on people. I am also a firm supporter of qmail. It's a great program and works very well in so many different ways. I wouldn't want to disparage Dan's programming abilities--they're obviously top notch--but people skills leave a lot to be desired. Perhaps Dan could employ (on a volunteer basis, of course) a qmail front man that would act as a buffer between Dan and the rest of the world. Someone to help Dan keep his high standards while not being so abrasive. It worries me that there is so much discord among the strongest qmail supporters--us on this list. Vern -- ,+'^'+, Vern Hart O Creative Design Engineer - The Hungry Programmers `+,.,+' [EMAIL PROTECTED] http://www.hungry.org 1:16am up 10 day(s), 15:25, 16 users, load average: 0.45, 0.42, 0.69
Setting up pop3 and smtp
Hi all, In the FAQ it states how to run qmail-pop3d and qmail-smtpd via the inetd table. Is there a way that I can set up the above two deamons to work without the inetd configuration. Because they are both referred to as daemons, the d at the end of the name, I am assuming that this can be done, since they both support functionality of daemons. Please correct me if I am wrong, and if there is a solution to my question please can you help me on that. I am currently using both of the above, but I need to support virtual domains on the same box. I will need to bind the deamons to the interface of each virtual domain. Thank you in advance for the help lara Lara Marquesemail: [EMAIL PROTECTED] Software Developer work: +27 11 402 4116 fax: +27 11 402 4118 http://www.mighty.co.za Cellular: 082 656 4665
Re: verifying system binaries, a la R*dh*t
>good job. But Russ was afraid to mention the author of qmail's name >because he didn't want to alienate anyone. [snip] >I am also a firm supporter of qmail. It's a great program and works >very well in so many different ways. I wouldn't want to disparage Dan's >programming abilities--they're obviously top notch--but people skills >leave a lot to be desired. Thank god* none of you have met the person who wrote the 'ls' command for Unix. Man was he a human pig of monstrous proportions**. If any of you knew what he was like on the "people skills" front, I'll bet that you'd all use "echo *" in preference to "ls". Regards. * For those paying attention, should that be "Thank God unix" :> ** Yes, it's an ambit proposition. "ls" was probably authored by Richie or Kernighan which by my very limited experience both appear to be genuinely nice people on many fronts.
Re: verifying system binaries, a la R*dh*t
Vern Hart O Creative Design Engineer - The Hungry Programmers writes: > I'm not positive what his exact motivation for not mentioning Dan's > name but it goes to show that Dan can have a negative effect on people. > Well, you're starting to have a negative effect on me... If Redhat chooses software based on the personality of the programmer who wrote it, than there couldn't be a better reason to avoid Redhat. sdb
Re: Setting up pop3 and smtp
On Wed, Dec 23, 1998 at 10:24:35AM +, Lara Marques wrote: > Hi all, Hi! > Is there a way that I can set up the above two deamons to work > without the inetd configuration. Yes, but they still require that they be run from within another program that actually listens to the network. Tcpserver is the most common choice when using qmail and other software written by djb. The details of setting up tcpserver can be found as part of the excellent instructions at: http://qmail-docs.surfdirect.com.au/docs/qmail-antirelay.html However tcpserver is up to version 0.84 now. Otherwise the instructions should hold. > I am currently using both of the above, but I need to support virtual > domains on the same box. > I will need to bind the deamons to the interface of each virtual domain. Are you *sure* you have to do it this way? Look at the FAQ that comes with qmail and read up on how qmail supports virtual domains. I doubt you need to bind a daemon to each ip address you have configured. -Peter
Re: fastforward (HELP)
On Wed, 23 Dec 1998, Moh. Deny Kurniawan wrote: > Date: Wed, 23 Dec 1998 14:33:24 +0700 (WIB) > From: "Moh. Deny Kurniawan" <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: fastforward (HELP) > > > Help Please...fastforward doesn't work. > > I already setup q-mail under tcpserver, like this: > > 17151 p0 S0:00 /var/qmail/bin/splogger smtpd 3 - > 17155 p0 S0:00 qmail-lspawn ./Mailbox > 17154 p0 S0:00 splogger qmail > 17157 p0 S0:00 qmail-clean > 17156 p0 S0:00 qmail-rspawn > 17153 p0 S0:00 qmail-send > 17150 p0 S0:00 /usr/local/bin/tcpserver -c 100 -v -u 501 -g 502 0 > smtp /var/qmail/bin/qmail-smtpd > > and I already install fastforward, and configure it as mention in the > manual, like: > newaliases /etc/aliases become /etc/aliases.cdb and looks like this > engineer@: > , &[EMAIL PROTECTED] > , &[EMAIL PROTECTED] > ; > ~alias/.qmail-default looks like this > |fastforward -d /etc/aliases.cdb > > but unfortunatelly it won't work :-( > help me please > Thanks. you may have configured it, but have you tested your configuration ? in file ALIASES there are several steps for testing whether fastforward works or not. -wasz-
Re: verifying system binaries, a la R*dh*t
On 23 Dec 1998, Scott Ballantyne wrote: > > Well, you're starting to have a negative effect on me... I don't mean to. My criticisms of Dan aren't meant to convince anyone not to use qmail. qmail is very good. Everyone should use qmail. > If Redhat > chooses software based on the personality of the programmer who wrote > it, than there couldn't be a better reason to avoid Redhat. Don't take my word as Redhat doctrine. I have nothing to do with Redhat and have no insight into their decision processes. Vern -- ,+'^'+, Vern Hart O Creative Design Engineer - The Hungry Programmers `+,.,+' [EMAIL PROTECTED] http://www.hungry.org 1:53am up 10 day(s), 16:03, 15 users, load average: 0.19, 0.18, 0.23
Re: Setting up pop3 and smtp
Lara Marques writes: > Hi all, > > In the FAQ it states how to run qmail-pop3d and qmail-smtpd via the inetd > table. > The tcpserver is available on the qmail URL, and: tcpserver -R -v -x /my/path/tcp.smtp.cdb -u 123 -g 456 0 smtp \ /var/qmail/bin/qmail-smtpd 2>&1 | /var/qmail/bin/splogger smtpd 3 & tcpserver -R -v -x /my/path/tcp.pop3.cdb -u 0 -g 789 0 pop3 \ /var/qmail/bin/qmail-popup mymachine.mydomain.com \ /var/qmail/bin/checkpassword /var/qmail/bin/qmail-pop3d \ Maildir 2>&1 | /var/qmail/bin/splogger pop3 3 & is what I use. John -- John Conover, 631 Lamont Ct., Campbell, CA., 95008, USA. VOX 408.370.2688, FAX 408.379.9602 [EMAIL PROTECTED], http://www2.inow.com/~conover/john.html
Re: OK, I did something stoopid...
At 02:49 PM 12/22/98 , Gerry Boudreaux wrote: >Hi, > >After running qmail for almost a year, I have hit my first problem.. > >I had a message stuck in the queue, and decided to delete it... > >Now, even after looking at ls -lR in /var/qmail/queue I see nothing >left of message 115207, yet I get the following messages every time >qmail processes it's queue. > >Where is this message coming from? (How does qmail remember what is in the >queue, after the 3 queue files are deleted (./mess/0 ./info/0 ./remote/0) >(I think) > >How do I get rid of qmail's 'memory' of this message when I cannot find >anything left of the message in the queue directory tree? > >Thanks in advance! > >914366407.284040 warning: trouble opening local/0/115207; will try again later > >Gerry Boudreaux I didn't take me that long to do something stupid! I got the same messages... and wondered the same stuff. I deleted the three files and even restarted all of the qmail daemons a few times. It eventually went away. I think the maximum lifetime of message in the queue is a week, so if it's still bugging you after a week, write another message to the list. BTW, the correct way to remove a message from the queue (from reading up on this after the fact) is to kill qmail then delete it, or use one of the queue management programs available from www.qmail.org --Ludwig Pummer ( [EMAIL PROTECTED] ) ICQ UIN: 692441 ( [EMAIL PROTECTED] )
Re: group-depending mailing list
Russell Nelson wrote:
> Mirko Zeibig writes:
> > Hello,
> > whenever a new user is created, he or she is member of several groups
> > (all, adm, dev etc.) to gain rights using samba and to deliver mail
> > automatically to every member of the group when mail is sent to all@,
> > adm@ etc.
> > Now I use to edit ~alias/.qmail-all, .qmail-adm etc. files and add the
> > appropriate users manually. I started to write a redirect like this:
> > | /var/qmail/bin/qmail-inject $(/bin/cat /etc/group | /bin/grep alle: |
> > /bin/awk -F':' '{print $4}' | /bin/sed 's/,/ /g')
> > which will alias cause to deliver the message but now the From adress is
> > rewritten to alias, which was not my goal of course.
>
> Yes, the envelope sender will match the user which sent the mail. If
> you need it to be something else you should use the -f switch to
> qmail-inject.
Hello,
this I already knew ;-). Now: how to get the sender from the message which
alias will deliver. I could of course just start a thing like getting the
"From" from the first line of the incoming message, strip of the From and use
this as sender:
| (MYFROM=$(head -1 | sed ´s/From\ //´ ; cat - ) | /var/qmail/bin/qmail-inject
-f"$MYFROM" $(/bin/cat /etc/group | /bin/grep alle: | /bin/awk -F':' '{print
$4}' | /bin/sed 's/,/ /g')
Merry XMas
Mirko
Re: verifying system binaries, a la R*dh*t
Mark Delany <[EMAIL PROTECTED]> writes: > Thank god* none of you have met the person who wrote the 'ls' command > for Unix. Man was he a human pig of monstrous proportions**. If any of > you knew what he was like on the "people skills" front, I'll bet that > you'd all use "echo *" in preference to "ls". I appreciate this argument, but if I want to modify ls, I don't have to deal with the original author. It's therefore not an issue. If I want to modify qmail, I do have to deal with Dan due to the license. I understand his reasons for preferring the license that he uses, but using such a license necessarily implies that people doing things with qmail have to deal with Dan, and Dan's personality and mode of interaction *are* a factor in deployment of qmail. I personally have no problems whatsoever with his mode of interaction. I personally like it. I'm also the only person in my acquaintance with that opinion. And I think I'll drop this topic here. Talking about it on the list doesn't do any good if Dan doesn't want to do anything about it, and if he does, talking about it here isn't going to help either. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/>
Re: Frivolous forking
Russell Nelson writes: > This is a red herring. /var/qmail/owners is chmod 700. owners? -- Jos Backus _/ _/_/_/"Reliability means never _/ _/ _/ having to say you're sorry." _/ _/_/_/ -- D. J. Bernstein _/ _/ _/_/ [EMAIL PROTECTED] _/_/ _/_/_/use Std::Disclaimer;
Email Trapping
Hello, I am trying to configure qmail to trap email to/from certain addresses and redirect it to a "Waste Bin" - Can anybody help with this? Andy. ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. All information is the view of the individual and not necessarily the company. If you are not the intended recipient you are hereby notified that any dissemination, distribution, or copying of this communication and its attachments is strictly prohibited. If you have received this email in error please notify [EMAIL PROTECTED] This email has been swept for computer viruses. **
Re: verifying system binaries, a la R*dh*t
On 23 Dec 1998, Russell Nelson wrote: > > According to Dan, his install time config of the uids is fine with > > Redhat, and moving qmail to a different place is ok, as long as > > there's a link from /var/qmail... It's hard to see what problems > > remain. So, perhaps you could bug redhat for a bit. > > That would be a waste of time. Dan doesn't trust Redhat; Redhat > doesn't trust Dan. Note that Redhat is not unique in this regard. Neither is Dan. Vince. -- == Vince Vielhaber -- KA8CSH email: [EMAIL PROTECTED] flame-mail: /dev/null # includeTEAM-OS2 Online Searchable Campground Listingshttp://www.camping-usa.com "There is no outfit less entitled to lecture me about bloat than the federal government" -- Tony Snow ==
Re: verifying system binaries, a la R*dh*t
>That would be a waste of time. Dan doesn't trust Redhat; Redhat >doesn't trust Dan. Note that Redhat is not unique in this regard. Nor is Dan, I might add. I would rather gnaw off my arm than use something from Redhat. Personally I think that this has gone way too far. I agree with Dan that using getpwnam() is not acceptable, I disagree that editing binaries is a sane thing to do. I don't see why people can't get off their asses and type make setup on their own, but if they are so lazy I also don't see why the UIDs can't be put in to control files. I don't see how putting information in a control file is any less secure than putting it in a binary, and while it adds more code it would solve this stupid argument, which in itself is a worthy goal! Evan
aliases.db
This argument about not being able to monitor aliases.db is interesting: just because rpm cannot monitor certain files, does not mean it should give up monitoring *all* the files. And indeed, RH (Linux, in general), puts all the sys files it cannot monitor are put under /etc (config files) and /var. And this gives the long awaited solution to all the problems regarding qmail on RH: put all the qmail binaries in a subdirectory under /var, and mark them %ghost in the spec file. You can always use tripwire to monitor /var/whatever and /etc. Mate
Re: Why Red Hat is not distributing qmail
D. J. Bernstein writes: > I tried to work with Donnie Barnes. I put a lot of effort into making > qmail distributable in binary form. But he isn't willing to guarantee > cross-platform compatibility. He's committed to cross-platform compatibility -- in the form of the File Hierarchy Standard. "What if the FHS changes?" He doesn't want to have to come begging, on his knees, for the permission to comply with the industry standard, in violation of your standard. Dan, just because you decide something, that doesn't make it an industry standard. As someone else said, "Who does he think he is?" The basic problem is that you don't trust Redhat. If you trusted them, then you would give them the freedom to distribute modified binaries. Redhat is returning that distrust. Not only that, but Donnie is so confident that you have sufficiently marginalized yourself that he isn't going to bother to dispute you. -- -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.
RE: aliases.db
Mate Wierdl wrote/schrieb/scribsit: > And this gives the long awaited solution to all the problems regarding > qmail on RH: put all the qmail binaries in a subdirectory under /var, > and mark them %ghost in the spec file. Yes, but it seems that not being able to verify the binaries is not an option for some people... Apart from that, to install a %ghost file will be hard, since %ghosts -by nature- will not be packaged by rpm. My solution would be to tell rpm not to check MD5 and mtime for qmail binaries. You still can't compare them to the originals then, but at least rpm -V won't scream after the uids are patched in. Stefan
Re: verifying system binaries, a la R*dh*t
Mark Delany writes: > If any of you knew what he was like on the "people skills" front, > I'll bet that you'd all use "echo *" in preference to "ls". Mark, I know of at least three people who feel *exactly* that way about Dan and his software: "I would never consider using anything written by djb". Dan writes software which is heads and tails above anything written by anyone else. He is probably better than anyone else at programming. He is also better than anyone else at alienating people. At least, better than any programmer I've ever met. -- -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.
Re: tcpserver initscripts question
Hello, what is the easier package of initscripts to install for tcpserver? the rpm package of the tar.gz package? Please let me know. What rpm package are you talking about: tcpserver-initscripts? That does not contain the qmail initscripts; only a script to start rlogind, telnetd, etc. The qmail initscripts are part of the qmail rpm---presently. But I'll change that in the future. At this point, it is easiest: install the ucspi-tcp rpm, daemontools rpm, and the qmail rpm---and possibly the tcpserver-initscripts rpm. Mate
Re: OK, I did something stoopid...
On 22-Dec-98 23:49:32, Gerry Boudreaux wrote something about "OK, I did something stoopid...". I just couldn't help replying to it, thus: > Now, even after looking at ls -lR in /var/qmail/queue I see nothing > left of message 115207, yet I get the following messages every time > qmail processes it's queue. > Where is this message coming from? qmail-send. > (How does qmail remember what is in the > queue, after the 3 queue files are deleted (./mess/0 ./info/0 ./remote/0) > (I think) qmail-send keeps the message numbers in memory. You should generally delete queue/*/*/115207 when deleting message 115207. > How do I get rid of qmail's 'memory' of this message when I cannot find > anything left of the message in the queue directory tree? Stop and start qmail. Regards, /¯¯T¯\ | Rask Ingemann Lambertsen | [EMAIL PROTECTED] | | Registered Phase5 developer | WWW: http://www.gbar.dtu.dk/~c948374/ | | A4000, 775 kkeys/s (RC5-64) | "ThrustMe" on XPilot and EFnet IRC | | Hard work may not kill me, but why take chances? |
Re: Red Hat Linux and Frivolous forking
On 23-Dec-98 00:37:41, Vince Vielhaber wrote something about "Re: Red Hat Linux and Frivolous forking". I just couldn't help replying to it, thus: > Try to keep up, Peter. 1) I don't use RedHat's software. 2) I don't use > RPMs. So what's your point? I should change operating systems to please > you? RPM != RedHat and RPM != Linux. Regards, /¯¯T¯\ | Rask Ingemann Lambertsen | [EMAIL PROTECTED] | | Registered Phase5 developer | WWW: http://www.gbar.dtu.dk/~c948374/ | | A4000, 775 kkeys/s (RC5-64) | "ThrustMe" on XPilot and EFnet IRC | | 3 kinds of people: those who can count & those who can't.|
Re: System integrity verification and other delusions
You simply have to follow the var-qmail rules, to guarantee compatibility. See http://pobox.com/~djb/qmail/dist.html. The operative word is "simply". So: how do I find the 40 arguments to idedit on my RH Linux (elf, littel-endian)---or any other system. Plase Mate
Mailing list from other domains
Hi everyone. I'm facing a problem which I'm not quite sure what to do. this problem involve both qmail and ezmlm. I need to move two mailing lists(each about 1 subscribers) to another hosts on a different domain. here is the description: there are two mailing lists(using majordomo): list1@domain1 and list2@domain2 currently, these lists are on host1.domain3. Now, I need to move them to another host(host2.domain3) which I just installed qmail and ezmlm. I did some simple tests on qmail and ezmlm and they both seem to work. both these lists are to be controled by the admin (not a normal user). The things I'm not sure are : 1) how can I set up ezmlm so qmail knows how to deliver the mails sent to list1@domain1 and list2@domain2 ? or, I have to do some thing to qmail. I set up qmail before, but only to accept mails for the domain the host's on. I'm not sure how to set up qmail to accept mails sent to a completely different domain. 2) once I set up the lists on the new hosts, is there anyway of testing it without losing any messages ? 3) do I need to install ezmlm-idx ? maybe the problem has arose in the list before. I did search the archive most of my search results are about virtual hosts. I'm not sure if thats what I need. Thank you very much.
Re: FWIW: FHS definition of /var
Everything that once went into /usr that is written to during system operation (as opposed to installation and software maintenance) must be in /var. Hence qmail should be installed under /var. Mate
Re: Why Red Hat is not distributing qmail
Sam wrote: > On 23 Dec 1998, D. J. Bernstein wrote: > > > In fact, forks are traditional UNIX vendor behavior. I described how > > Debian had screwed up cross-platform compatibility by changing the qmail > > file locations. He dismissed my concerns, and said that he needed to > > change the paths too. > > I don't recall many questions on the list from Debian users and how > confused they are with the different location of all the files. > > As far as vendor's traditional packaging, they are not forks, but > site-specific customizations. If they were real forks, the vendor > would have its own source tree that they work on independently. > > Both Debian and Redhat do not maintain any separate code trees. The > source code they shipped with their OS is the original package source > code. And any OS-specific patches are provided separately. Although they turn the sources into something funny -- SRPMS as far as I know. Don't know the exact detail of this. I do know I like to have my packages in /usr/local/pkgname, like Samba, Squid, Postgres, Apache etc... do. I don't like the RH way of putting everything into /usr. Speaking about that, forgive the naîve question Dan, but what's so special about /var? Cheers, Juan
Re: OK, I did something stoopid...
At 02:48 AM 12/23/98 +0100, Rask Ingemann Lambertsen wrote: [snip] > qmail-send keeps the message numbers in memory. You should generally >delete queue/*/*/115207 when deleting message 115207. I knew this. Just for some reason, after no problems in a year, this happened... >> How do I get rid of qmail's 'memory' of this message when I cannot find >> anything left of the message in the queue directory tree? > > Stop and start qmail. I have done this twice, and, due to the need to rewire part of the computer room, I have even cycled power on this machine, and the message still comes up. I have looked repeatedly at ls -lR for the /var/qmail/queue tree, and there is nothing left of 115207... Is there anywhere else this could be coming from? Thanks again to those who have responded :-) Gerry
Re: Frivolous forking
Mate Wierdl writes: > I thought the sysadm is supposed to write 9 numbers in a file like > control/ids That was a different proposal. The disadvantage was supposed to be that it wouldn't work with scripts that change uids in the whole filesystem. But it's a waste of time to discuss how this should work, if the main justification for it is incorrect speculation about Redhat's needs. Donnie Barnes told me that install-time uid configuration was fine. But if that is fine, then putting qmail under /var has to be now their main objection---which cannot be a strong one. Afterall, this is a pretty good idea to have qmail under one dir, and then make symlinks. This would take care of installations not having a package manager; they would have an easy way to find the files. As for FHS: it was made w/o putting qmail in the picture. Mate
Re: nm
Mate Wierdl writes: > Can you show me an example how to do this? The low-tech solution is to compile, copy the binary, change the uids in auto_uids.c, recompile, and run cmp -l on the old and new binaries. But I encourage you to learn your system's executable binary format, and write a program that reliably locates symbols inside the binary. Great, thanks. (I was hoping though that you would show a high tech example, so I would know *where* to start learning) Mate
var qmail locals
I saw this somewere in the man pages but for the life of me I can't find it now. I want to have a machine see *.domain.com as local what is the syntax??? I tried localhost domain.com .domain.com this didn't werk??? and I can't find what I read before:(
Re: Red Hat Linux and Frivolous forking
On 23 Dec 1998, Rask Ingemann Lambertsen wrote: > On 23-Dec-98 00:37:41, Vince Vielhaber wrote something about "Re: Red Hat Linux and >Frivolous forking". I just couldn't help replying to it, thus: > > > Try to keep up, Peter. 1) I don't use RedHat's software. 2) I don't use > > RPMs. So what's your point? I should change operating systems to please > > you? > > RPM != RedHat and RPM != Linux. RPM == RedHat Package Manager ^^ Vince. -- == Vince Vielhaber -- KA8CSH email: [EMAIL PROTECTED] flame-mail: /dev/null # includeTEAM-OS2 Online Searchable Campground Listingshttp://www.camping-usa.com "There is no outfit less entitled to lecture me about bloat than the federal government" -- Tony Snow ==
DJB is promoting "Frivolous Incompatibilities"
On Wed, 23 Dec 1998, Mate Wierdl wrote: >You simply have to follow the var-qmail rules, to guarantee >compatibility. See http://pobox.com/~djb/qmail/dist.html. > > The operative word is "simply". So: how do I find the 40 > arguments to idedit on my RH Linux (elf, littel-endian)---or any other > system. The whole idea that you have to use a binary editor is crazy in the first place. The whole idea that reading the uids out of /var/qmail/control/ids will cause "lots of bugs" is equally crazy. Gee, doesn't qmail *already* read configuration info out of control files, and manage to do so securely? Surely a programmer as esteemed as Dan could manage that. If someone is able to change /var/qmail/control/ids, your box is already completely owned and most likely fdisked by that point (by the intruder). There is *ZERO* change in security between having hard coded uids versus a /var/qmail/control/ids file. Since having control/ids would be a) a *ZERO* change in security, and b) very easy to implement then: Dan is being a) lazy or b) headstrong, obstinate, mulish, sulky, dogmatic and illogical. Sounds like Dan is *promoting* "Frivolous Incompatibilities" with the rest of the Unix universe. Dax Kelson Internet Connect, Inc.
Re: Red Hat Linux and Frivolous forking
> RPM == RedHat Package Manager >^^ RPM was originally a RedHat-tool. However, it is no longer a RedHat or Linux-only tool. (it is known to run on Linux - Sparc/Intel/PowerPC/Alpha/m68k/SGI, Solaris - Sparc/Intel, Hewlett-Packard HP-UX 10.20, SCO OpenServer 5.0.2, Digital UNIX 3.2/4.0, SunOS 4.1.3, HP-UX 9.05, AIX 3.2.5, NCR v2.02) >From the rpm.org website http://www.rpm.org/ >: "RPM is the Red Hat Package Manager. While it does contain Red Hat in the name, it is completely intended to be an open packaging system available for anyone to use. It allows users to take source code for new software and package it into source and binary form such that binaries can be easily installed and tracked and source can be rebuilt easily. It also maintains a database of all packages and their files that can be used for verifying packages and querying for information about files and/or packages. Red Hat Software encourages other distribution vendors to take the time to look at RPM and use it for their own distributions. RPM is quite flexible and easy to use, though it provides the base for a very extensive system. It is also completely open and available, though we would appreciate bug reports and fixes. Permission is granted to use and distribute RPM royalty free under the GPL. " So, yes, the "R" in "RPM" stands for RedHat, but that doesn't mean that RPM == RedHat. bt
Re: Red Hat Linux and Frivolous forking
On Wed, 23 Dec 1998, Bart Blanquart wrote: > > So, yes, the "R" in "RPM" stands for RedHat, but that doesn't mean that RPM == >RedHat. Close enuf for me. Vince. -- == Vince Vielhaber -- KA8CSH email: [EMAIL PROTECTED] flame-mail: /dev/null # includeTEAM-OS2 Online Searchable Campground Listingshttp://www.camping-usa.com "There is no outfit less entitled to lecture me about bloat than the federal government" -- Tony Snow ==
Re: DJB is promoting "Frivolous Incompatibilities"
On Wed, 23 Dec 1998, Dax Kelson wrote: > Sounds like Dan is *promoting* "Frivolous Incompatibilities" with the rest > of the Unix universe. This is also frivolously incompatible with the rest of qmail. Under DJB's line of reasoning why have *any* control files??? It would be more secure just to compile in everything. If you ever need to change it, just bust out the binary editor and go to work. This would remove all that silly control file opening and parsing code which we all know is a security disaster waiting to happen. Dax Kelson Internet Connect, Inc.
Re: Frivolous forking
I bet you have some problem with the configuration/installation of one of your daemons, and your logs (also on /var) are constantly rewritten. Like you are trying to start qmail-smtpd, but there is already something else bound to smtp. Mate
future of qmail
Of course, it is entirely possible that overtime qmail will pervail (now that postfix got fatally wounded by a Magnum 821), it becomes clear that it is not possible to securely look up the uids from a file, and RH will end up shipping qmail anyways---modifying rpm perhaps. Afterall, they started shipping netscape way before netscape disclosed its source---in clear violation of their pristine source policy. Market demand does make a difference for RH: they would not ship xforms (hence xfmail) but did ship netscape. It is a much more interesting question, though, what will GNU ship? You cannot expect compromises based on market demands, so the alternative might end up a qmail based gmail. Mate
Re: DJB is promoting "Frivolous Incompatibilities"
Dax Kelson <[EMAIL PROTECTED]> writes: > Dan is being a) lazy or b) headstrong, obstinate, mulish, sulky, > dogmatic and illogical. I don't think you are going to convince anyone with this kind of argumentation. While I have to say that I don't fully understand all the issues with Redhat and qmail and Donnie and Dan, I surely hope that this fight will be won by the best technical arguments. I, too, have more than once heard the statement "qmail is great if you can deal with its author", but I think it would be more correct to say "if you can deal with the level of excellence targeted by its author". Dan reminds me of a fellow over there on comp.lang.lisp who picks every fight he can about incompetence of any kind. Sometimes this is annoying, but most often it is fun. But, people who are so keen on competence and excellence likely behave that way out of experience and it is them who we owe a lot of real progress. Not merely being content with "it works for me, screw the rest", but longing after the proverbial "right thing". So, it is not easy to argue, and almost hopeless to convince someone on "excellence patrol" of ones own little, confronting view of the things without raising to equal levels of competence. I have a great deal of respect for people who do things differently for the right reasons. "This is how it should be, screw the rest". It might not be the most convenient route to follow but it sure leads to new horizons. [whoa what marketing speak.] > Sounds like Dan is *promoting* "Frivolous Incompatibilities" with > the rest of the Unix universe. And maybe for good reasons. Ok, I have to say that I favour run-time configurable uids myself, too. And that I didn't want to pick on you personally, Dax, it's just that I tend to condensate my thoughts around minor dust particles. Especially after returning from a little Christmas party. merry christmas to y'all, Marius -- GNOME: Penguin in bondage.
Re: Can Qmail handles this.....
You can use formail of the procmail package or reformail of the maildrop package for removing duplicates. Use the -D option. Let me know if you need more help Mate
Re: List volume
I think Dan said about 800. I do not think there were 2000 messages today though... Mate
Re: List volume
Once upon a midnight dreary, Mate Wierdl had spoken clearly: >I think Dan said about 800. I do not think there were 2000 >messages today though... The box may do more than just *this* mailing list - there's Dan's other lists, and list.cr.yp.to could just be a DNS entry for his standard mail server (that's the way I have it, so you can expand to a separate box, just change the DNS entry, restart named, and everything's transparent to the user), so there's all that volume as well. So 1.5 million msgs could easily be within mark. Happy Holidaze! Roger "Merch" Merchberger
Re: List volume
On Wed, 23 Dec 1998, Roger Merchberger wrote: > > ObFriends: The reason this whole thing ballooned is because *we all care*. > Hell, if we didn't give a shit about qmail, this thread would have never > happened - everyone would have had the attitude "yea, whatever" and that > would have been the end of it. I agree. The thread occurred because we are qmail fanatics (or at least strong qmail supporters). We care about qmail. We care about Dan. Personally, I'm glad Dan continued to participate in the thread(s). His responses gave insight and at the very least gave us a view of his way of thinking. Happy Holidays, Vern -- ,+'^'+, Vern Hart O Creative Design Engineer - The Hungry Programmers `+,.,+' [EMAIL PROTECTED] http://www.hungry.org 3:12pm up 11 day(s), 5:21, 18 users, load average: 0.12, 0.16, 0.18
Re: List volume
A client of ours sends out their newsletter at a rate of about 40,000/hour. Keep in mind that these are personalized, rather large but fed directly into qmail-queue. That's 960,000 in 24 hours. Dirk On Wed, Dec 23, 1998 at 05:14:58PM -0500, Roger Merchberger wrote: > Once upon a midnight dreary, Mate Wierdl had spoken clearly: > > >I think Dan said about 800. I do not think there were 2000 > >messages today though... > > The box may do more than just *this* mailing list - there's Dan's other > lists, and list.cr.yp.to could just be a DNS entry for his standard mail > server (that's the way I have it, so you can expand to a separate box, just > change the DNS entry, restart named, and everything's transparent to the > user), so there's all that volume as well. > > So 1.5 million msgs could easily be within mark. > > Happy Holidaze! > Roger "Merch" Merchberger >
Re: /var, /opt, /package
How about putting qmail (or at least the binaries) in /opt/local/qmail or /usr/local/qmail? Apache has recently changed to /usr/local/apache for its ServerRoot directory, and I personally like this method. I have recently begun configuring most software I install to use /opt/local (which I have /usr/local/ symlinked to.) --Adam -Original Message- From: D. J. Bernstein <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: Wednesday, December 23, 1998 3:36 PM Subject: /var, /opt, /package :Juan Carlos Castro y Castro writes: :> what's so special about /var? : :/var is universally available, and was almost universally available :three years ago; it usually has lots of space; it is not shared across :NFS. So people can just go ahead with the installation, with no risk of :incorrect file sharing and with minimal risk of installation failure. : :More and more systems are being shipped with /opt, where each package is :expected to have its own directory structure. Unfortunately, /opt is :normally shared among hosts with the same architecture, like /usr; :there's no place for machine-specific package directory structures. : :It's clearly an error for file storage to determine the API. Dozens of :programs, and countless user scripts, broke when /usr/spool/mail moved :to /var/spool/mail. Hundreds of installation scripts broke when /usr/man :moved to /usr/share/man. Sun figured out its mistake by the time it :introduced kernel-specific file sharing---notice the symlink from :/usr/sbin/adb to /usr/kvm/adb---but we're still stuck with / and /usr :and /usr/share. It's particularly depressing that all this complexity is :visible on single-user machines that don't share any files. : :I'd like to see a standard place for package directories, independent of :file storage. The obvious name is /package: e.g., /package/lprng, with :programs in /package/lprng/bin and data in /package/lprng/spool. : :Of course, packages are constantly upgraded, and you shouldn't have to :remove the old version of a package to try out the new version. So :/package/lprng is actually a symlink to /package/lprng-3.7.2. The :upgrade script moves data from lprng/spool to lprng-3.7.2/spool, stops :the old lprng, switches the symlink, and starts the new lprng. : :On systems that share files, the package manager can automatically set :up appropriate symlinks, using some system-specific configuration and a :small amount of sharing information included in the package: : : /package/lprng-3.7.2/src -> /shared/dist/lprng-3.7.2/src : /package/lprng-3.7.2/bin -> /shared/syst/openbsd-i386/lprng-3.7.2/bin : :But the only program that cares about this is the package manager; and :systems without file sharing don't need /shared at all. : :I mentioned this design on the FHS list a couple of years ago, and set :up a mailing list for it (send mail to [EMAIL PROTECTED]), :but not many people were interested. Bummer. : :---Dan :
Re: /var, /opt, /package
On 23-Dec-98 Adam D. McKenna wrote: > How about putting qmail (or at least the binaries) in /opt/local/qmail or > /usr/local/qmail? Apache has recently changed to /usr/local/apache for its > ServerRoot directory, and I personally like this method. I have recently > begun configuring most software I install to use /opt/local (which I have > /usr/local/ symlinked to.) I think he answers that here: >:More and more systems are being shipped with /opt, where each package is >:expected to have its own directory structure. Unfortunately, /opt is >:normally shared among hosts with the same architecture, like /usr; >:there's no place for machine-specific package directory structures. These two are often shared between machines, /var is not. Vince. -- == Vince Vielhaber -- KA8CSH email: [EMAIL PROTECTED] flame-mail: /dev/null # includeTEAM-OS2 Online Searchable Campground Listingshttp://www.camping-usa.com "There is no outfit less entitled to lecture me about bloat than the federal government" -- Tony Snow ==
Re: /var, /opt, /package
On Wed, Dec 23, 1998 at 05:22:22PM -0500, Adam D. McKenna wrote: > How about putting qmail (or at least the binaries) in /opt/local/qmail or > /usr/local/qmail? Apache has recently changed to /usr/local/apache for its > ServerRoot directory, and I personally like this method. I have recently > begun configuring most software I install to use /opt/local (which I have > /usr/local/ symlinked to.) I think there are just too many variations. For example, RedHat puts the Apache config. files in /etc/httpd, even though the stock Apache distribution puts it in /usr/local/etc/apache I think this is what Dan's trying to avoid. I personally don't really care whether it's in /opt, /var, or /usr. I do like the idea of the whole package sitting in the same directory. It guarantees that a year later I won't have little bits and pieces of tihs package lying around if I decide to remove it. Tim
Re: Frivolous forking
audit is important, however as many people have already mentioned, there are tools designed specifically for auditing, and if you really want a secure system, you need to use them anyway. RPM is no substitute. It basically comes down to this: If redhat is as security-conscious as it claims to be (or at least as security-conscious as some people on this list claim it is), they would have found a way to include qmail in their OS. Whether this involved creating a specific set of UID's to use for qmail (which debian does btw), making symlinks, whatever. Spite, in general, is not a good reason to decrease your security. Personally, I feel that if in order to get qmail included in RedHat, it needs to be dumbed down so that Joey Hacker who just got his first Linux CD can install it, and if that dumbing down involves adding more code to qmail, that it's not really worth it. Red Hat stock still has way better security than Win95, even with Sendmail installed. If they want to do even better, they should limit the number of services and SUID root programs that they are installing by default (NFS? imapd? sendmail? abuse??) People on home boxes generally don't need an MTA anyway, they can use their ISP's. And people who aren't beginners will be easily able to install these packages. --Adam -Original Message- From: Sam <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: Wednesday, December 23, 1998 1:02 PM Subject: Re: Frivolous forking :On 23 Dec 1998, Scott Ballantyne wrote: : :> arrangement. The arguments seem to reduce to people saying that they :> either can't use RPM to install qmail or they can't use RPM to do :> security audits, neither of which sound like very strong arguments to :> me. : :That's your viewpoint. For me, the ability to do a security - "integrity" :would actually be a better word - audit is important. : : :
Re: Frivolous forking
Well... I do have to patch install in order to allow a BuildRoot, but that does not go into the actual installed package. You do not need to patch. Build the package with the default config: make make man Then move instcheck and install (I move instcheck to BuildRoot/var/qmail/bin along with config and friends), and change conf-qmail: sed "s}/var/qmail}$RPM_BUILD_ROOT/var/qmail}" conf-qmail > conf-qmail.tmp mv conf-qmail.tmp conf-qmail Now just make install make instcheck ./install ./instcheck Mate
Re: /var, /opt, /package
The major problem here is that there isn't a standard. Or rather, there is, but nobody is using it. Is this because the standard is unsatisfactory? Or just because people are lazy? Or that they don't know about it? (And I am not talking about OS distributors only, I am also talking about people who write their own software and distribute it in source form.) --Adam -Original Message- From: Tim Tsai <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: Wednesday, December 23, 1998 5:32 PM Subject: Re: /var, /opt, /package :On Wed, Dec 23, 1998 at 05:22:22PM -0500, Adam D. McKenna wrote: :> How about putting qmail (or at least the binaries) in /opt/local/qmail or :> /usr/local/qmail? Apache has recently changed to /usr/local/apache for its :> ServerRoot directory, and I personally like this method. I have recently :> begun configuring most software I install to use /opt/local (which I have :> /usr/local/ symlinked to.) : : I think there are just too many variations. For example, RedHat puts :the Apache config. files in /etc/httpd, even though the stock Apache :distribution puts it in /usr/local/etc/apache I think this is what Dan's :trying to avoid. : : I personally don't really care whether it's in /opt, /var, or /usr. :I do like the idea of the whole package sitting in the same directory. :It guarantees that a year later I won't have little bits and pieces of :tihs package lying around if I decide to remove it. : : Tim :
Where to start?
There are no instructions, on how to compile Qmail. I downloaded Qmail 1.03 for linux. Where do I start? I find lot of intructions, HOWTO remove sendmail. How is that useful, without being able to compile Qmail and configure Qmail? Subba Rao [EMAIL PROTECTED] == Disclaimer - I question and speak for myself.
Re: /var, /opt, /package
On Wed, Dec 23, 1998 at 01:21:31PM -0800, Russ Allbery wrote: > Someone was interested enough to write a Usenix paper about it, although I > believe it was independent invention. "SEPP -- Software Installation and > Sharing System" by Tobias Oetiker, Swiss Federal Institute of Technology, > Zurich. Everything is stored in /usr/pack. The focus there is more > towards sharing user executables across multiple machines, rather than > isolating subsystems on a single machine, but it's a very similar idea. > > We do something quite similar for software management in AFS as well. Sorry for off topic (slightly): Already back in 1990 there is a LISA IV paper: The Depot: A Framework for Sharing Software Installation Across Organizational and UNIX Platform Boundaries For those interested it's available e.g. at http://www.leo.org/pub/comp/doc/LISA/lisa4/ \Maex P.S. I'd like to join in and wish you all a peaceful, merry xmas and a happy new year and thank you for everything I've learned from this list.
Re: Where to start?
Unless you got a broken archive from somewhere you must have failed to notice the file called INSTALL in the qmail directory... maybe that will help you out Subba Rao wrote: > > There are no instructions, on how to compile Qmail. > I downloaded Qmail 1.03 for linux. > Where do I start? > > I find lot of intructions, HOWTO remove sendmail. How is that useful, without being > able to compile Qmail and configure Qmail? > > Subba Rao > [EMAIL PROTECTED] > == > Disclaimer - I question and speak for myself. -- |-|---| | Hitesh Patel|[EMAIL PROTECTED] | |-|---| | Network Administrator |_ | | Preferred Communications Inc. | / __ / /__ __/ | | | / /_/ / / / / | | Voice: (541) 759-3126 | / / /__/ /__| | Fax: (541) 759-3214 |/__/ /__/___/| | | | |-|---|
config-fast
I have a private LAN at home, with a private (bogus) domainname. Do I have to use the host+bogusdomainname, for the config-fast? or do I have to use my ISP's domainname? Is there any precaution, that I have to take now, regarding the use of private domainname? TIA. Subba Rao [EMAIL PROTECTED] == Disclaimer - I question and speak for myself.
Re: Where to start?
Subba Rao wrote: > There are no instructions, on how to compile Qmail. > I downloaded Qmail 1.03 for linux. > Where do I start? > > I find lot of intructions, HOWTO remove sendmail. How is that useful, without being > able to compile Qmail and configure Qmail? In addition to the INSTALL file, you may want to read http://metalab.unc.edu/LDP/HOWTO/Mail-HOWTO.html for qmail installation info.
Re: Where to start?
On Wed, 23 Dec 1998, Subba Rao wrote: > There are no instructions, on how to compile Qmail. > I downloaded Qmail 1.03 for linux. > Where do I start? > > I find lot of intructions, HOWTO remove sendmail. How is that useful, without being > able to compile Qmail and configure Qmail? Try the INSTALL file. I think you'll find what you need there. jms
Re: Does one change qmail, or fetchmail?
On Wed, 23 Dec 1998 15:37:28 -0500 (EST), Alan McConnell wrote: > >When fetchmail attempts to deliver mail to my home box, from >my ISP mail-box, qmail won't let it. qmail says: >SMTP listener doesn't like recipient address 'alan@localhost' >(actually that is what fetchmail is telling me that qmail tells it) >This is of course perfectly proper behavior of qmail. > >So I want to put something in my .fetchmailrc that tells fetchmail >to deliver to "@alan17.his.com". I thought that >'localdomains alan17.his.com' in my .fetchmailrc would do it, but >it doesn't show up when I run fetchmail -V. > >So maybe there is a qmail way of fixing this? something in qmail/alias? >or qmail/control? > There's a simple fetchmail fix. I can't see any of my .fetchmailrc's at the moment, but there's a fetchmail variable called "smtphost", or something similar. So you can put smtphost your.host.name in the .fetchmailrc, and it will use that instead of @localhost, in the RCPT TO. This is, of course, for sufficiently new fetchmails. I'm using the latest, 4.7.1. >All suggestions gratefully accepted, and I apologize that this message >is, perhaps, more about fetchmail than about qmail. > >TIA, > >Alan McConnell > >-- >Alan McConnell Linux! The choice of a GNU generation; >Pixel Analysis already at a site near you! > Paul J. Schinder NASA Goddard Space Flight Center Code 693 Greenbelt, MD 20770 [EMAIL PROTECTED]
Re: Does one change qmail, or fetchmail?
According to Paul Schinder: > > >So I want to put something in my .fetchmailrc that tells fetchmail > >to deliver to "@alan17.his.com". I thought that > >'localdomains alan17.his.com' in my .fetchmailrc would do it, but > >it doesn't show up when I run fetchmail -V. > > > >So maybe there is a qmail way of fixing this? something in qmail/alias? > >or qmail/control? > > > > There's a simple fetchmail fix. I can't see any of my .fetchmailrc's at > the moment, but there's a fetchmail variable called "smtphost", or > something similar. So you can put smtphost your.host.name in the > .fetchmailrc, and it will use that instead of @localhost, in the RCPT > TO. > > This is, of course, for sufficiently new fetchmails. I'm using the latest, > 4.7.1. Just tried it, works like a charm! Finally, after a month of wrestling with sendmail's rule-set, and a week of figuring out qmail, I have an operative well-configured E-mail system on my home Linux box. I am tickled pink Many thanks! Alan -- Alan McConnell Linux! The choice of a GNU generation; Pixel Analysis already at a site near you!
Re: fastforward (HELP)
Thanks mr Waskita, I did this [root@smtp bin]# DEFAULT=postmaster HOST=sby.rad.net.id ./fastforward -nd /etc/aliases.cdb from to <[EMAIL PROTECTED]> Dec 23 22:16:31 deni qmail: 914426191.010806 starting delivery 557: msg 195326 to local [EMAIL PROTECTED] Dec 23 22:16:31 deni qmail: 914426191.011079 status: local 1/10 remote 0/20 Dec 23 22:16:31 deni qmail: 914426191.035931 delivery 557: deferral: Home_directory_is_sticky:_user_is_editing_his_.qmail_file._(#4.2.1) -I didn't find any mail in root -but actually i already stop editing some .qmail_file on the ~alias/ -Do I have to make home directories for each oh them ? On Wed, 23 Dec 1998, waskita adijarto wrote: > > On Wed, 23 Dec 1998, Moh. Deny Kurniawan wrote: > > > Date: Wed, 23 Dec 1998 14:33:24 +0700 (WIB) > > From: "Moh. Deny Kurniawan" <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > > Subject: fastforward (HELP) > > > > > > Help Please...fastforward doesn't work. > > > > I already setup q-mail under tcpserver, like this: > > > > 17151 p0 S0:00 /var/qmail/bin/splogger smtpd 3 - > > 17155 p0 S0:00 qmail-lspawn ./Mailbox > > 17154 p0 S0:00 splogger qmail > > 17157 p0 S0:00 qmail-clean > > 17156 p0 S0:00 qmail-rspawn > > 17153 p0 S0:00 qmail-send > > 17150 p0 S0:00 /usr/local/bin/tcpserver -c 100 -v -u 501 -g 502 0 > > smtp /var/qmail/bin/qmail-smtpd > > > > and I already install fastforward, and configure it as mention in the > > manual, like: > > newaliases /etc/aliases become /etc/aliases.cdb and looks like this > > engineer@: > > , &[EMAIL PROTECTED] > > , &[EMAIL PROTECTED] > > ; > > ~alias/.qmail-default looks like this > > |fastforward -d /etc/aliases.cdb > > > > but unfortunatelly it won't work :-( > > help me please > > Thanks. > > you may have configured it, but have you tested your configuration ? > in file ALIASES there are several steps for testing whether fastforward > works or not. > > -wasz- > > > >
Re: The qmail security guarantee
"D. J. Bernstein" <[EMAIL PROTECTED]> writes: | Scott Schwartz writes: | > solution for this problem. | | What problem? The one we've been discussing? I realize that you don't perceive it as a problem; that's obvious from the fact that you don't log any smtp activity at all. I'd respect your opinion a lot more if you actually used recordio in the mode that you advocate for purposes of argument. You don't use recordio for routine logging; that proves that recordio is the wrong tool for the job, not that routine logging is a bad idea. | What exactly do you want to see in the log? All the things we've sent you patches for. | How many times do I have to ask this question before you answer it? I've already explained what I want, if you'll recall. It's obvious that this isn't the question you really have in mind. You want to know if there is internal state in smtpd that cannot be deduced from watching all of it's I/O. If there is none, you will declare recordio a success and disregard the valid objections to it's use. I'm not sure that I agree that there is no hidden internal state, but for the purpose of argument, consider it stipulated. Nonetheless, recordio is wrong: The requirement you are ignoring is the need to *not record* and to *not deduce*. I have no desire to parse recordio's encoding of smtp just to discover discover if any interesting events have occured. Rather, smtpd (which has already done all the necessary parsing) should be quiet (recording only the queue id) unless it has an error to report, in which case it should report only that. recordio is a useful debugging too, like tcpdump, or NFR, but it's not the right design for routine logging.
Flat users file
This is just another newbie question. I have qmail set up so that the mail users are only mail users not real system users, they get their mail via pop. Only problem I have with this is that they are stored in flat files, and lookups can get very slow once you start getting alot of users. Is there something out there that allows for a db lookup?? Joe
Re: The qmail security guarantee
Scott Schwartz writes: > I've already explained what I want, if you'll recall. Sorry, I don't recall. What exactly do you want to see in the log? I have asked you this question far too many times now, Scott, without seeing you answer it. This is your last chance. (Other people are of course free to send me their answers too---I've already received a few suggestions.) ---Dan
What should qmail-smtpd log (was Re: The qmail security guarantee)
FWIW I have qmail-smtpd log the following info: pid, envelope addresses, TCPREMOTEHOST, TCPREMOTEIP and bind-prefix. bind-prefix is simply a token that is passed via the tcpserver invocation so that I can associated the log entry with an interface binding. This is logged at: o any SMTP failure code - temporary or permanent o every rcpt to: o a non-zero exit if it occurs Regards. At 04:00 24/12/98 -, D. J. Bernstein wrote: >Scott Schwartz writes: >> I've already explained what I want, if you'll recall. > >Sorry, I don't recall. What exactly do you want to see in the log? > >I have asked you this question far too many times now, Scott, without >seeing you answer it. This is your last chance. > >(Other people are of course free to send me their answers too---I've >already received a few suggestions.) > >---Dan > >
Re: System integrity verification and other delusions
On 23 Dec 1998, Russell Nelson wrote: > > Probably could. How's about I ask Redhat about distributing a > var-qmail? If they don't have a problem with that, then it's a moot > point, eh? I realize it's a moot point because of the personality conflict between the good folks at Redhat and Dan's ego but I have a question about var-qmail. I finally read http://pobox.com/~djb/qmail/var-qmail.html (I haven't up until this point because I have no need to distribute a qmail package). If I understand it correctly, a var-qmail package is not allowed to enable qmail to send and receive messages. It seems the var-qmail package is allowed to put all the binaries and control files in place but it is not allowed to start qmail. "A user has to follow the instructions in /var/qmail/doc/fastforward/ALIASES and in /var/qmail/doc/INSTALL starting at step 9:" So, does that mean a var-qmail RPM couldn't do those six extra steps FOR the user? If not, how is a user supposed to know what file(s) to read to know what to do next? That seems like a pretty steep restriction to me. Read on: you could make two rpms: one for var-qmail, the other for the initscripts and realted matters. Mate
Re: Why Red Hat is not distributing qmail
Once upon a time, Donnie Barnes Is he the only one making decisions at RH. What kind of freedom did RH have when they *started* distributing Netscape? Mate
Re: Why Red Hat is not distributing qmail
> Is he the only one making decisions at RH. What kind of freedom did RH > have when they *started* distributing Netscape? RedHat has AFAIK changed policy since then. (They used to include other commercial programs in their distribution, but stopped doing so) bt
Re: Why Red Hat is not distributing qmail
On 23 Dec 1998 06:40:20 -, D. J. Bernstein wrote: >I tried to work with Donnie Barnes. I put a lot of effort into making >qmail distributable in binary form. But he isn't willing to guarantee >cross-platform compatibility. It saddens me that he hasn't been honestly >telling his users the nature of our disagreement. RedHat has SECURITY announcements. Often, the problem is that the package is screwed up, not that the source program itself is. Directories have the worng permission, etc. They fix it and the announcement clearly states that it was the _package_ not the _program_. This would not give qmail a bad name. RedHat may well screw it up, but that's [mainly] their problem. RedHat already distribute "non-free" packages, i.e. packages with restrictions above GPL. They do not need to make qmail _the_ redhat MTA, just make it avaialble as an option. What we need is one good and secure rpm. I want maildir, not some stupid mbox spool. RedHat are likely to do the latter for ease of sendmail compatibility. So, I'll keep building qmail on my [redhat linux] system. However, I'd rather the rest of the word used a partially screwed up qmail than sendmail. So, DJB and DB are both 100% correct. A compromise, is worth more than the sum of the merits of both points of view. -Sincerely, Fred (Frederik Lindberg, Infectious Diseases, WashU, St. Louis, MO, USA)
Re: verifying system binaries, a la R*dh*t
It worries me that there is so much discord among the strongest qmail supporters--us on this list. Obviously, you have never been to Israel or Hungary... Watching an Italian movie can also help your worries. Mate
"scientific" relations
It's Dan's attitude. Even after making all the allowances the guy from Redhat wanted, Redhat still didn't want to include qmail. What that says to me is that Dan fundamentally offended someone and that someone couldn't get over it. While I'm not condoning holding personal grudges it says a lot about how Dan interacts with people--not well. Well, RH loses, and pine loses. Unfortunately, this happens big time in history: there is no Nobel prize in mathematics b/c Mittag-Leffler seduced A. Nobel's wife, so we have Field's medal given out every 4 yrs, and pays $5000. Mate
RE: Why Red Hat is not distributing qmail
Well.. One other "related" thing that would need to be updated if you want Maildir mail handling is the modification of the "skeleton" directory/User Add/Del Scripts. If you used qmail w/Maildir, the rpm would need to modify the User Add scipts and skeleton Directory to set up new users properly. It could also be made smart enough to get rid of the /var/mail directory. Same for User Del, it would have to know to not bother with /var/mail Matt Soffen Webmaster - http://www.iso-ne.com/ == Boss- "My boss says we need some eunuch programmers." Dilbert - "I think he means UNIX and I already know UNIX." Boss- "Well, if the company nurse comes by, tell her I said never mind." - Dilbert - == > -- > From: Fred Lindberg[SMTP:[EMAIL PROTECTED]] > Reply To: Fred Lindberg > Sent: Wednesday, December 23, 1998 11:30 AM > To: [EMAIL PROTECTED] > Subject: Re: Why Red Hat is not distributing qmail > > On 23 Dec 1998 06:40:20 -, D. J. Bernstein wrote: > > >I tried to work with Donnie Barnes. I put a lot of effort into making > >qmail distributable in binary form. But he isn't willing to guarantee > >cross-platform compatibility. It saddens me that he hasn't been > honestly > >telling his users the nature of our disagreement. > > RedHat has SECURITY announcements. Often, the problem is that the > package is screwed up, not that the source program itself is. > Directories have the worng permission, etc. They fix it and the > announcement clearly states that it was the _package_ not the > _program_. This would not give qmail a bad name. RedHat may well screw > it up, but that's [mainly] their problem. > > RedHat already distribute "non-free" packages, i.e. packages with > restrictions above GPL. They do not need to make qmail _the_ redhat > MTA, just make it avaialble as an option. > > What we need is one good and secure rpm. I want maildir, not some > stupid mbox spool. RedHat are likely to do the latter for ease of > sendmail compatibility. So, I'll keep building qmail on my [redhat > linux] system. However, I'd rather the rest of the word used a > partially screwed up qmail than sendmail. > > So, DJB and DB are both 100% correct. A compromise, is worth more > than > the sum of the merits of both points of view. > > > > -Sincerely, Fred > > (Frederik Lindberg, Infectious Diseases, WashU, St. Louis, MO, USA) > >
Re: Frivolous forking
On Wed, 23 Dec 1998, Petr Novotny wrote: -| For me install means rpm -ivh qmail*rpm. That's one of a hell of a -| difference. I don't recompile every single thing (hell, I could -| even live without a gcc installed) I install - I just tend to trust -| the PGP signatures, MD5 checksums and RedHat fixing holes ASAP. I've been remaining quiet this whole time about this "qmail/djb vs. redhat" situation, but this one really erked me. SOMEONE has to write the program. SOMEONE has to write the rpm. SOMEONE has to do the work. If we constantly rely on RPM's to do for us the fundamental things of installing, and we get USED to that, we are going experience serious problems in the future. Most people dont even look at an RPM before they install it. They just blindly rpm -i the package - that's almost as bad as running untrusted binaries. So if all you are looking for is pure simplicity of running a system and installing packages, i suggest you all use NT. Hell, i mean that's why i switched over to different unix flavors. The control they gave me. The source. The Makefile. Things i can change, things i can look at. Things i can make sure arent malicious. RPM's are for the most part very evil. I see their purpose for some things: 1. VERY simple packages (which you shouldnt need an RPM form anywayz, since they are simple) 2. VERY complex processes (which you shouldnt use an RPM, since you are going to have to know about the program before you can get any real work done with it. Or otherwise we'll have open relays all over the place, because someone just rpm -i'ed the package WITHOUT reading the docs or without spending any time on the thing like they should or WOULD have to, installing it PROPERLY.) 3. BEGINNERS that just want to get up and running AFAP (which, shouldnt be installing mission critical software on an open internet system that can potentially affect all of us.) 4. This has been proved OVER and OVER again. Redhat systems are not only the most hacked systems (that would be obvious, since most distributions sold are redhat) but they also have the "less educated" level of users. I'd say roughly 90% of all systems hacked are redhat systems. They are shipped vulnerable, and the user never knows enough to upgrade their systems. They get hacked, their upstream pulls the plug, they format/reinstall, and get hacked again, and never figure out what's going on. ___ _ __ _ __ /___ ___ /__ John Gonzalez/Net.Tech __ __ \ __ \ __/_ __ `__ \/ __ /_ ___/ MDC Computers/netMDC! _ / / / `__/ /_ / / / / / / /_/ / / /__ (505)437-7600/fax-437-3052 /_/ /_/\___/\__/ /_/ /_/ /_/\__,_/ \___/ http://www.netmdc.com [-[system info]---] 10:20am up 73 days, 13:59, 4 users, load average: 0.13, 0.13, 0.09
QMail keeps dying
We recently installed QMail on the 4 servers in our server array and have been pretty impressed with on exception. It keeps dying causing us to have to restart it. There doesn't seem to be any pattern as to when it dies, or on which server(s) it dies on. It's all been pretty random. Has anyone else had this type of problem or does anyone have any ideas? Rick
QMail keeps dying
We recently installed QMail on the 4 servers in our server array and have been pretty impressed with on exception. It keeps dying causing us to have to restart it. There doesn't seem to be any pattern as to when it dies, or on which server(s) it dies on. It's all been pretty random. Has anyone else had this type of problem or does anyone have any ideas? Rick
Re: tcpserver start up
Thanks for everyone's help on the tcp server startup. looks like the boot time issue has been solved by makeing sure qmail boots first and smtp is commented out of inetd. Of course snedmail cannot be running...(I still have to remove it, looks like a default install on the IRIX 6.5) Thanks again, Samuel On Mon, 21 Dec 1998, Samuel Dries-Daffner wrote: > > > We have upgraded from IRIX 5.3 to 6.5 and now we have "host" of network > problems :) > > One is getting our tcpserver program running...here's a sample of the > command I am using...which worked until the upgrade. Any suggestions? > > TIA, > > Samuel Daffner > > > ella 67# /usr/local/bin/tcpserver -u91 -g151 0 smtp /usr/local/bin/tcpcontrol >/etc/tcp.smtp.cdb /var/qmail/bin/qmail-smtpd & > [1] 48337 > ella 68# tcpserver: fatal: unable to bind: address already used > > [1]Exit 111 /usr/local/bin/tcpserver -u91 -g151 0 smtp >/usr/local/bin/tcpcontrol ... > > > >
Re: Frivolous forking
John Gonzalez/netMDC admin <[EMAIL PROTECTED]> writes: > > If we constantly rely on RPM's to do for us the fundamental things of > installing, and we get USED to that, we are going experience serious > problems in the future. > I agree with this comment, 100%. Dan has good reasons (and is not alone) in not wanting to use the getpwent stuff. Given that, he's asking what the advantages are to using a config file over the present arrangement. The arguments seem to reduce to people saying that they either can't use RPM to install qmail or they can't use RPM to do security audits, neither of which sound like very strong arguments to me. sdb
Re: Frivolous forking
On Wed, Dec 23, 1998 at 06:05:19PM -, Scott Ballantyne wrote: > John Gonzalez/netMDC admin <[EMAIL PROTECTED]> writes: > > > > If we constantly rely on RPM's to do for us the fundamental things of > > installing, and we get USED to that, we are going experience serious > > problems in the future. > > I agree with this comment, 100%. Dan has good reasons (and is not > alone) in not wanting to use the getpwent stuff. Why should getpw* be needed? There have been suggestions on other methods. This is a comment on one possible implementation of using files to define the qmail uids, and using it as an argument against implementing file-based uids is consistent with djb's dodging the issue that a design choice he has made has a weakness, and he doesn't want to admit it and add flexability at no security cost to qmail. > Given that, he's > asking what the advantages are to using a config file over the present > arrangement. The arguments seem to reduce to people saying that they > either can't use RPM to install qmail or they can't use RPM to do > security audits, neither of which sound like very strong arguments to > me. How about: It's easier for the user. It makes qmail more transparent to the user. It makes qmail easier to reconfigure (didn't you say once that you should always code for flexability?) It lets qmail be installed in stripped-down environments. It allows updates to be distributed for those environments where commercial-ware doesn't allow for distribution of compilers and/or development tools. -Peter
Re: Frivolous forking
You've got some interesting reasoning here... > From: John Gonzalez/netMDC admin <[EMAIL PROTECTED]> > Date: Wed, 23 Dec 1998 10:32:43 -0700 (MST) > > 3. BEGINNERS that just want to get up and running AFAP > (which, shouldnt be installing mission critical software on an > open internet system that can potentially affect all of us.) They're going to do it anyway. Given this, why shouldn't they be able to run as secure of a system as possible? > 4. This has been proved OVER and OVER again. Redhat systems are not only > the most hacked systems (that would be obvious, since most distributions > sold are redhat) but they also have the "less educated" level of users. > I'd say roughly 90% of all systems hacked are redhat systems. They are > shipped vulnerable, and the user never knows enough to upgrade their > systems. They get hacked, their upstream pulls the plug, they > format/reinstall, and get hacked again, and never figure out what's going > on. The entirety of your point 4 follows from the fact that "beginners" are installing systems. They install RedHat because it's easy. It's easy in large part because of RPM. To insist that everybody who runs anything on the Internet read and understand all the source code would be absurd; it's almost as absurd to insist that anybody who puts a Unix box on the net know how to install qmail on day one. So, given this, people are going to run some version of Unix and they're not going to fully understand what they're doing. This version of Unix happens to be RedHat, but if it wasn't RedHat it would be something else. One thing that RPM provides is an easier way to do upgrades. Wouldn't it be better if these "beginners" were automatically notified that there's a security update to their mail program and they should push the stupid little button that corresponds to an "rpm -U qmail*rpm" than to expect them to build the software by hand (and probably forget rcpthosts along the way)? Chris -- Chris Garrigues Deep Eddy Internet Consulting +1 512 432 4046 609 Deep Eddy AvenueO- http://www.DeepEddy.Com/~cwg/ Austin, TX 78703-4513 My email address is an experiment in SPAM elimination. For an explanation of what we're doing, see http://www.DeepEddy.Com/tms.html Nobody ever got fired for buying Microsoft, but they could get fired for relying on Microsoft. PGP signature
RE: QMail keeps dying
What dies?: everything QMail version: 1.03 OS: Solaris 2.6 How I start Qmail: /var/qmail/rc inetd or tcpserver: tcpserver I don't get any error messages or anything that I know of. I haven't found anything in syslog yet about it. I just notice that all of a sudden, QMail and everything associated isn't running. Thanks, Rick > Nope, I've never had this problem. > > You know you're not saying what part of qmail is dying, or what > part(s) is(are) still running. You're not mentioning how you're > setup, what OS, how you're starting qmail, what version of qmail, > whether you're using inetd or tcpserver for your smtp services, etc. > > If you re-posted with any error messages from qmail that happen at the > same time, maybe you'll get a definitive response from folks? > > -Peter >
