Cool Site !!!
I have recieved an e-mail ( subject: to retrieve your emails anytime, anywhere for FREE ) http://thatweb.comit is exactly a site that we are looking for that could get our mails from, with ease . All you need is any computer with internet access, your e-mail address password will do. Armed with these, you will be able to retrieve your e-mail ,compose , send and reply from anywhere. Furthermore , the service is easy to use. No settings of pop3 server, IP address is needed. Try it! It's a great service. Best regards
Username in .qmail
Hi ! I red the following page witch is very interresting. http://qmail-docs.surfdirect.com.au/docs/virtual-hosts.html I created users like .qmail-fred and in it the forward. No problem it works. But does it works with .qmail-fred.davis ? with qmail-fred_davis ? Thank you in advance :-) _ Dimitri SZAJMAN - [EMAIL PROTECTED]
Re: verifying system binaries, a la R*dh*t
On 23-Dec-98 09:29:35, Mark Delany wrote something about "Re: verifying system binaries, a la R*dh*t". I just couldn't help replying to it, thus: 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 often do that, actually. 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 | | It's bad luck to be superstitious. |
Verifying system binaries (Was: Frivolous forking)
On 23-Dec-98 05:20:37, Russ Allbery wrote something about "Re: Frivolous forking". I just couldn't help replying to it, thus: I hope that anyone who intends to do this as part of their security policy uses tripwire rather than relying on RPM. Tripwire is not a package [cut] Which is all great until the tripwire database itself is tampered with. A competent intruder would wipe it out as the first thing (s)he does. It is a darn sight more difficult to hack the MD5 sums on your Redhat Linux CDROM. RPM's verification thing is nice, but I really wouldn't rely on it as a replacement for tripwire. And I would not trust my tripwire database once my system has been compromised. 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 | | Life starts at '030, fun starts at '040, impotence starts at '86.|
Re: Frivolous forking
On 23-Dec-98 18:32:43, John Gonzalez/netMDC admin wrote something about "Re: Frivolous forking". I just couldn't help replying to it, thus: Most people dont even look at an RPM before they install it. Why should I do that when I only install RPM's from people I trust? They just blindly rpm -i the package - that's almost as bad as running untrusted binaries. That's the point: The RPM's I install contain _trusted_ binaries. 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 | |Press Esc to exit. Press Esc twice to save and exit.|
Re: List volume
On 23-Dec-98 23:07:00, Roger Merchberger wrote something about "Re: List volume". I just couldn't help replying to it, thus: Also Dan... Could you (briefly) describe your mailing list machine (or list a URL where that info could be had?) I'd like to know for comparison / gauge to when I may need to upgrade and why. URL:ftp://koobera.math.uic.edu/www/hardware/muncher.html. Notice the "alternative" choice of harddisks. The list was previously running on a less powerful system (URL:ftp://koobera.math.uic.edu/www/hardware/cruncher.html). 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 | | There are no absolutes...that's the absolute truth! |
Re: Frivolous forking
On 23-Dec-98 23:14:10, Adam D. McKenna wrote something about "Re: Frivolous forking". I just couldn't help replying to it, thus: 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. No, that is exactly why they can _not_ include qmail. They are not allowed to distribute modified versions, which means that as security holes are found, they can't fix them and distribute their fixed versions. 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 | | Es funktioniert nicht, sieht aber gut aus. |
Re: extra
On 28-Dec-98 23:00:16, Samuel Dries-Daffner wrote something about "extra "" ". I just couldn't help replying to it, thus: I have a few users who use BSD mail. I have the sendmail wrapper setup so that it invokes qmail which works fine to send messages and also call the aliases in /var/qmail/alias... the problem is that when they use 'r' reply or 'ra' reply to all, that an extra "" gets added to the domain name and causes a bounce. = example of bounced messages [EMAIL PROTECTED]: ^^ Sorry, I couldn't find any host named rmki.kfki.hu. (#5.1.2) ^ | notice this [EMAIL PROTECTED]: ^ ^ Sorry, I couldn't find any host named math.utexas.edu. (#5.1.2) ^ | notice this It is not just at the end. You'll have to fix BSD mail, it's broken. 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 | |Paperweights -- The only way to keep bills down.|
Re: flushing queue
On 28-Dec-98 22:54:49, Samuel Dries-Daffner wrote something about "flushing queue". I just couldn't help replying to it, thus: I have lots of mail that seems stuck in my queue...how can I flush? The first thing to do is, of course, to find out why it is stuck, and fix that problem. Once you've done that, use killall -ALRM qmail-send to tell qmail to try to deliver it now. 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: Frivolous forking
At 01:16 PM 12/29/98 +0100, Rask Ingemann Lambertsen wrote: On 23-Dec-98 23:14:10, Adam D. McKenna wrote something about "Re: Frivolous forking". I just couldn't help replying to it, thus: 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. No, that is exactly why they can _not_ include qmail. They are not allowed to distribute modified versions, which means that as security holes are found, they can't fix them and distribute their fixed versions. Name 1 security hole found in qmail that they would have had to fix. Matt Soffen == 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 - ==
Re: Frivolous forking
Matthew Soffen wrote/schrieb/scribsit: At 01:16 PM 12/29/98 +0100, Rask Ingemann Lambertsen wrote: On 23-Dec-98 23:14:10, Adam D. McKenna wrote something about "Re: Frivolous forking". I just couldn't help replying to it, thus: No, that is exactly why they can _not_ include qmail. They are not allowed to distribute modified versions, which means that as security holes are found, they can't fix them and distribute their fixed versions. Name 1 security hole found in qmail that they would have had to fix. Name one vendor that would fix s.th. they didn't f**k up before. Stefan
Re: flushing queue
On Tue, Dec 29, 1998 at 02:17:57PM +0100, Rask Ingemann Lambertsen wrote: # On 28-Dec-98 22:54:49, Samuel Dries-Daffner wrote something about "flushing queue". I just couldn't help replying to it, thus: # I have lots of mail that seems stuck in my queue...how can I flush? # #The first thing to do is, of course, to find out why it is stuck, and fix # that problem. Once you've done that, use # # killall -ALRM qmail-send assuming they are running Linux under solaris this is: killall(1M) Maintenance Commandskillall(1M) NAME killall - kill all active processes SYNOPSIS /usr/sbin/killall [ signal ] -- /- [EMAIL PROTECTED] --- [EMAIL PROTECTED] -\ |Justin Bell NIC:JB3084| Time and rules are changing. | |Simon Schuster AAT | Attention span is quickening.| |Programmer | Welcome to the Information Age. | \ http://www.superlibrary.com/people/justin/ --/
Re: Verifying system binaries (Was: Frivolous forking)
the Tripwire database is supposed to be mounted read-only as well, either on CD or write-protected floppy. If it is writeable, you have no security. --Adam -Original Message- From: Rask Ingemann Lambertsen [EMAIL PROTECTED] To: Qmail mailing list [EMAIL PROTECTED] Date: Tuesday, December 29, 1998 7:59 AM Subject: Verifying system binaries (Was: Frivolous forking) :On 23-Dec-98 05:20:37, Russ Allbery wrote something about "Re: Frivolous forking". I just couldn't help replying to it, thus: : : I hope that anyone who intends to do this as part of their security policy : uses tripwire rather than relying on RPM. Tripwire is not a package :[cut] : : Which is all great until the tripwire database itself is tampered with. A :competent intruder would wipe it out as the first thing (s)he does. It is a :darn sight more difficult to hack the MD5 sums on your Redhat Linux CDROM. : : RPM's verification thing is nice, but I really wouldn't rely on it as a : replacement for tripwire. : : And I would not trust my tripwire database once my system has been :compromised. : :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 | :| Life starts at '030, fun starts at '040, impotence starts at '86.| : :
Re: Is it my fault??
Andy Cowles writes: Hi There, I have an installation of Qmail that has been working fine with lots of domain names and user accounts... I now have one user who says that they are unable to receive email... they have tried sending themself a message from their AOL account and I get this message in my log maillog file; Dec 29 13:56:35 saturn qmail: 914939795.265747 delivery 57214:deferral: Connected_to_198.81.16.36_but_sender_was_rejected./Remote_host_said:_450_ri [EMAIL PROTECTED]..._Sender_domain_not_found_in_DNS_(see_RFC_11 23,_sections_5.2.2_and_5.2.18)./ Is this something at my end or AOL (or both) what can I do about it?? Hrm. It looks like you already have. You'll get this message if the envelope sender is completely unusable -- that is, if the domain name is not in the DNS. It's perfectly reasonable to reject such mail at the SMTP port because you cannot reliably send a bounce message in the event of non-delivery. I'm VERY surprised that qmail-smtpd doesn't do such a check. Imagine this scenario: o Admin misconfigures his host with a domain name that has no MX, A, or CNAME. o User sends mail to an invalid username at a site running qmail. o qmail-smtpd happily accepts the mail. o qmail tries to deliver the mail; cannot; generates bounce message to sender. o Bounce message bounces because sender domain not in DNS. o email has been misdelivered to unrelated third party. o This is a total privacy breach, an email disaster. -- -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: Redhat qmail
Russell Nelson [EMAIL PROTECTED] wrote: judgement-callBasically, Dan has hacked off Donnie Barnes one too many times. He has some technical issues, such as the difficulty of moving a qmail queue from one machine to another, and that qmail doesn't log enough to make configuration problems obvious. But mostly he doesn't want to deal with Dan's personality, to the point that he thinks that nobody will believe anything negative Dan says about Redhat./judgement-call Likewise, Donnie has hacked off Dan one too many times. I don't know Donnie, but what I've seen of Red Hat Linux doesn't overly impress me. On the other hand, I find Dan's work very impressive. Not perfect, by any means, but far more intelligent, coherent, and robust than anything Red Hat has produced. That happens far too often, Dan. Dozens of people feel the same way as Donnie. To win an argument and lose a friend doesn't scale. Friends are finite in number; disagreements are not. It should be obvious to all by now that Dan's not trying to win a popularity contest. He's doing things his way, and people who like the way he does things are welcome to share the fruits of his labor. Can't we all just agree that qmail (and the DJBist philosophy) aren't for everyone, and that trying to change that is very unlikely to succeed but sure to annoy almost everyone here? Since Redhat doesn't care anymore, and there's no longer a possibility of Redhat shipping qmail, there's no point in arguing the UID in binaries problem. Agreed. -Dave
Re: Redhat qmail
On Tue, Dec 29, 1998 at 10:50:37AM -0500, Dave Sill wrote: Likewise, Donnie has hacked off Dan one too many times. I don't know Donnie, Donnie is the most abrasive member of the redhat team. He deals with people in about the same way that Dan does. I would have supposed that they were a match made in heaven. but what I've seen of Red Hat Linux doesn't overly impress me. ObCuriousity: Relative to what? IMO redhat, debian, freebsd, etc are all pretty much neck-and-neck for installation, redhat and debian are way ahead for upgrading, and no commercial unix vendor comes close to any of these groups for maintenance. Where do you see them falling down? On the other hand, I find Dan's work very impressive. Not perfect, by any means, but far more intelligent, coherent, and robust than anything Red Hat has produced. He's also producing a small set of utilities that interact with each other (doing it very well, too - no disagreement there). Comparing the scope and complexity of Dan's projects to an OS vendors mission is apples and oranges. -Peter
Re: Frivolous forking
On Tue, Dec 29, 1998 at 08:44:00AM -0500, Matthew Soffen wrote: Name 1 security hole found in qmail that they would have had to fix. Do you use ulimit before running your qmail-smtpd? One place to fix this security hole is in qmail-smtpd. Though Dan doesn't think it should be fixed in qmail itself, it reasonably could be. Anyway, keep in mind that just because it hasn't broken yet doesn't mean it can't break. Thinking that way is unwise. Just because qmail hasn't been broken *yet* doesn't mean that anyone is willing to stick their neck out and claim that it can't be broken. A group (I among them) have ponied up cash because there doesn't seem to be a way to do it. Money isn't a conclusive proof that it can't happen. It's just paper, it can't do a proof. Also note that Dan's standing offer of $1k doesn't cover stupid holes in the OS qmail's running on. If such an OS bug turned up, I hope that someone would write a work-around for qmail. But since there's always a chance that something unforseen will break, why strutt around pretending otherwise? -Peter
Re: Username in .qmail
On Tue, Dec 29, 1998 at 09:49:16AM +0100, Dimitri SZAJMAN wrote: I red the following page witch is very interresting. http://qmail-docs.surfdirect.com.au/docs/virtual-hosts.html I created users like .qmail-fred and in it the forward. No problem it works. But does it works with .qmail-fred.davis ? with qmail-fred_davis ? To send mail to fred.davies@virtual-host you have to replace the "." by ":". If you have an existing .qmail-fred and this is the same user as "fred.davies" and "fred_davies" a $ ln .qmail-fred .qmail-fred:davies $ ln .qmail-fred .qmail-fred_davies is probably the best. \Maex -- SpaceNet GmbH | http://www.Space.Net/ | In a world without Research Development| mailto:[EMAIL PROTECTED] | walls and fences, Joseph-Dollinger-Bogen 14 | Tel: +49 (89) 32356-0| who needs D-80807 Muenchen | Fax: +49 (89) 32356-299 | Windows and Gates?
Re: Frivolous forking
From: Matthew Soffen [EMAIL PROTECTED] : No, that is exactly why they can _not_ include qmail. They are not allowed :to distribute modified versions, which means that as security holes are :found, they can't fix them and distribute their fixed versions. : :Name 1 security hole found in qmail that they would have had to fix. This isn't the point. It is possible that a security hole could be found in qmail. (highly doubtful, but possible). However, if that happened, I wouldn't want Redhat touching the source anyway. --Adam
Re: Frivolous forking
On 29-Dec-98 Peter C. Norton wrote: On Tue, Dec 29, 1998 at 08:44:00AM -0500, Matthew Soffen wrote: Name 1 security hole found in qmail that they would have had to fix. Do you use ulimit before running your qmail-smtpd? One place to fix this security hole is in qmail-smtpd. Though Dan doesn't think it should be fixed in qmail itself, it reasonably could be. FreeBSD uses login classes to handle this, but prior to that I used limit. I agree with Dan that it's an OS thing whether it can be handled in the app or not. Vince. -- == Vince Vielhaber -- KA8CSH email: [EMAIL PROTECTED] flame-mail: /dev/null # include std/disclaimers.h TEAM-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: Frivolous forking
Thats exactly my point. If there were a "REAL" security hole found in qmail, DJB would immediately want to fix it right. He would not want a "quick" fix as the OS venders may do. 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: Adam D. McKenna[SMTP:[EMAIL PROTECTED]] Sent: Tuesday, December 29, 1998 12:22 PM To: Qmail mailing list Subject: Re: Frivolous forking From: Matthew Soffen [EMAIL PROTECTED] : No, that is exactly why they can _not_ include qmail. They are not allowed :to distribute modified versions, which means that as security holes are :found, they can't fix them and distribute their fixed versions. : :Name 1 security hole found in qmail that they would have had to fix. This isn't the point. It is possible that a security hole could be found in qmail. (highly doubtful, but possible). However, if that happened, I wouldn't want Redhat touching the source anyway. --Adam
RE: Frivolous forking
But would you really want RedHat fixing qmail instead of DJB ? If security holes were found (REAL security holes), DJB would be the 1st to want them fixed right, not a quick fix as an os vender/redhat would do. 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: Rask Ingemann Lambertsen[SMTP:[EMAIL PROTECTED]] Sent: Tuesday, December 29, 1998 12:28 PM To: Qmail mailing list Subject: Re: Frivolous forking On 29-Dec-98 14:44:00, Matthew Soffen wrote something about "Re: Frivolous forking". I just couldn't help replying to it, thus: At 01:16 PM 12/29/98 +0100, Rask Ingemann Lambertsen wrote: No, that is exactly why they can _not_ include qmail. They are not allowed to distribute modified versions, which means that as security holes are ^ found, they can't fix them and distribute their fixed versions. ^ Name 1 security hole found in qmail that they would have had to fix. 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 | | Do artificial plants need artificial water? |
Re: Frivolous forking
On Tue, Dec 29, 1998 at 12:23:57PM -0500, Vince Vielhaber wrote: FreeBSD uses login classes to handle this, but prior to that I used limit. I agree with Dan that it's an OS thing whether it can be handled in the app or not. FreeBSD *can* use login classes to handle this. I don't see any references to any capabilities in the qmail section of of /usr/ports for freebsd 2.2.7. The cget*() family seems to be specific to later bsd's. Maybe just freebsd? The man pages I have don't tell me much about the taxanomy of this system. As you say, freebsd does have the setrlimit(), as does every other modern *nix. -Peter
Re: Frivolous forking
On Tue, Dec 29, 1998 at 12:35:30PM -0500, Soffen, Matthew wrote: But would you really want RedHat fixing qmail instead of DJB ? If security holes were found (REAL security holes), DJB would be the 1st to want them fixed right, not a quick fix as an os vender/redhat would do. Again, this is just your opinion. As is the idea of a "REAL" security hole. Should a security hole ever be discovered in qmail, it would be subject to Dan's schedule. make-believe If dan is on sabbatical in Malaysia in the middle of the 2 month Malaysian internet blackout of 1999, and he's hiking in the mountains anyway, and a "REAL" qmail security hole is found, where does that leave the hypothetical* vendor or OEM that's shipping qmail? /make-believe * hypothetical because I can't name a company that is doing so - Dan has claimed on the list that such a thing exists, but I haven't seen any reference to a company name, or how they're planning on maintaining qmail. -Peter
Re: Frivolous forking
On 29-Dec-98 Peter C. Norton wrote: On Tue, Dec 29, 1998 at 12:35:30PM -0500, Soffen, Matthew wrote: But would you really want RedHat fixing qmail instead of DJB ? If security holes were found (REAL security holes), DJB would be the 1st to want them fixed right, not a quick fix as an os vender/redhat would do. Again, this is just your opinion. As is the idea of a "REAL" security hole. Should a security hole ever be discovered in qmail, it would be subject to Dan's schedule. make-believe If dan is on sabbatical in Malaysia in the middle of the 2 month Malaysian internet blackout of 1999, and he's hiking in the mountains anyway, and a "REAL" qmail security hole is found, where does that leave the hypothetical* vendor or OEM that's shipping qmail? /make-believe In this case, someone from this list would no doubt also come up with a patch. So who would you rather have fix it, redhat or someone like one of the Russes, Sam, Fred, ... ? Vince. -- == Vince Vielhaber -- KA8CSH email: [EMAIL PROTECTED] flame-mail: /dev/null # include std/disclaimers.h TEAM-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 ==
Support for DSN
Are there plans to support Delivery Status Notifications (RFC 1891- 1894) in future versions of qmail? qreceipt is very poor... -Andrzej
Re: QMail keeps dying
On Tue, 29 Dec 1998, Rick McMillin wrote: We are having a big problem. We have an array of three servers with QMail running on each server. The problem is that QMail keeps dying. There doesn't seem to be a pattern to this or anything. We are running Solaris 2.6. We're running QMail 1.03 using Maildir format with Tcpserver being used also. Please be more specific. What exactly happens when you say "qmail is dying"? Is anything showing up in the logs? Please tell us more about your configuration. jms
.qmail and looping and bouncing
Hello all, I have a question about the forwarding mechanism used by qmail. I have looked through the documentation, manpages, and searched the mailing list archives without finding an adequate answer. I am running qmail in the default manner described in the documentation (read: no hairy configurations, all the defaults). As such, we are using mbox format in $HOME/Mailbox mailboxes and all remnants of sendmail and /bin/mail are gone. I have the same home directory on several machines, but I want mail sent to me at any of the machines which share the same home directory to be sent to a single machine (which also has that same home directory). With sendmail I simply put a .forward file in my single home directory with the address I wanted all my mail sent to (again, the address was to me at a machine on which I had this same home directory). Once mail arrived at the desired machine, sendmail would recognize that the .forward file contained the same address that just received the mail and not re-forward to the same address multiple times, but simply terminate the delivery at the address in .forward. qmail, on the other hand, forwards the mail to the address in .qmail. When this forwarded mail arrives, qmail sees the same .qmail file and therefore same address and recognizes that the forwarding address is already listed in the Delivered-To: field and rather than terminate the delivery at that address, it bounces the message. I realize that since I have moved my mbox to $HOME/Mailbox, this is not really a big problem, since I can get rid of the .qmail file and all the mail will still end up in $HOME/Mailbox. But given that my $HOME is nfs mounted on all but one of the machines, I would like to avoid the troubles with nfs and have all the other machines forward, while the local machine delivers. (Unless I can be assured qmail will not lose my mail even though my mailbox is on an nfs). Any stable solutions would be much appreciated. As a side note, the real problem occurs when the same address in my .qmail file appears in the ~alias/.qmail-root (.qmail-postmaster and .qmail-mailer-daemon forward to root). If I send a test message to myself, it tries to deliver it, forwards it, sees the Delivered-To:, bounces it back to me, tries to forward it, sees the Delivered-To:, double bounces to postmaster, which gets forwards to root, which forwards to me, which attempts to forward, can't and can't bounce! As far as I can tell, this causes the message to be lost (if anyone knows a way to recover such a message, I would appreciate it). Thank you for your time. DAVID. ~~ David J. Dooling[EMAIL PROTECTED] Dept. of Chemical Engineering phone 847 467-1402 Northwestern University fax 847 491-3728 http://winnie.chem-eng.nwu.edu/students/dooling.html
Re: QMail keeps dying
On Tue, Dec 29, 1998 at 11:55:10AM -0600, Rick McMillin wrote: There are times when this happen 3 times a night and then it may not happen again for a week or so. It's all pretty random. Does anyone have any ideas? What was your $PATH when you compiled qmail? Have you tried building w/o /usr/ucb in it? Better yet, move /usr/ucb/ld to something else like /usr/ucb/broken.ld. See if building w/o that does anything for you. -Peter
Re: Redhat qmail
On Tue, 29 Dec 1998, Peter C. Norton wrote: -| He's also producing a small set of utilities that interact with each -| other (doing it very well, too - no disagreement there). Comparing -| the scope and complexity of Dan's projects to an OS vendors mission is -| apples and oranges. Well. Have you visited his site yet? Have you seen the AMOUNT of tools that he creates? He doesnt just make software that interacts with "each other" he makes ALL kinds of software that will work on almost any unix system, that work with countless other utilities.. (tcpserver springs, to mind) and has to program for tons of other OS's. He's also pretty much a 1 man team, whereas redhat is a whole company. Your right, it's like comparing apples to oranges - but DJB does deserve the respect that he gets. Oh, i fergot to mention. Redhat makes money, DJB does not. ___ _ __ _ __ /___ ___ /__ John Gonzalez/Net.Tech __ __ \ __ \ __/_ __ `__ \/ __ /_ ___/ MDC Computers/netMDC! _ / / / `__/ /_ / / / / / / /_/ / / /__ (505)437-7600/fax-437-3052 /_/ /_/\___/\__/ /_/ /_/ /_/\__,_/ \___/ http://www.netmdc.com [-[system info]---] 11:10am up 79 days, 14:49, 3 users, load average: 0.05, 0.11, 0.09
Re: Frivolous forking
On Tue, Dec 29, 1998 at 12:28:59PM -0500, Soffen, Matthew wrote: I wasn't referring to OS Security Holes. I was referring to "true" qmail holes. I am too. I'm just adding what I believe is relevant information to the realm of "qmail and security." If there were a real hole shown, I belive the DJB would fix it quickly (and not just a quick fix as I think redhat would do). I do too, but who are you or I to speak for the man? -Peter
Re: Frivolous forking
On 29-Dec-98 Peter C. Norton wrote: On Tue, Dec 29, 1998 at 12:23:57PM -0500, Vince Vielhaber wrote: FreeBSD uses login classes to handle this, but prior to that I used limit. I agree with Dan that it's an OS thing whether it can be handled in the app or not. FreeBSD *can* use login classes to handle this. I don't see any references to any capabilities in the qmail section of of /usr/ports for freebsd 2.2.7. I should clarify, I do not depend on ports, packages, or anything else like that for mission critical applications. About all I use the ports for is to tell me where to find the most recent version of something. Correction, I did get lazy the other day and used ports for wmcdplay, but that wasn't on a mission critical machine anyway. Vince. -- == Vince Vielhaber -- KA8CSH email: [EMAIL PROTECTED] flame-mail: /dev/null # include std/disclaimers.h TEAM-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: Queueing remote deliveries at specific intervals (ala sendmail -q)?
On Tue, 29 Dec 1998, [ISO-8859-1] Robin Smidsrød wrote: -| -| I guess the subject says it all? -| -| How is it possible to enforce a "sendmail -q" specific behaviour in qmail? -| I'm using it in a dial-on-demand system, and I want to be able to flush the -| remote mail queue at specific intervals. -| -| Anybody'd care to enlighten me? Send an -ALRM signal to qmail-send and it will re-try the queue. ___ _ __ _ __ /___ ___ /__ John Gonzalez/Net.Tech __ __ \ __ \ __/_ __ `__ \/ __ /_ ___/ MDC Computers/netMDC! _ / / / `__/ /_ / / / / / / /_/ / / /__ (505)437-7600/fax-437-3052 /_/ /_/\___/\__/ /_/ /_/ /_/\__,_/ \___/ http://www.netmdc.com [-[system info]---] 12:05pm up 79 days, 15:44, 3 users, load average: 0.01, 0.04, 0.06
Re: .qmail and looping and bouncing
David J. Dooling writes: | Once mail arrived at the desired machine, sendmail would recognize that the .forward file contained the same address that just received the mail and not re-forward to the same address multiple times, but simply terminate the delivery at the address in .forward. Something like this ought to do it: |condredirect $USER@canonicalhost test ! `hostname` == canonicalhost ./Mailbox -- -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: Redhat qmail
"Peter C. Norton" [EMAIL PROTECTED] wrote: On Tue, Dec 29, 1998 at 10:50:37AM -0500, Dave Sill wrote: but what I've seen of Red Hat Linux doesn't overly impress me. ObCuriousity: Relative to what? IMO redhat, debian, freebsd, etc are all pretty much neck-and-neck for installation, redhat and debian are way ahead for upgrading, and no commercial unix vendor comes close to any of these groups for maintenance. Where do you see them falling down? Relative to high quality packages like name your favorite djbware or, from what I've heard and read, OpenBSD. I have no first-hand experience with Debian or FreeBSD, but I do play with Red Hat LINUX at work and at home. The quality of the *package*--not to be confused with the quality of the components--leaves a lot to be desired. They seem to be more concerned with incorporating the "latest and greatest" versions of everything than with producing a well-integrated, sanely configured package. E.g., many unnecessary network services are installed by default, and with less than prudent configurations. On the other hand, I find Dan's work very impressive. Not perfect, by any means, but far more intelligent, coherent, and robust than anything Red Hat has produced. He's also producing a small set of utilities that interact with each other (doing it very well, too - no disagreement there). Comparing the scope and complexity of Dan's projects to an OS vendors mission is apples and oranges. Agreed. Writing an SMTP server from scratch and assembling off-the-shelf freeware components into an operating system are very different tasks. Developing qmail is a one-man, part-time, not-for-profit programming job. Producing Red Hat LINUX is a commercial team packaging effort. But I'm not comparing qmail and RHL head-to-head, I'm considering the personal efforts of Dan Bernstein and Donnie Barnes. From what I've seen, Dan produces the higher quality product by far. -Dave
Re: Why Red Hat is not distributing qmail
Russell Nelson [EMAIL PROTECTED] wrote: The basic problem is that [Dan doesn't] trust Redhat. Good for him! He'd be a fool to trust them. There's no basis for trust between them. If [he] trusted them, then [he] would give them the freedom to distribute modified binaries. If pigs had wings... Redhat is returning that distrust. Good for them! (See above.) Not only that, but Donnie is so confident that [Dan has] sufficiently marginalized [him]self that he isn't going to bother to dispute [him]. I don't think thats it, really. I think Donnie/Red Hat are simply not sufficiently motivated to include qmail in RHL. I suspect their reasoning goes something like this: Sendmail is *the* UNIX mailer. Everyone knows how to work it. It's well documented, well proven, and hopefully most of the major bugs have been found. We can tweak the source any way we see fit. Not many (paying) customers are complaining about it. Sure, qmail is better, but when we compare the benefits to the costs, it doesn't make economic sense to switch. -Dave
Re: Cool Site !!!
Sorry for posting this back to the list... Other companies have been doing this for years...this is not new! Cheers!, Matthew Landry Design Trust Inc Systems Developer150 Danbury Rd. Network AdministratorWilton Ct. 06897 mailto:[EMAIL PROTECTED] phone: (203)-761-1412 http://www.destru.comfax: (203)-761-1419 On Tue, 29 Dec 1998 [EMAIL PROTECTED] wrote: I have recieved an e-mail ( subject: to retrieve your emails anytime, anywhere for FREE ) http://thatweb.comit is exactly a site that we are looking for that could get our mails from, with ease . All you need is any computer with internet access, your e-mail address password will do. Armed with these, you will be able to retrieve your e-mail ,compose , send and reply from anywhere. Furthermore , the service is easy to use. No settings of pop3 server, IP address is needed. Try it! It's a great service. Best regards
RE: IIS 4.0 SMTPSVC vs. QMAIL
Nelson Bunker writes: The Error happened again with .XXX last night... I had to delete the piece of mail again. Our establishment has started to use IIS4.0 option pack SMTP service (post SP4) for our outgoing mail. We have had several complaints regarding an issue with trying to send mail destined for servers running "Qmail". It appears that the Qmail shuts down the connection with out giving an error message. Doen't appear to be a qmail problem, since Nelson was able to send me mail. -- -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: Why Red Hat is not distributing qmail
Bill Parker [EMAIL PROTECTED] Dave Sill wrote: Sendmail is *the* UNIX mailer. Everyone knows how to work it. It's well documented, well proven, and hopefully most of the major bugs have been found. We can tweak the source any way we see fit. Not many (paying) customers are complaining about it. Sure, qmail is better, but when we compare the benefits to the costs, it doesn't make economic sense to switch. Ahem! if you are installing a system from scratch (as i did about 5 months ago) and you read horror stories about what a pain it is to admin sendmail, it makes perfectly good sense to install what you want when you are loading the operating system..:) In my case, i installed Qmail v1.03 and never have looked back (except for a few small problems, etc).. Of course I agree completely. I was merely guessing at Red Hat's reasons for not switching to qmail. Remember, Red Hat is a big bux commercial operation (see recent news reports of substantial investment in Red Hat by Intel). They don't produce Open Source Software because they're nice guys and it makes them feel good to give away their wonderful operating system. They're in the business to make money. They do it by selling shrink wrapped RHL, support services, and various LINUX add-ons. To a certain extent, the quality of the components of RHL can affect their bottom line: quality is something that some customers are willing to pay for. But, as Microsoft, Netscape, and Red Hat's own experience has amply demonstrated, the public is all too eager to accept buggy, unreliable software. Clearly, quality isn't the only criterion--or even all that important a criterion--to the average customer. If Red Hat was a bunch of geeks dedicated to furthering the hacker ethic, replacing sendmail with qmail or even postfix or exim would be a no-brainer. They'd evaluate the choices, pick a winner, and do whatever it would take to implement the switch. But Red Hat is more like a bunch of executives dedicated to growing the business and raising profits. Their techies might argue for replacing sendmail on the grounds that it would improve the quality of their product and hopefully avoid some negative publicity the next time sendmail is hacked, but that's not enough to justify the switch. The executives will want to be sure that the costs of switching are lower than the benefits of switching--otherwise they'll lose some of their precious growth or profits. So what are the costs to Red Hat of switching from sendmail to another MTA? Here are a few: o they have to select an alternative o they have to test the alternative on a variety of platforms in a variety of situations o they have to incorporate the alternative into the next release o they have to change various documentation o they have to support their sendmail customers in the migration There are also risks: o what if users don't want to switch? o what if the replacement has problems? I'm sure there are others, but you get the idea. From Red Hat's point of view, the inertia behind sendmail is substantial and the mere availability of a superior alternative isn't compelling enough to make them switch. -Dave
Re: Why Red Hat is not distributing qmail
On Tue, Dec 29, 1998 at 04:12:27PM -0500, Dave Sill wrote:
Remember, Red Hat is a big bux commercial operation (see recent news
reports of substantial investment in Red Hat by Intel). They don't
produce Open Source Software because they're nice guys and it makes
them feel good to give away their wonderful operating system.
Only part right. Those I've talked to at redhat say that they give
their work back to the community, and for free, because they believe
it's a valid business model, but also because it makes them feel good.
They were and are bucking the pointy-haired trend in the computer
world. A big part of it is because what they're doing makes them feel
good.
They're
in the business to make money. They do it by selling shrink wrapped
RHL, support services, and various LINUX add-ons.
That too. But they do more of the "because it makes us feel good"
kind of thing then anyone else I know in the community (OSS, Free
Software, what have you. Even RMS likes them). That's partly becaue
their business gives them the revenue that lets them support the stuff
that lets them feel good. It's not exactly cut-n-dried.
If Red Hat was a bunch of geeks dedicated to furthering the hacker
ethic, replacing sendmail with qmail or even postfix or exim would be
a no-brainer. They'd evaluate the choices, pick a winner, and do
whatever it would take to implement the switch.
I disagree. The choices are more then technical, because Dan makes it
so. View debian linux, or stampede linux - they are what you
describe, as I believe the freebsd and openbsd core teams are. To my
knowledge none of these essentially hacker systems, or redhat's
hack-branch ("rawhide") have any option for qmail to be installed by
default. Obviously something besides technical considerations come
into play. Maybe something about qmail conflicts with the ethic of a
sizeable percentage of hackers?
But Red Hat is more like a bunch of executives dedicated to growing
the business and raising profits. Their techies might argue for
replacing sendmail on the grounds that it would improve the quality of
their product and hopefully avoid some negative publicity the next
time sendmail is hacked, but that's not enough to justify the
switch.
AFAIK this was a group decision. Ask them yourself next time you see
them at a trade show. They made up their mind at least 2 years ago,
and it seemed to be a unanimous decision throughout the group of about
10 geeks that ran the technical side at the time. Never mind that
redhat uses qmail for all of their list systems...
The executives will want to be sure that the costs of
switching are lower than the benefits of switching--otherwise they'll
lose some of their precious growth or profits.
I disagree again. If it was viable for them to offer qmail as a
replacement beyond the technical considerations (and Dan has gone to
alot of trouble so that there aren't any technical considerations in
the simplest cases) then they would. So what else is there?
[deletia]
I'm soundly opposed to the picture you paint of linux or other free
OS' being monolithic inflexible distributions. Options can be
offered, and are at install time. Because your opinions seem to rest
on that assumption I won't address your points, which are mostly valid
but aren't stated in a way that allows them to mate with the situation
as I understand it. If your POV (as I read it) that the motivating
reason redhat doesn't do this is because they're a pointy-haired
business was at all accurate then all non-pointy-haired OS
distributions should have qmail, right? Well, where is qmail? I see
wu-ftpd being replaced by proftpd in places, I see apache installed
instead of CERN or NCSA httpd, I see gnu utilities instead of BSD
utils, or where appropriate BSD utils instead of GNU utils, I see
network code getting tightened up, kernels being scrutinized, but I
don't see qmail anywhere.
What's the answer?
I'm sure there are others, but you get the idea. From Red Hat's point
of view, the inertia behind sendmail is substantial and the mere
availability of a superior alternative isn't compelling enough to make
them switch.
Then why haven't any of the other many free operating system
distributions moved towards qmail?
-Peter
Re: Why Red Hat is not distributing qmail
On Tue, Dec 29, 1998 at 04:25:55PM -0500, Sam wrote: Not when they have a functional MTA available, that doesn't come with any strings attached, that quietly installs itself, non-relaying out of the box, and will even do certain things that Qmail cannot do, such as reject non-resolvable envelope sender addresses, reject delivery attempts to non-existent local users, and support RBL lookups with a single configuration switch. There's absolutely no reason for Red Hat to switch to Qmail, so let's just stop beating a dead horse. qmail doesn't reject delivery attempts to nonexistant local users?? I guess this is true if you have a .qmail-default in ~alias, but otherwise the message will bounce, no? --Adam
Re: Frivolous forking
On 29-Dec-98 18:35:30, Soffen, Matthew wrote something about "RE: Frivolous forking". I just couldn't help replying to it, thus: But would you really want RedHat fixing qmail instead of DJB ? I would definitely want RedHat to be in a position to release a fixed version, even if the fix should turn out to be only a stop-gap measure. Once a fixed version arrives from the author, I'd install that. If security holes were found (REAL security holes), DJB would be the 1st to want them fixed right, not a quick fix as an os vender/redhat would do. I am not questioning DJB's intentions here - of course he would do his best to fix a security hole, but what if he happens to be incapacitated (sp?) at just the wrong time, e.g. runs out in front of a bus? Should RedHat then just sit there, twiddling their thumbs, saying "Sorry, we have a fix ready, but we're not allowed to give it to you" to their customers, while waiting for Dan to recover? One solution would be for Dan ro allow RedHat to make only modifications that fix security holes. This means Dan would have to trust RedHat not to abuse this right. 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 | | I'm as confused as a baby at a topless bar! |
Re: Why Red Hat is not distributing qmail
On 29-Dec-98 22:30:41, Adam D. McKenna wrote something about "Re: Why Red Hat is not distributing qmail". I just couldn't help replying to it, thus: On Tue, Dec 29, 1998 at 04:25:55PM -0500, Sam wrote: [sendmail] box, and will even do certain things that Qmail cannot do, such as reject non-resolvable envelope sender addresses, reject delivery attempts to non-existent local users, and support RBL lookups with a single qmail doesn't reject delivery attempts to nonexistant local users?? No, in fact it doesn't. I guess this is true if you have a .qmail-default in ~alias, Doesn't make a difference. but otherwise the message will bounce, no? Yes, the message will bounce if it cannot be delivered. 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 | | Which is worse: Ignorance or apathy? Who knows... Who cares...|
Re: /var, /opt, /package
On 23 Dec 1998, D. J. Bernstein wrote: ... 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 have researched a number of tools to manage these symlinks: depot stow encap All of them had good ideas but I felt they also had their shortcomings. So I wrote my own which I've called graft. I requires perl5 and I've been successfully using it at a number of sites for a couple of years now: ftp://ftp.uniq.com.au/pub/tools/graft The philosophy is simple: Install the package in /pkgs/package-vers. Where /pkgs is some directory of your choosing. The default location is hard coded into the graft executable but can be overridden on the command line. pacakge-vers is a unique name describing the package name and version number. eg gcc-2.7.2.1, ghostscript-5.50, ucspi-tcp-0.84. Each package has its own bin, lib, include, etc, ... directories. If the package needs to refer to its own control/library files, it should be built such that is refers to them as /pkgs/package-vers/lib/file instead of /usr/local/lib/file. THis is usually easy for autoconf style programs which can be built using ./configure --prefix=/pkgs/package-vers The just graft the package into YOUR standard location which might be /usr/local or /opt/local or /pkgs or whatever. The default is hard coded into the graft executable but may be overriden on the command line graft -i gcc-2.7.2.1 This will create symlinks such as /usr/local/bin/gcc - /pkgs/gcc-2.7.2.1/bin/gcc . There are mechanisms to avoid grafting branches that are not necessary - there's no need to graft /pkgs/perl-5.0002/lib for example. There are also mecahnisms for avoiding the grafting of specific files. Read the doco for more details. Regards Peter -- Peter Samuel[EMAIL PROTECTED] Technical Consultantor at present: Uniq Professional Services [EMAIL PROTECTED] Phone: +61 2 9206 3410 Fax: +61 2 9281 1301 "If you kill all your unhappy customers, you'll only have happy ones left"
