qmail Digest 19 May 1999 10:00:01 -0000 Issue 645
Topics (messages 25701 through 25779):
Mass migration off of qmail because of lack of DSNs?
25701 by: John Conover <[EMAIL PROTECTED]>
25709 by: Tasos Kotsikonas <[EMAIL PROTECTED]>
25710 by: "Chris Garrigues" <[EMAIL PROTECTED]>
25711 by: Van Liedekerke Franky <[EMAIL PROTECTED]>
25712 by: [EMAIL PROTECTED]
25713 by: [EMAIL PROTECTED]
25715 by: Russell Nelson <[EMAIL PROTECTED]>
25716 by: [EMAIL PROTECTED]
25718 by: Russell Nelson <[EMAIL PROTECTED]>
25720 by: Dave Sill <[EMAIL PROTECTED]>
25721 by: Bruno Wolff III <[EMAIL PROTECTED]>
25728 by: Jeff Hayward <[EMAIL PROTECTED]>
25731 by: "Sam" <[EMAIL PROTECTED]>
25735 by: "Sam" <[EMAIL PROTECTED]>
25738 by: Dave Sill <[EMAIL PROTECTED]>
25741 by: Kai MacTane <[EMAIL PROTECTED]>
25748 by: Arnt Gulbrandsen <[EMAIL PROTECTED]>
25749 by: [EMAIL PROTECTED]
25750 by: Vince Vielhaber <[EMAIL PROTECTED]>
25753 by: "Fred Lindberg" <[EMAIL PROTECTED]>
qmail installation
25702 by: Javed Ahsan <[EMAIL PROTECTED]>
25766 by: Peter van Dijk <[EMAIL PROTECTED]>
qmail-newu via Perl script?
25703 by: Harald Hanche-Olsen <[EMAIL PROTECTED]>
25742 by: "Peter Janett" <[EMAIL PROTECTED]>
25744 by: Asmodeus <[EMAIL PROTECTED]>
25747 by: Harald Hanche-Olsen <[EMAIL PROTECTED]>
25777 by: Anand Buddhdev <[EMAIL PROTECTED]>
bcc fields
25704 by: Chris Johnson <[EMAIL PROTECTED]>
25705 by: Thomas Neumann <[EMAIL PROTECTED]>
25708 by: Chris Johnson <[EMAIL PROTECTED]>
25730 by: Jeff Hayward <[EMAIL PROTECTED]>
25740 by: Stefan Paletta <[EMAIL PROTECTED]>
Q: Is it possible to bind 2 diffrent qmail instances on 2 diffrent network interfaces
25706 by: Dave Sill <[EMAIL PROTECTED]>
25763 by: Peter van Dijk <[EMAIL PROTECTED]>
cgi script
25707 by: James McGlinn <[EMAIL PROTECTED]>
Is qmail's log method inefficient?
25714 by: Balazs Nagy <[EMAIL PROTECTED]>
25717 by: Andre Oppermann <[EMAIL PROTECTED]>
25719 by: Russell Nelson <[EMAIL PROTECTED]>
25723 by: Balazs Nagy <[EMAIL PROTECTED]>
25725 by: Andre Oppermann <[EMAIL PROTECTED]>
25737 by: Balazs Nagy <[EMAIL PROTECTED]>
25752 by: "Fred Lindberg" <[EMAIL PROTECTED]>
25755 by: Balazs Nagy <[EMAIL PROTECTED]>
25756 by: Vince Vielhaber <[EMAIL PROTECTED]>
25757 by: Balazs Nagy <[EMAIL PROTECTED]>
25760 by: Vince Vielhaber <[EMAIL PROTECTED]>
25761 by: Balazs Nagy <[EMAIL PROTECTED]>
25762 by: Vince Vielhaber <[EMAIL PROTECTED]>
25776 by: Magnus Bodin <[EMAIL PROTECTED]>
25779 by: Vince Vielhaber <[EMAIL PROTECTED]>
Weird stats?
25722 by: Mark E Drummond <[EMAIL PROTECTED]>
25751 by: "Fred Lindberg" <[EMAIL PROTECTED]>
What's a DSN?
25724 by: "Barton" <[EMAIL PROTECTED]>
25726 by: Russell Nelson <[EMAIL PROTECTED]>
25727 by: "Chris Garrigues" <[EMAIL PROTECTED]>
25732 by: "Sam" <[EMAIL PROTECTED]>
25733 by: "Sam" <[EMAIL PROTECTED]>
25736 by: "Adam D. McKenna" <[EMAIL PROTECTED]>
25743 by: "Sam" <[EMAIL PROTECTED]>
Error msg. from matchup
25729 by: "Ralf Guenthner" <[EMAIL PROTECTED]>
25739 by: Mark E Drummond <[EMAIL PROTECTED]>
[Off-topic] Simplicity (Re: What's a DSN?)
25734 by: Harald Hanche-Olsen <[EMAIL PROTECTED]>
25745 by: Jos Backus <[EMAIL PROTECTED]>
25746 by: Jos Backus <[EMAIL PROTECTED]>
Help getting qmail to work.
25754 by: "Brian Moon" <[EMAIL PROTECTED]>
Bare LF problem
25758 by: John Gonzalez/netMDC admin <[EMAIL PROTECTED]>
25759 by: Balazs Nagy <[EMAIL PROTECTED]>
25765 by: Justin Bell <[EMAIL PROTECTED]>
paternalism?
25764 by: Peter van Dijk <[EMAIL PROTECTED]>
fastforward, cyrus and firstname.lastname
25767 by: "Stephen Farrugia" <[EMAIL PROTECTED]>
25771 by: "Timothy L. Mayo" <[EMAIL PROTECTED]>
25775 by: "Stephen Farrugia" <[EMAIL PROTECTED]>
Home Directory Sticky?
25768 by: Eric Berg <[EMAIL PROTECTED]>
25769 by: Peter van Dijk <[EMAIL PROTECTED]>
25770 by: Chris Johnson <[EMAIL PROTECTED]>
25772 by: Eric Berg <[EMAIL PROTECTED]>
Help: deferral:
Unable_to_forward_message:_qq_trouble_creating_files_in_queue_(#4.3.0)./
25773 by: "Justin Hammond" <[EMAIL PROTECTED]>
Fw: Help: deferral:
Unable_to_forward_message:_qq_trouble_creating_files_in_queue_(#4.3.0)./
25774 by: "Justin Hammond" <[EMAIL PROTECTED]>
Maintaining Mailbox and MX record
25778 by: Manohar Pradhan <[EMAIL PROTECTED]>
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To bug my human owner, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
----------------------------------------------------------------------
Andre Oppermann writes: > > See http://www.mckusick.com/~mckusick/index.html > Thanks for taking the bandwidth to share that. What's it got to do with qmail? John -- John Conover, 631 Lamont Ct., Campbell, CA., 95008, USA. VOX 408.370.2688, FAX 408.379.9602, whois '!JC154' [EMAIL PROTECTED], http://www2.inow.com/~conover/john.html
Trevor Harrison wrote: > Ease up everyone... Tasos isn't a flame-baiting troller... he probably really needs >DSN (I feel your pain Tasos, I need it too). > > Anyway, he's also the author of Listproc (yeah!), which I'm still using to this day >because everything else (read majordomo) I've tried sucks hard; anyway, he's cool. > > -Trevor > ps. here's a good reason for DSN: SMTP<->X.400 gateways. X.400 supports all kinds >of return receipts, and right now, DSN is the way our X.400 MTA provider interfaces >this stuff. I've got a sendmail box that I have to keep using because we need to be >able to turn on DSN when we send messages into X.400. > However, DSN is also a major cause of headaches for us, either Micros~1 Exchange >MTA's saying that they support it, but they really don't, to someone else's >home-grown bad implementation, to firewall smtp filters rejecting it, etc. > Thanks everyone for the responses. Indeed our need for DSNs is simply TREMENDOUS. Email Solutions is setting up an enterprise-level services organization and the software we have developed (newsletter delivery if you care to know) needs a high speed farm of MTAs. Our software-customers at this point have lists as large as 3 million subscribers each. Our services organization should be able to support thousands of lists like that. With so much volume of email going out we need to cut down on the number of bounces. As we expect megabytes of bounces each day coming back from each such list, we need to keep our lists as clean as possible. Nothing else other than DSNs will allow us to be 100% successful. I am well aware that installing MTAs that do DSNs does not necessarily mean that we will not be getting non-DSN bounces back. In fact, our bounce handling code resolves about 99.2% of them (on a test of half a million random bounces). But we need to cut down on the processing time parsing non-DSN bounces, and indeed DSNs are very easy to parse with linear algorithms or better. For enterprise-level delivery needs qmail in its current form does not cut it for us. It is very unfortunate because it's extremely fast and reliable, and we take full advantage of its PIPELINE mode. The freeware sendmail is not an option for us either. >From the responses I got (again, thank you immensely), I became aware of commercial "versions" of qmail and that may be an option. Sendmail Inc also has a high-speed commercial version of its product which we will be looking at. Exim came up while exploring the market. I agree that security may be a problem with it. And if all fails, we'll do it ourselves, as they say ;-) I am not sure where Dan stands on DSNs (although I gather he just agree it's the right thing?), and all I can say is that he would have been a millionaire by now with the right product for business and a good business strategy. You know, despite what we all think of freeware sendmail, they did get $6mil in VC funding, they do have a high speed version of the product (of unknown as yet performance capabilities), they will be successful in converting large-scale operations using freeware sendmail like AOL.COM (e.g. see 205.188.156.161), and they are in the process of rewriting their product. My apologies to all of you who thought I was trying to stir up the waters here. But the similarity of responses I got re: qmail was very striking and the message was: use qmail but if your business depends on it and you need to get something done by the author, well, good luck! That's a chance we cannot afford to take. Finally, I have a serious proposal for all of you out there with a business mind. We may have a need for advisors should we decide to write our own SMTP delivery engine. Interested parties should email me privately to discuss this furhter. Thanks all for listening and good luck! tasos
> From: "Scott D. Yelich" <[EMAIL PROTECTED]> > Date: Tue, 18 May 1999 02:41:35 -0600 (MDT) > > Eric Allman's GAY? Of course we all know that using software written by gay authors might make us gay as well. Who in the hell cares????? Chris -- Chris Garrigues virCIO +1 512 432 4046 4314 Avenue C O- http://www.DeepEddy.Com/~cwg/ Austin, TX 78751-3709 +1 512 374 0500 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
Come on guys, lets get mature and stop any more remarks about sexual preferences of certain people, there are specific newsgroups for things like this. Let's focus on qmail here, shall we? Franky > ---------- > From: Chris > Garrigues[SMTP:[EMAIL PROTECTED]] > Sent: Tuesday, May 18, 1999 4:04 PM > To: Scott D. Yelich > Cc: Russell Nelson; Tasos Kotsikonas; [EMAIL PROTECTED] > Subject: Re: Mass migration off of qmail because of lack of DSNs? > > > From: "Scott D. Yelich" <[EMAIL PROTECTED]> > > Date: Tue, 18 May 1999 02:41:35 -0600 (MDT) > > > > Eric Allman's GAY? > > Of course we all know that using software written by gay authors might > make us > gay as well. > > Who in the hell cares????? > > Chris > > -- > Chris Garrigues virCIO > +1 512 432 4046 4314 Avenue C O- > http://www.DeepEddy.Com/~cwg/ Austin, TX 78751-3709 > +1 512 374 0500 > > 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. > > >
Scott D. Yelich <[EMAIL PROTECTED]> writes on 18 May 1999 at 02:41:35 -0600 > -----BEGIN PGP SIGNED MESSAGE----- > > > > On 18 May 1999, Russell Nelson wrote: > > This is completely unfair. > > No it't not. It's the truth. > > > Calling qmail "non-conforming" because it has its own > > bounce format is like calling Eric Allman "non-conforming" just > > because he's gay. > > Eric Allman's GAY? Try to imagine how little I care. -- David Dyer-Bennet [EMAIL PROTECTED] http://www.ddb.com/~ddb (photos, sf) Minicon: http://www.mnstf.org/minicon http://ouroboros.demesne.com/ The Ouroboros Bookworms Join the 20th century before it's too late!
Tasos Kotsikonas <[EMAIL PROTECTED]> writes: > Thanks everyone for the responses. Indeed our need for DSNs is > simply TREMENDOUS...With so much volume of email going out we need > to cut down on the number of bounces. As we expect megabytes of > bounces each day coming back from each such list, we need to keep > our lists as clean as possible. Nothing else other than DSNs will > allow us to be 100% successful. Forgive the (possibly ignorant) question, but why won't VERPs allow you to be 100% successful? There are exactly two things that MTA's cannot mess with, and still work: the envelope sender, and the envelope recipient. Any other header munging is possible, and probably happens at least sometimes. With VERP, if you receive a bounce, then it will be addressed in such a way as to completely specify what bounced. Period. Handling that automatically is certainly no trick. Of course, at the moment I believe that implies you must use both qmail and ezmlm. -Len. -- Corrupt: In politics, holding an office of trust or profit. -- Ambrose Bierce
Tasos Kotsikonas writes: > With so much volume of email going out we need to cut down > on the number of bounces. Look into qmail's VERP. VERP will make you happy. Very, very, very happy. > In fact, our bounce handling code resolves about 99.2% of them (on > a test of half a million random bounces). But we need to cut down > on the processing time parsing non-DSN bounces, and indeed DSNs are > very easy to parse with linear algorithms or better. VERP (remote bounces) doesn't need to be parsed. And Dan's QSBMF (local bounces) is much easier to parse than DSNs. > My apologies to all of you who thought I was trying to stir up the > waters here. But the similarity of responses I got re: qmail was > very striking and the message was: use qmail but if your business > depends on it and you need to get something done by the author, > well, good luck! You received bad advice. First, because you are perfectly free to modify qmail for your own uses. Second, because very often, qmail really *doesn't* need modification. qmail is designed to play well with other Unix programs, and can usually be extended without source hackery or patches. -- -russ nelson <[EMAIL PROTECTED]> http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | Good parenting creates 521 Pleasant Valley Rd. | +1 315 268 1925 voice | an adult, not a perfect Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | child.
Tasos Kotsikonas <[EMAIL PROTECTED]> writes on 18 May 1999 at 13:56:37 +0000 > Thanks everyone for the responses. Indeed our need for DSNs is > simply TREMENDOUS. Email Solutions is setting up an > enterprise-level services organization and the software we have > developed (newsletter delivery if you care to know) needs a high > speed farm of MTAs. Our software-customers at this point have lists > as large as 3 million subscribers each. Our services organization > should be able to support thousands of lists like that. > > With so much volume of email going out we need to cut down > on the number of bounces. As we expect megabytes of bounces > each day coming back from each such list, we need to keep > our lists as clean as possible. Nothing else other than DSNs will > allow us to be 100% successful. I am well aware that installing > MTAs that do DSNs does not necessarily mean that we will > not be getting non-DSN bounces back. In fact, our bounce handling > code resolves about 99.2% of them (on a test of half a million random > bounces). But we need to cut down on the processing time parsing > non-DSN bounces, and indeed DSNs are very easy to parse with > linear algorithms or better. Actually, qmail's VERP should allow you to be 100% successful; and DSNs won't, since they're not widely supported. -- David Dyer-Bennet [EMAIL PROTECTED] http://www.ddb.com/~ddb (photos, sf) Minicon: http://www.mnstf.org/minicon http://ouroboros.demesne.com/ The Ouroboros Bookworms Join the 20th century before it's too late!
[EMAIL PROTECTED] writes: > With VERP, if you receive a bounce, then it will be addressed in such > a way as to completely specify what bounced. Period. Handling that > automatically is certainly no trick. Well, actually, sometimes gateways send bounces to the From: address. Yes, this is horribly broken. > Of course, at the moment I believe that implies you must use both > qmail and ezmlm. Not really. ezmlm is just a good mailing list package. You can use VERPs and QSBMFs without using ezmlm. I'm doing it for a customer right now. -- -russ nelson <[EMAIL PROTECTED]> http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | Good parenting creates 521 Pleasant Valley Rd. | +1 315 268 1925 voice | an adult, not a perfect Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | child.
Russell Nelson <[EMAIL PROTECTED]> wrote: >[EMAIL PROTECTED] writes: > > > > With VERP, if you receive a bounce, then it will be addressed in such > > a way as to completely specify what bounced. Period. Handling that > > automatically is certainly no trick. > >Well, actually, sometimes gateways send bounces to the From: address. >Yes, this is horribly broken. And, in my experience, MTA's that do that don't use DSN: they're non-standards oriented. VERP will handle all DSN bounces and almost all non-DSN bounces. That's better that any DSN-only bounce handler can do. > > Of course, at the moment I believe that implies you must use both > > qmail and ezmlm. > >Not really. ezmlm is just a good mailing list package. You can use >VERPs and QSBMFs without using ezmlm. I'm doing it for a customer >right now. I use VERP's with majordomo, thanks to Russ' bounceman. It's a list manager's dream. -Dave
On Mon, May 17, 1999 at 10:34:35PM -0400, "Adam D. McKenna" <[EMAIL PROTECTED]> wrote: > DNS's (IMNSHO): > > a) are lame > b) are an invasion of privacy (if you can't turn them off) > c) should be handled by the MUA We had them turned on on our main email servers here and ended up turning them off after we had a mail loop with someone's vacation program that requested DSN replies and then sent back a vacation message in response to the reply.
Tasos, Others have pointed this out, but I wanted to reinforce it: if you are already using qmail then handling list-traffic-bounces is so tremendously easy using VERP that there really isn't any comparison to DSN. In the most recent survey that I am aware of, DJB's Jan 1998 survey, about 41% of sites claimed DSN support in their MTA. 100% of sites support VERP, except for some that violate the fundamental requirements of RFC 821/RFC 1123. Parsing VERP is dead simple. I do it in a small shell script, and can certainly parse megabytes of bounces if need be. Use of VERP does not require ezmlm as someone else has suggested. Your statement that qmail's lack of DSN makes it unusable for enterprise class mail systems such as you describe does not stand up; several large enterprises, including the one I work for, use qmail as their primary MTA. The only reason to use DSN, in my judgement, is if you have to support mail clients (people or programs) that can't function without it. So my suggestion is that you look in to VERP, and if you conclude that it won't work for you get back to us, there's a good chance you've overlooked something. At the least, I would appreciate a descriptive report on a case where VERP is unusable for mailing list bounces. Regards, -- Jeff Hayward On Tue, 18 May 1999, Tasos Kotsikonas wrote: Trevor Harrison wrote: > Ease up everyone... Tasos isn't a flame-baiting troller... he probably really needs DSN (I feel your pain Tasos, I need it too). > > Anyway, he's also the author of Listproc (yeah!), which I'm still using to this day because everything else (read majordomo) I've tried sucks hard; anyway, he's cool. > > -Trevor > ps. here's a good reason for DSN: SMTP<->X.400 gateways. X.400 supports all kinds of return receipts, and right now, DSN is the way our X.400 MTA provider interfaces this stuff. I've got a sendmail box that I have to keep using because we need to be able to turn on DSN when we send messages into X.400. > However, DSN is also a major cause of headaches for us, either Micros~1 Exchange MTA's saying that they support it, but they really don't, to someone else's home-grown bad implementation, to firewall smtp filters rejecting it, etc. > Thanks everyone for the responses. Indeed our need for DSNs is simply TREMENDOUS. Email Solutions is setting up an enterprise-level services organization and the software we have developed (newsletter delivery if you care to know) needs a high speed farm of MTAs. Our software-customers at this point have lists as large as 3 million subscribers each. Our services organization should be able to support thousands of lists like that. With so much volume of email going out we need to cut down on the number of bounces. As we expect megabytes of bounces each day coming back from each such list, we need to keep our lists as clean as possible. Nothing else other than DSNs will allow us to be 100% successful. I am well aware that installing MTAs that do DSNs does not necessarily mean that we will not be getting non-DSN bounces back. In fact, our bounce handling code resolves about 99.2% of them (on a test of half a million random bounces). But we need to cut down on the processing time parsing non-DSN bounces, and indeed DSNs are very easy to parse with linear algorithms or better. For enterprise-level delivery needs qmail in its current form does not cut it for us. It is very unfortunate because it's extremely fast and reliable, and we take full advantage of its PIPELINE mode. The freeware sendmail is not an option for us either. >From the responses I got (again, thank you immensely), I became aware of commercial "versions" of qmail and that may be an option. Sendmail Inc also has a high-speed commercial version of its product which we will be looking at. Exim came up while exploring the market. I agree that security may be a problem with it. And if all fails, we'll do it ourselves, as they say ;-) I am not sure where Dan stands on DSNs (although I gather he just agree it's the right thing?), and all I can say is that he would have been a millionaire by now with the right product for business and a good business strategy. You know, despite what we all think of freeware sendmail, they did get $6mil in VC funding, they do have a high speed version of the product (of unknown as yet performance capabilities), they will be successful in converting large-scale operations using freeware sendmail like AOL.COM (e.g. see 205.188.156.161), and they are in the process of rewriting their product. My apologies to all of you who thought I was trying to stir up the waters here. But the similarity of responses I got re: qmail was very striking and the message was: use qmail but if your business depends on it and you need to get something done by the author, well, good luck! That's a chance we cannot afford to take. Finally, I have a serious proposal for all of you out there with a business mind. We may have a need for advisors should we decide to write our own SMTP delivery engine. Interested parties should email me privately to discuss this furhter. Thanks all for listening and good luck! tasos
[EMAIL PROTECTED] writes: > Forgive the (possibly ignorant) question, but why won't VERPs allow > you to be 100% successful? When you have mailing lists that number in millions, you will usually have thousands of messages going to the same messages. Using VERPs will require a thousand times as much bandwidth. Each individual message will have to be transmitted separately, plus each bounce will be returned separately. With DSNs, one copy of message to a single domain, with all the receipients listed for the message, and then exactly one bounce back, listing all undeliverable addresses. -- Sam
Sam writes: > When you have mailing lists that number in millions, you will usually have > thousands of messages going to the same messages. Slippery fingers. IM "to the same domain". -- Sam
Tasos Kotsikonas <[EMAIL PROTECTED]> wrote: > >I am not a subscriber of this list so if you have any relevant comments >please copy me too. Our company is looking around for qmail >replacements that do DSNs, after having sent a couple of emails >to Dan and received no replies on this issue. Dan's pretty busy, and he's already addresses the DSN issue publicly. He doesn't like to repeat himself. >While talking to various people >about it, the following comments by one prominent entity in the >email world [identity withheld] was not atypical: Brad Knowles? >However, the author of qmail is a problem. besides simply being one of the >more obnoxious people in the world, he is entirely rigid and unresponsive >to user requests, as his non-conforming bounce format demonstrates. Dan does things the way he thinks they should be done. He only implements user requests that he thinks *should* be implemented. >I would strongly encourage looking at exim. I've heard very good things >about it and the web page for it has an excellent tone. I don't choose MTA's (or any other products) based on the tone of their web page. >I'm told there is >a pretty serious mass migration from qmail to exim. Wishful thinking. Since exim and qmail came on the scene at about the same time, people using qmail already decided against exim. >Many of us are delighted to hear it. How juvenile... >So, is the final answer NO DSNs from qmail? Probably not from Dan. >Ever? Is there a reason we can buy why? Dan looked at the DSN standard, and the level of MUA/MTA support for it, and decided against it. Can you buy that? >Please understand I do not >want to be part of the politics, I am just asking a very specific >question to which I have had no responses yet from Dan. We've all asked questions Dan hasn't answered. There's just not enough of him to go around. All things considered, I'd rather he devote his time to the lawsuit and coding qmail 2.0 and other djbware. -Dave
Text written by Chris Garrigues at 09:04 AM 5/18/99 -0500: >> Eric Allman's GAY? > >Of course we all know that using software written by gay authors might make us >gay as well. > >Who in the hell cares????? Someone who's exploring their sexuality and wants to know that not all gay people are artists, writers, dancers and actors might be very pleased to find a gay geek role model. Though I'll admit the Qmail mailing list isn't really the place to look for that. ----------------------------------------------------------------- Kai MacTane System Administrator Online Partners.com, Inc. ----------------------------------------------------------------- >From the Jargon File: (v4.0.0, 25 Jul 1996) gonkulator /gon'kyoo-lay-tr/ /n./ [from the old "Hogan's Heroes" TV series] A pretentious piece of equipment that actually serves no useful purpose. Usually used to describe one's least favorite piece of computer hardware. See gonk.
[EMAIL PROTECTED] > Actually, qmail's VERP should allow you to be 100% successful; and > DSNs won't, since they're not widely supported. Huh? What's your threshold for "widely supported"? Doesn't sendmail have something like 80% market share and nice DSN support? --Arnt
Arnt Gulbrandsen <[EMAIL PROTECTED]> writes on 18 May 1999 at 20:12:17 +0200 > [EMAIL PROTECTED] > > Actually, qmail's VERP should allow you to be 100% successful; and > > DSNs won't, since they're not widely supported. > > Huh? What's your threshold for "widely supported"? Doesn't sendmail > have something like 80% market share and nice DSN support? Well, so they claim, but I don't think everybody is running modern releases with DSN. And some may not have it enabled. Perhaps my feelings are biased by knowing that only one of the sites I know the admin of is running sendmail. -- David Dyer-Bennet [EMAIL PROTECTED] http://www.ddb.com/~ddb (photos, sf) Minicon: http://www.mnstf.org/minicon http://ouroboros.demesne.com/ The Ouroboros Bookworms Join the 20th century before it's too late!
On 18-May-99 Arnt Gulbrandsen wrote: > [EMAIL PROTECTED] >> Actually, qmail's VERP should allow you to be 100% successful; and >> DSNs won't, since they're not widely supported. > > Huh? What's your threshold for "widely supported"? Doesn't sendmail > have something like 80% market share and nice DSN support? But how much of that 80% is really old sendmail? Having 80% marketshare and 80% marketshare of a current product are two very different things. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: [EMAIL PROTECTED] flame-mail: /dev/null # include <std/disclaimers.h> TEAM-OS2 Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
On 18 May 1999 20:12:17 +0200, Arnt Gulbrandsen wrote: >Huh? What's your threshold for "widely supported"? Doesn't sendmail >have something like 80% market share and nice DSN support? 99% supported (VERP is better than that) => 1x work. 80% supported => 20 x work. Sam's 1000x bandwidth for VERP over DSN is widely exaggerated. More like 2x at most (most bounces are preVERP, most messages have single recipients, most mailing lists have no more than 10% of members at the most frequent domain, 5% at one or two others,... So, it's very hard to go above 2x in message transfer even with pure mailing list traffic). Also, there are specific solutions for situations where bandwidth is an issue. -Sincerely, Fred (Frederik Lindberg, Infectious Diseases, WashU, St. Louis, MO, USA)
While i m installing my qmail and running make command it shows me like this:# make setup check
( cat warn-auto.sh; \
echo CC=\'`head -1 conf-cc`\'; \
echo LD=\'`head -1 conf-ld`\' \
) > auto-ccld.sh
cat auto-ccld.sh make-load.sh > make-load
chmod 755 make-load
cat auto-ccld.sh find-systype.sh > find-systype
chmod 755 find-systype
./find-systype > systype
( cat warn-auto.sh; ./make-load "`cat systype`" ) > load
chmod 755 load
cat auto-ccld.sh make-compile.sh > make-compile
chmod 755 make-compile
( cat warn-auto.sh; ./make-compile "`cat systype`" ) > \
compile
chmod 755 compile
( ( ./compile tryvfork.c && ./load tryvfork ) >/dev/null \
2>&1 \
&& cat fork.h2 || cat fork.h1 ) > fork.h
make: *** [fork.h] Error 139Does anybody aware of these errors, pl. let me know how to come out from this error.
Thanx & regards
Javed Ahsan
-- ***************************************************************** * Internet Programmer, * * Usha Telenet Private Limited * * Usha Bhavan, Phone: +91-11-6959000/ * * A-41 Mohan Co-operative, 6959200/6959300. Ext: 241 * * Industrial Estate, Fax: +91-11-6959999 * * Mathura Road, Email: [EMAIL PROTECTED] * * New Delhi 110044 (INDIA) URL: http://www.imaginix.net * *****************************************************************
On Tue, May 18, 1999 at 04:27:36PM +0000, Javed Ahsan wrote: > While i m installing my qmail and running make command it shows me like > this: > > make: *** [fork.h] Error 139 139-128=11 # kill -l 11 SIGSEGV That's either a hardware problem or some totally screwed compiler. Greetz, Peter -- | 'He broke my heart, | Peter van Dijk | I broke his neck' | [EMAIL PROTECTED] | nognikz - As the sun | Hardbeat@ircnet - #cistron/#linux.nl | | Hardbeat@undernet - #groningen/#kinkfm/#vdh |
+ "Peter Janett" <[EMAIL PROTECTED]>: | Has anyone been able to execute the qmail-newu command via a Perl | script? I haven't tried, but can think of no reason why it should be impossible or even difficult: It's just another program to be run, which you can do using system("/var/qmail/bin/qmail-newu");. Maybe if you told us what you were doing, what you expected, and what happened? | Is there another way to accomplish what qmail-new does without | executing the command? Not without writing your own qmail-newu replacement, which seems rather pointless to me. In my own setup, BTW, I have a perl script generating users/assign and a Makefile organizing the running of this perl script and qmail-newuser. - Harald
Thanks for the reply. I tried exactly what you suggested: system("/var/qmail/bin/qmail-newu"); But this fails, appearing to be a permission problem. If I telnet in as the user that the script runs as, I get "Permission denied". So, I changed permissions, and then get: "qmail-newu: fatal: unable to open users/cdb.tmp" It looks like qmail-newu creates a cdb.tmp file, then copies it to the cdb file. Even if I change the permissions to allow the command to be executed by the user the script runs as, it fails to move (copy) the cdb.tmp file to the cdb file. Since this is for web based email, I need to do a "qmail=newu" each time someone signs up (each time the Perl script is run.) For this reason, setting up a shell script to run at certain intervals doesn't seem to be the correct solution. I'd like to see how you are running the command with your Perl script, or hear other suggestions Thanks, Peter Janett http://www.healthwell.com -----Original Message----- From: Harald Hanche-Olsen <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: Tuesday, May 18, 1999 5:10 AM Subject: Re: qmail-newu via Perl script? > > > > >+ "Peter Janett" <[EMAIL PROTECTED]>: > >| Has anyone been able to execute the qmail-newu command via a Perl >| script? > >I haven't tried, but can think of no reason why it should be >impossible or even difficult: It's just another program to be run, >which you can do using system("/var/qmail/bin/qmail-newu");. Maybe if >you told us what you were doing, what you expected, and what happened? > >| Is there another way to accomplish what qmail-new does without >| executing the command? > >Not without writing your own qmail-newu replacement, which seems >rather pointless to me. In my own setup, BTW, I have a perl script >generating users/assign and a Makefile organizing the running of this >perl script and qmail-newuser. > >- Harald > > >
On Tue, 18 May 1999, Peter Janett wrote: > Thanks for the reply. I tried exactly what you suggested: > system("/var/qmail/bin/qmail-newu"); > > But this fails, appearing to be a permission problem. If I telnet in as the > user that the script runs as, I get "Permission denied". So, I changed > permissions, and then get: > "qmail-newu: fatal: unable to open users/cdb.tmp" <snip> > > Since this is for web based email, I need to do a "qmail=newu" each time > someone signs up (each time the Perl script is run.) For this reason, > setting up a shell script to run at certain intervals doesn't seem to be the > correct solution. I'd like to see how you are running the command with your > Perl script, or hear other suggestions I get the feeling that you need to run the perl script as root (or whomever else has permissions to those files/directories) Everything you've mentioned seems to be permissions problems. You might be able to get away with one of the qmail* uids, but you might end up having to run the script as root. That being said, I've never mucked around with scripting it. .Shawn
+ "Peter Janett" <[EMAIL PROTECTED]>: | It looks like qmail-newu creates a cdb.tmp file, then copies it to | the cdb file. No, it renames it. The reason is that the update has to be atomic, since there is a live mail system using the database. | Even if I change the permissions to allow the command to be executed | by the user the script runs as, it fails to move (copy) the cdb.tmp | file to the cdb file. Indeed, qmail-newu must have write privileges on the /var/qmail/user directory. + Asmodeus <[EMAIL PROTECTED]>: | I get the feeling that you need to run the perl script as root (or | whomever else has permissions to those files/directories) Everything | you've mentioned seems to be permissions problems. You might be | able to get away with one of the qmail* uids, but you might end up | having to run the script as root. Certainly, if you allow any uid other than root to muck around with the users directory, you have opened up a large potential security hole. To allow your web server to do this is bold and daring indeed. Some suid-ness and *very* careful and security-conscious programming is probably called for. - Harald
On Tue, May 18, 1999 at 11:10:58AM -0600, Peter Janett wrote: While we're on the subject, qmail-newu does not check to see if 2 copies are running. I hope your perl script is doing some sort of serialization, to make sure you don't accidentally run 2 qmail-newu's together, and end up with a corrupt users.cdb. > Thanks for the reply. I tried exactly what you suggested: > system("/var/qmail/bin/qmail-newu"); > > But this fails, appearing to be a permission problem. If I telnet in as the > user that the script runs as, I get "Permission denied". So, I changed > permissions, and then get: > "qmail-newu: fatal: unable to open users/cdb.tmp" -- System Administrator See complete headers for address, homepage and phone numbers
On Tue, May 18, 1999 at 10:43:30AM +0200, Eike Kiltz wrote: > Hi, > > for some stuipid reason a customer sent out a message containing 1500 (!) > ','-seperated entries in the bcc: header using AK-Mail with a qmail 1.03 > smtp server for outgoing mail. > qmail-header(5) says > qmail-inject deletes any Bcc field > and RFC822 says there is no length limit on the header > > but what happened was that several adresses bounced and the bounced > messaged were sent to all the 1500 adresses listed only in the bcc field. > Obviously qmail-inject did not remove the bcc correctly. When you say "with a qmail 1.03 smtp server for outgoing mail," do you mean that this message was injected with SMTP? If so, then qmail-inject never saw the message. qmail-smtpd doesn't look at the headers, and execs qmail-queue to queue the message as is. It's the responsibility of the software on the remote end to strip the Bcc field and turn it into SMTP "RCPT TO" commands. Chris
Chris Johnson <[EMAIL PROTECTED]> writes: > > When you say "with a qmail 1.03 smtp server for outgoing mail," do > you mean that this message was injected with SMTP? If so, then > qmail-inject never saw the message. qmail-smtpd doesn't look at the > headers, and execs qmail-queue to queue the message as is. It's the > responsibility of the software on the remote end to strip the Bcc > field and turn it into SMTP "RCPT TO" commands. Uh... you say that a SMTP MTA should analyze message headers and turn the retrieved information into envelope recipient data? I don't buy that. How's that supposed to work anyway: The moment the first message header appears in a SMTP connection's data stream is by definition the DATA part of the session. At that time all envelope sender and recipient specifications have been completed anyway. The only scenario where a SMTP MTA must deduce envelope information from message headers is when the MTA is locally invoked a'la "sendmail -t". -t
On Tue, May 18, 1999 at 02:27:58PM +0200, Thomas Neumann wrote: > Chris Johnson <[EMAIL PROTECTED]> writes: > > > > When you say "with a qmail 1.03 smtp server for outgoing mail," do > > you mean that this message was injected with SMTP? If so, then > > qmail-inject never saw the message. qmail-smtpd doesn't look at the > > headers, and execs qmail-queue to queue the message as is. It's the > > responsibility of the software on the remote end to strip the Bcc > > field and turn it into SMTP "RCPT TO" commands. > > Uh... you say that a SMTP MTA should analyze message headers and turn > the retrieved information into envelope recipient data? I don't buy > that. How's that supposed to work anyway: The moment the first message > header appears in a SMTP connection's data stream is by definition the > DATA part of the session. At that time all envelope sender and > recipient specifications have been completed anyway. Uh... I didn't say that at all, though I was intentionally vague when I said it was the responsibility of "the software" on the remote end to strip Bcc fields. The point is that if someone wants to deliver mail to my server with SMTP, it's his responsibility to turn Bcc fields into envelope information, because I'm not going to look at the message headers and will queue the message just as I receive it. What piece of software performs this transformation--sendmail, qmail-inject, Eudora, Netscape, whatever--is no concern of mine. Chris
The only program in the qmail suite that looks at headers is qmail-inject. If the message was submitted via SMTP, nothing in qmail ever looked at those Bcc: headers. The submitting client (AK-Mail?) *should* have stripped bcc fromt the headers and built the correct envelope. My guess is this: 1) The message was not processed by qmail-inject, and 2) the MTA that sent bounces to all the Bcc: addresses was a) not qmail, and b) very broken. To answer your question, the only limit on header size in qmail is the memory needed by qmail-inject to build the envelope. That limit is imposed by the kernel, not qmail. -- Jeff Hayward On Tue, 18 May 1999, Eike Kiltz wrote: Hi, for some stuipid reason a customer sent out a message containing 1500 (!) ','-seperated entries in the bcc: header using AK-Mail with a qmail 1.03 smtp server for outgoing mail. qmail-header(5) says qmail-inject deletes any Bcc field and RFC822 says there is no length limit on the header but what happened was that several adresses bounced and the bounced messaged were sent to all the 1500 adresses listed only in the bcc field. Obviously qmail-inject did not remove the bcc correctly. So, is there a limititation on the header in qmail? The header above was about 29469 bytes long, the bcc field about 27617 bytes. Any idea? -Eike
Thomas Neumann wrote/schrieb/scribsit: > Chris Johnson <[EMAIL PROTECTED]> writes: > > > > qmail-inject never saw the message. qmail-smtpd doesn't look at the > > headers, and execs qmail-queue to queue the message as is. It's the > > responsibility of the software on the remote end to strip the Bcc > > field and turn it into SMTP "RCPT TO" commands. > > Uh... you say that a SMTP MTA should analyze message headers and turn > the retrieved information into envelope recipient data? I don't buy No. ("software on the remote end" meaning "SMTP client") Stefan
Anand Buddhdev <[EMAIL PROTECTED]> wrote: >On Mon, May 17, 1999 at 09:19:29AM -0400, Eric Shafto wrote: > >> > HELO <SP> <domain> <CRLF> >> > <domain> ::= <element> | <element> "." <domain> >> > <element> ::= <name> | "#" <number> | "[" <dotnum> "]" >> > <dotnum> ::= <snum> "." <snum> "." <snum> "." <snum> >> > <snum> ::= one, two, or three digits representing a decimal >> > integer value in the range 0 through 255 >> > >> > Therefore, >> > >> > HELO [199.103.176.41] >> >> But so does: >> >> HELO [199.103.176.41].#394875.spoon.[100.164.68.209] > >I don't think so. I do. The <domain> rule allows any <domain> to be prefixed with any <element>, followed by ".". So as along as every "." delimited chunk is a valid <element>, the result is a valid <domain>. -Dave
On Tue, May 18, 1999 at 08:31:25AM -0400, Dave Sill wrote: > Anand Buddhdev <[EMAIL PROTECTED]> wrote: > >On Mon, May 17, 1999 at 09:19:29AM -0400, Eric Shafto wrote: > > > >> > HELO <SP> <domain> <CRLF> > >> > <domain> ::= <element> | <element> "." <domain> > >> > <element> ::= <name> | "#" <number> | "[" <dotnum> "]" > >> > <dotnum> ::= <snum> "." <snum> "." <snum> "." <snum> > >> > <snum> ::= one, two, or three digits representing a decimal > >> > integer value in the range 0 through 255 > >> > > >> > Therefore, > >> > > >> > HELO [199.103.176.41] > >> > >> But so does: > >> > >> HELO [199.103.176.41].#394875.spoon.[100.164.68.209] > > > >I don't think so. > > I do. The <domain> rule allows any <domain> to be prefixed with any > <element>, followed by ".". So as along as every "." delimited chunk > is a valid <element>, the result is a valid <domain>. Isn't that kind of sick? Greetz, Peter -- | 'He broke my heart, | Peter van Dijk | I broke his neck' | [EMAIL PROTECTED] | nognikz - As the sun | Hardbeat@ircnet - #cistron/#linux.nl | | Hardbeat@undernet - #groningen/#kinkfm/#vdh |
"A.Wadas" wrote: > > my Linux system is sendmail free. I do not have sendmail in /var/qmail/bin > Do I need to have it to solve the problem. if so, how to do it without > reinstalling Qmail. > Thanks > Andrzej Wadas I don't know if it's specific to the Memphis RPM I used to install Qmail, but my system has a binary 'sendmail' in /var/qmail/bin, and a symlink to it in /usr/sbin. If you'd like me to send you the file (8k) let me know off the list; it might be worthwhile trying. Short of that, a script using qmail-inject as suggested earlier should be able to handle formmail's output easily. Cheers, James McGlinn -- Entertainz Web Solutions * http://www.entertainz.co.nz/ --
Hi, I read Qmail's documentation again and I realized that DJB didn't mention logging other than qmail-send. Is logging obsolete? I don't think so. But why other (smtpd, qmtpd, but most importantly pop3d) services lack the support of logging? IMHO the technology behind qmail logging is wrong. These inetd-controlled services cannot use stderr for logging (as tcpserver), and none of DJB's software use syslog. Therefore no logging is applied to these softwares. Anyone who say 'when a connection is made it's enough to log it's remote ip number' is wrong. A customer of mine wanted to log the time, remote IP, password checking failure, status informations about any POP3 connections just because they wanted to track down their would-be hacker employees. It was just a bit of hack in the source code. But here? Here is no way to do it. I see two solutions. The first one is not likely to be realized: use syslog. The another one is much better. My idea is the same as in qmail-start: tcpserver should open a file descriptor for piping through a logger program. The service program (qmail-pop3d for example) should check if this fixed fd number is exists. Any comments? -- Regards: Kevin (Balazs)
Balazs Nagy wrote: > > Hi, > > I read Qmail's documentation again and I realized that DJB didn't mention > logging other than qmail-send. Is logging obsolete? I don't think so. But > why other (smtpd, qmtpd, but most importantly pop3d) services lack the > support of logging? > > IMHO the technology behind qmail logging is wrong. These inetd-controlled > services cannot use stderr for logging (as tcpserver), and none of DJB's > software use syslog. Therefore no logging is applied to these softwares. > > Anyone who say 'when a connection is made it's enough to log it's remote ip > number' is wrong. A customer of mine wanted to log the time, remote IP, > password checking failure, status informations about any POP3 connections > just because they wanted to track down their would-be hacker employees. > It was just a bit of hack in the source code. > > But here? Here is no way to do it. > > I see two solutions. The first one is not likely to be realized: use > syslog. The another one is much better. My idea is the same as in > qmail-start: tcpserver should open a file descriptor for piping through a > logger program. The service program (qmail-pop3d for example) should check > if this fixed fd number is exists. > > Any comments? If you run under tcpserver it's no problem to log to stderr. Everthing you print to stderr will appear in tcpserver's logfile. In fact I'm implementing that right now for qmail-smptd and qmail-pop3d. -- Andre
Balazs Nagy writes: > IMHO the technology behind qmail logging is wrong. These inetd-controlled > services cannot use stderr for logging (as tcpserver), and none of DJB's > software use syslog. Therefore no logging is applied to these softwares. That's why you don't use inetd. Inetd is stupid. Syslog is stupid. A lot of BSD facilities are stupid. > Anyone who say 'when a connection is made it's enough to log it's remote ip > number' is wrong. A customer of mine wanted to log the time, remote IP, > password checking failure, status informations about any POP3 connections > just because they wanted to track down their would-be hacker employees. > It was just a bit of hack in the source code. > > But here? Here is no way to do it. Write a checkpassword which logs to stderr. -- -russ nelson <[EMAIL PROTECTED]> http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | Good parenting creates 521 Pleasant Valley Rd. | +1 315 268 1925 voice | an adult, not a perfect Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | child.
On Tue, 18 May 1999, Andre Oppermann wrote: > Balazs Nagy wrote: > > > > I see two solutions. The first one is not likely to be realized: use > > syslog. The another one is much better. My idea is the same as in > > qmail-start: tcpserver should open a file descriptor for piping through a > > logger program. The service program (qmail-pop3d for example) should check > > if this fixed fd number is exists. > > > > Any comments? > > If you run under tcpserver it's no problem to log to stderr. Everthing > you print to stderr will appear in tcpserver's logfile. In fact I'm > implementing that right now for qmail-smptd and qmail-pop3d. Yeah, but you *should* give a non-sensitive solution. If you use stderr for logging, you should remove the dup2ing fd 1 to fd 2 line, but it's for compatibility reasons among various inetd's. By the way inetd (from netkit-base) actually dup2s fd 1 to fd 2, which will happily puts your logs to the socket. Why do you want to determine qmail services whether it runs under tcpserver or not? It's a very heavy compatibility issue. I'd like to see if DJB himself says anything about the subject. If we want logging, we should want to do it the official way. -- Regards: Kevin (Balazs)
Balazs Nagy wrote: > > On Tue, 18 May 1999, Andre Oppermann wrote: > > > Balazs Nagy wrote: > > > > > > I see two solutions. The first one is not likely to be realized: use > > > syslog. The another one is much better. My idea is the same as in > > > qmail-start: tcpserver should open a file descriptor for piping through a > > > logger program. The service program (qmail-pop3d for example) should check > > > if this fixed fd number is exists. > > > > > > Any comments? > > > > If you run under tcpserver it's no problem to log to stderr. Everthing > > you print to stderr will appear in tcpserver's logfile. In fact I'm > > implementing that right now for qmail-smptd and qmail-pop3d. > > Yeah, but you *should* give a non-sensitive solution. If you use stderr for > logging, you should remove the dup2ing fd 1 to fd 2 line, but it's for > compatibility reasons among various inetd's. By the way inetd (from > netkit-base) actually dup2s fd 1 to fd 2, which will happily puts your logs > to the socket. Why do you want to determine qmail services whether it runs > under tcpserver or not? It's a very heavy compatibility issue. Feel free to roll your own patch which send's all it's stuff to syslog. Anyway, who cares about inetd? > I'd like to see if DJB himself says anything about the subject. If we want > logging, we should want to do it the official way. He say's use recordio. -- Andre
On Tue, 18 May 1999, Andre Oppermann wrote: > Feel free to roll your own patch which send's all it's stuff to syslog. Well, I think if I hack syslog support into qmail, it won't be qmail anymore as DJB said before. > Anyway, who cares about inetd? Anyone who don't want to install ucspi-tcp. You cannot say 'qmail-smtpd is not inetd conform' because it's not true. This is a bigger issue than patching qmail - you cannot sell a qmail-solution without move a step back and check it's integrity. IMHO qmail itself is a robust server, without patches. Patches can add more functionality but more weaknesses too. I cannot belive in patches which are will remain just as patches. > > I'd like to see if DJB himself says anything about the subject. If we want > > logging, we should want to do it the official way. > > He say's use recordio. Call me stupid but I don't know what recordio is. -- Regards: Kevin (Balazs)
On Tue, 18 May 1999 17:35:09 +0200 (CEST), Balazs Nagy wrote: >Anyone who don't want to install ucspi-tcp. You cannot say 'qmail-smtpd is >not inetd conform' because it's not true. This is a bigger issue than >patching qmail - you cannot sell a qmail-solution without move a step back >and check it's integrity. IMHO qmail itself is a robust server, without >patches. Patches can add more functionality but more weaknesses too. I >cannot belive in patches which are will remain just as patches. Don't patch qmail, use ucspi-tcp/daemontools. You can't blame Dan for, after giving you a perfect solution, not being willing to make a poor one slightly better. -Sincerely, Fred (Frederik Lindberg, Infectious Diseases, WashU, St. Louis, MO, USA)
On Tue, 18 May 1999, Fred Lindberg wrote: > On Tue, 18 May 1999 17:35:09 +0200 (CEST), Balazs Nagy wrote: > > >Anyone who don't want to install ucspi-tcp. You cannot say 'qmail-smtpd is > >not inetd conform' because it's not true. This is a bigger issue than > >patching qmail - you cannot sell a qmail-solution without move a step back > >and check it's integrity. IMHO qmail itself is a robust server, without > >patches. Patches can add more functionality but more weaknesses too. I > >cannot belive in patches which are will remain just as patches. > > Don't patch qmail, use ucspi-tcp/daemontools. You can't blame Dan for, > after giving you a perfect solution, not being willing to make a poor > one slightly better. Well, you're right. I don't want to blame DJB, because he's a brilliant programmer. BTW I don't think this is a *perfect* solution. He made just the *best* solution. I just want to extend this to a *better* solution. Without the need of writing patches but with the help of Dan. He wrote qmail to be usable by almost everybody who knows his/her machine well and not for the ones who just pick up a package and install it without a base knowledge what s/he is doing. If you like inetd, use inetd. If you like xinetd, just use it. It's not the developer's choice but the administrator's. I (as a coder) don't want to be your sysadm. Be your own sysadmin. As you see, I merely want to respect my users' claims and want to keep the software as flexible as (possible || it was). [sorry for the precedence] PS I use ucspi-tcp and daemontools. My fellow sysadmins don't want to use them and they use procmail instead of Maildir, anyways. -- Regards: Kevin (Balazs)
On 18-May-99 Balazs Nagy wrote: > On Tue, 18 May 1999, Fred Lindberg wrote: > >> On Tue, 18 May 1999 17:35:09 +0200 (CEST), Balazs Nagy wrote: >> >> >Anyone who don't want to install ucspi-tcp. You cannot say 'qmail-smtpd is >> >not inetd conform' because it's not true. This is a bigger issue than >> >patching qmail - you cannot sell a qmail-solution without move a step back >> >and check it's integrity. IMHO qmail itself is a robust server, without >> >patches. Patches can add more functionality but more weaknesses too. I >> >cannot belive in patches which are will remain just as patches. >> >> Don't patch qmail, use ucspi-tcp/daemontools. You can't blame Dan for, >> after giving you a perfect solution, not being willing to make a poor >> one slightly better. > > Well, you're right. I don't want to blame DJB, because he's a brilliant > programmer. BTW I don't think this is a *perfect* solution. He made just > the *best* solution. > > I just want to extend this to a *better* solution. Without the need of > writing patches but with the help of Dan. > > He wrote qmail to be usable by almost everybody who knows his/her machine > well and not for the ones who just pick up a package and install it without > a base knowledge what s/he is doing. If you like inetd, use inetd. If you > like xinetd, just use it. It's not the developer's choice but the > administrator's. I (as a coder) don't want to be your sysadm. Be your own > sysadmin. Actually it extends into a support issue as well. There are regular issues that come up with inetd and tcpwrappers and a few other things and switching to tcpserver solves all of them and in a more robust fashion. So in this case it really is developer's choice. If you want to use an alternate method you'll find very little support. > As you see, I merely want to respect my users' claims and want to keep the > software as flexible as (possible || it was). [sorry for the precedence] > > PS I use ucspi-tcp and daemontools. My fellow sysadmins don't want to > use them and they use procmail instead of Maildir, anyways. Procmail and Maildir are two entirely different things. Procmail is a method of delivery, Maildir is not. I don't use either. Methinks you need to tell your "fellow sysadmins" they need to RTFM. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: [EMAIL PROTECTED] flame-mail: /dev/null # include <std/disclaimers.h> TEAM-OS2 Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
On Tue, 18 May 1999, Vince Vielhaber wrote: > Actually it extends into a support issue as well. There are regular issues > that come up with inetd and tcpwrappers and a few other things and switching > to tcpserver solves all of them and in a more robust fashion. So in this > case it really is developer's choice. If you want to use an alternate method > you'll find very little support. It's in the FAQ. What else do you want? BTW if someone wants to do something another way, maybe s/he knows the solution better. -- Regards: Kevin (Balazs)
On 18-May-99 Balazs Nagy wrote: > On Tue, 18 May 1999, Vince Vielhaber wrote: > >> Actually it extends into a support issue as well. There are regular issues >> that come up with inetd and tcpwrappers and a few other things and switching >> to tcpserver solves all of them and in a more robust fashion. So in this >> case it really is developer's choice. If you want to use an alternate method >> you'll find very little support. > > It's in the FAQ. What else do you want? BTW if someone wants to do something > another way, maybe s/he knows the solution better. > -- > Regards: Kevin (Balazs) > Not in this one: ftp://koobera.math.uic.edu/www/qmail/faq.html Support was dropped for inetd configurations a few months ago. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: [EMAIL PROTECTED] flame-mail: /dev/null # include <std/disclaimers.h> TEAM-OS2 Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
On Tue, 18 May 1999, Vince Vielhaber wrote: > Not in this one: ftp://koobera.math.uic.edu/www/qmail/faq.html Well, I don't check that faq requlary. I use the /var/qmail/doc/FAQ. > Support was dropped for inetd configurations a few months ago. Excusez moi, but you meant 'support was dropped *from the faq*' and not from qmail. Qmail 1.03 'is shipped' with inetd support. -- Regards: Kevin (Balazs)
On 18-May-99 Balazs Nagy wrote: > On Tue, 18 May 1999, Vince Vielhaber wrote: > >> Not in this one: ftp://koobera.math.uic.edu/www/qmail/faq.html > > Well, I don't check that faq requlary. I use the /var/qmail/doc/FAQ. > >> Support was dropped for inetd configurations a few months ago. > > Excusez moi, but you meant 'support was dropped *from the faq*' and not from > qmail. Qmail 1.03 'is shipped' with inetd support. You need to go back and check the mail archives. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: [EMAIL PROTECTED] flame-mail: /dev/null # include <std/disclaimers.h> TEAM-OS2 Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
On Tue, 18 May 1999, Vince Vielhaber wrote: > On 18-May-99 Balazs Nagy wrote: > > On Tue, 18 May 1999, Vince Vielhaber wrote: > > > >> Not in this one: ftp://koobera.math.uic.edu/www/qmail/faq.html > > > > Well, I don't check that faq requlary. I use the /var/qmail/doc/FAQ. > > > >> Support was dropped for inetd configurations a few months ago. > > > > Excusez moi, but you meant 'support was dropped *from the faq*' and not from > > qmail. Qmail 1.03 'is shipped' with inetd support. > > You need to go back and check the mail archives. Qmail IS shipped with inetd support through tcp-env. Look into a popular file called INSTALL: "16. Set up qmail-smtpd in /etc/inetd.conf (all on one line): smtp stream tcp nowait qmaild /var/qmail/bin/tcp-env tcp-env /var/qmail/bin/qmail-smtpd 17. Reboot. (Or kill -HUP your inetd and make sure the qmail daemons are running.)" /magnus -- "MOST USELESS site of the year 1998" --> http://x42.com/urlcalc/
On Wed, 19 May 1999, Magnus Bodin wrote: > On Tue, 18 May 1999, Vince Vielhaber wrote: > > On 18-May-99 Balazs Nagy wrote: > > > On Tue, 18 May 1999, Vince Vielhaber wrote: > > > > > >> Not in this one: ftp://koobera.math.uic.edu/www/qmail/faq.html > > > > > > Well, I don't check that faq requlary. I use the /var/qmail/doc/FAQ. > > > > > >> Support was dropped for inetd configurations a few months ago. > > > > > > Excusez moi, but you meant 'support was dropped *from the faq*' and not from > > > qmail. Qmail 1.03 'is shipped' with inetd support. > > > > You need to go back and check the mail archives. > > Qmail IS shipped with inetd support through tcp-env. Look into a popular file > called INSTALL: > > "16. Set up qmail-smtpd in /etc/inetd.conf (all on one line): > smtp stream tcp nowait qmaild /var/qmail/bin/tcp-env > tcp-env /var/qmail/bin/qmail-smtpd > > 17. Reboot. (Or kill -HUP your inetd and make sure the qmail daemons > are running.)" > > > /magnus > > I'll repeat myself only once more. Go back and check the mail archives. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: [EMAIL PROTECTED] flame-mail: /dev/null # include <std/disclaimers.h> TEAM-OS2 Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
I've installed qmailanalog on my mail gateway and ran zoverall against the last 81 days of mail stats. What I came up with leads me to question how well my machine is working. The hardware is a Sun Enterprise 250 with dual 300MHz UltraSPARC-II's, and 256MB of RAM running Solaris 7. What I am wondering about is the apparently long processing time for messages. According to these stats we are processing only ~2722 messages per day (~1.9 per minute) at ~23K each. Yet the average message queue time is 527 seconds?! Why would a message sit in the queue for so long with such a light load? Here's the numbers: Basic statistics qtime is the time spent by a message in the queue. ddelay is the latency for a successful delivery to one recipient---the end of successful delivery, minus the time when the message was queued. xdelay is the latency for a delivery attempt---the time when the attempt finished, minus the time when it started. The average concurrency is the total xdelay for all deliveries divided by the time span; this is a good measure of how busy the mailer is. Completed messages: 222628 Recipients for completed messages: 244706 Total delivery attempts for completed messages: 257266 Average delivery attempts per completed message: 1.15559 Bytes in completed messages: 5139085562 Bytes weighted by success: 5470767758 Average message qtime (s): 526.552 Total delivery attempts: 258538 success: 234138 failure: 10575 deferral: 13825 Total ddelay (s): 22274235.431068 Average ddelay per success (s): 95.132936 Total xdelay (s): 553004.573188 Average xdelay per delivery attempt (s): 2.138968 Time span (days): 81.7779 Average concurrency: 0.0782671 -- _________________________________________________________________ Mark E Drummond Royal Military College of Canada [EMAIL PROTECTED] Computing Services Linux Uber Alles perl || die
On Tue, 18 May 1999 11:22:11 -0400, Mark E Drummond wrote: >What I am wondering about is the apparently long processing time for >messages. According to these stats we are processing only ~2722 messages >per day (~1.9 per minute) at ~23K each. Yet the average message queue >time is 527 seconds?! Why would a message sit in the queue for so long >with such a light load? Here's the numbers: First, you have a very lightly loaded machine, and it's goofing off most of the time ;-) This explains the 1.9 messages/min. We've had qmail do 1000/min on simple hardware, admittedly with ideal recipients. The queue time includes deliveries that were repeatedly deferred (host unreachable, user over quota try later, etc) that then finally timed out their queue life time(something like 7 days). Thus, the average is not very useful. Average ddelay per success (s): 95.132936: This shows you that the delivery attempts that were successful took on average 95 s to complete. This does not count all the unsuccessful delivery attempts. Look at other stats in the package. The time taken to complete 50% or 80% of the deliveries or the average time for the first 50 or 80% is a much more useful measure. In summary, looks ok and the numbers are a reflection of the recipients, not your qmail installation. -Sincerely, Fred (Frederik Lindberg, Infectious Diseases, WashU, St. Louis, MO, USA)
Ok, I give up, what's a DSN?
Barton writes: > Ok, I give up, what's a DSN? Delivery Status Notice. It's an attempt to solve every possible problem related to email delivery, including bounces, delayed messages, vacation responses, and changes of email address. Unfortunately, it's so complicated that it hasn't had sufficient penetration to be really useful. -- -russ nelson <[EMAIL PROTECTED]> http://crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | Good parenting creates 521 Pleasant Valley Rd. | +1 315 268 1925 voice | an adult, not a perfect Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | child.
> From: Russell Nelson <[EMAIL PROTECTED]> > Date: 18 May 1999 15:47:26 -0000 > > Delivery Status Notice. It's an attempt to solve every possible > problem related to email delivery, including bounces, delayed > messages, vacation responses, and changes of email address. > Unfortunately, it's so complicated that it hasn't had sufficient > penetration to be really useful. Just to change the subject and to tie it into a previous thread, I'd like to point out that the lack of this characteristic is one of the reasons why both Fred L. and I were defending RFC2369 for list headers. Simplicity is good. Isn't there a quote along the line of "as simple as possible, but no simpler"? It wasn't about standards, but it should be. Chris -- Chris Garrigues virCIO +1 512 432 4046 4314 Avenue C O- http://www.DeepEddy.Com/~cwg/ Austin, TX 78751-3709 +1 512 374 0500 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.
Barton writes: > Ok, I give up, what's a DSN? Read RFC1891, RFC1892, RFC1893, and RFC1894. A standard format for a bounce message. Well, somewhat more than that. -- Sam
Russell Nelson writes: > Delivery Status Notice. It's an attempt to solve every possible > problem related to email delivery, including bounces, delayed > messages, vacation responses, and changes of email address. > Unfortunately, it's so complicated that it hasn't had sufficient > penetration to be really useful. DSNs are not that complicated. I'm coding a custom mail relay for internal use. Adding DSN support was not exactly trivial, but it wasn't a herculean effort either. It will take you several weeks to figure out what the RFCs are talking about, true, but that's pretty much the case with any RFC. Once the gory details sink into your skull, it's trivially easy to generate one, or parse one. -- Sam
Wait, do DSN's include return receipts for successfully delivered mail? --Adam ----- Original Message ----- From: Sam <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, May 18, 1999 12:17 PM Subject: Re: What's a DSN? : Barton writes: : : > Ok, I give up, what's a DSN? : : Read RFC1891, RFC1892, RFC1893, and RFC1894. : : A standard format for a bounce message. Well, somewhat more than that. : : -- : Sam : :
Adam D. McKenna writes: > Wait, do DSN's include return receipts for successfully delivered mail? DSNs are generic mail status notification format. A subset of that are bounces. Another subset is return receipt. A single DSN message may contain any notification, in fact, you can get a DSN message telling you that one of your receipients does not exist, and another receipient has received the same message. Also, facilities are provided for the sender to optionally select the suppression of DSNs, so you can send a message, and tell it that you don't want to receive any bounces at all. Optional facilities include returning a sender-assigned message identification token, so that the sender's mail software can identify which message in its archives a DSN is in response to, and also communicate back to the sender's mail software the original receipient address, before the address was rewritten by various mail gateways along the path. -- Sam
Hi Sorry if this is pretty basic... While doing "cat logneu | ./bin/matchup > log1" in /usr/local/qmailanalog I get the message: matchup: fatal: unable to write fd 5: file descriptor not open What's wrong? Is my ulimit too low?? Thanks Ralf
Ralf Guenthner wrote: > > Hi > > Sorry if this is pretty basic... > > While doing > > "cat logneu | ./bin/matchup > log1" in /usr/local/qmailanalog > > I get the message: > > matchup: fatal: unable to write fd 5: file descriptor not open > > What's wrong? Is my ulimit too low?? You forgot to redirect fd 5 to a file. Do this: cat logneu | ./bin/matchup >log1 5>log1.blah -- _________________________________________________________________ Mark E Drummond Royal Military College of Canada [EMAIL PROTECTED] Computing Services Linux Uber Alles perl || die
+ "Chris Garrigues" <[EMAIL PROTECTED]>: | Simplicity is good. Isn't there a quote along the line of "as | simple as possible, but no simpler"? Albert Einstein: "Everything should be made as simple as possible, but not simpler." or "Things should be made as simple as possible, but not any simpler." I found one version in two Einstein quote collections on the web, and the other in two others. Who knows which, if any (or both), is correct? But can be little doubt that he said something like it. - Harald
Maybe you mean "Non sunt entia multiplicanda praeter necessitatem." -- Sir William of Ockam (also known as "Ockam's razor")? -- Jos Backus _/ _/_/_/ "Reliability means never _/ _/ _/ having to say you're sorry." _/ _/_/_/ -- D. J. Bernstein _/ _/ _/ _/ [EMAIL PROTECTED] _/_/ _/_/_/ use Std::Disclaimer;
Grr. Sorry for the off-topic off-topic post, I should have _read_ Harald's post before replying... -- Jos Backus _/ _/_/_/ "Reliability means never _/ _/ _/ having to say you're sorry." _/ _/_/_/ -- D. J. Bernstein _/ _/ _/ _/ [EMAIL PROTECTED] _/_/ _/_/_/ use Std::Disclaimer;
hi, new to the list. I just installed qmail on my Solaris 2.6 box. It is running fine and bouncing messages. I can not however get anything out of it. No mail is appearing. it is not bouncing, it just doesn't seem to be going anywhere. thanks for the help. Brian. ------------------------------ http://brian.threadnet.com
ftp://koobera.math.uic.edu/www/docs/smtplf.html We've gotten ahold of the techs at zianet, and were trying to work this problem out. Everybodies hunch about the linefeeds was correct. The question is now how to fix it. He turned on an option in his mail program that basicly, as i understand it no longer allows the mail server to accept mail with bare linefeeds, so any new email that his server accepts will be rfc conforming. But he has 75MB of mail in the queue will stray linefeeds still. What would be the best way to get this mail to us? I thought maybee hacking a perl script to cure the problem, but what other suggestions are there? Also, is there patch to qmail to allow it to accept the bare linefeeds? _ __ _____ __ _________ ______________ /_______ ___ ____ /______ John Gonzalez/Net.Tech __ __ \ __ \ __/_ __ `__ \/ __ /_ ___/ MDC Computers/netMDC! _ / / / `__/ /_ / / / / / / /_/ / / /__ (505)437-7600/fax-437-3052 /_/ /_/\___/\__/ /_/ /_/ /_/\__,_/ \___/ http://www.netmdc.com [---------------------------------------------[system info]-----------] 3:40pm up 102 days, 22:43, 3 users, load average: 0.06, 0.09, 0.09
On Tue, 18 May 1999, John Gonzalez/netMDC admin wrote: > The question is now how to fix it. A very good answer is at the tips and advice section at http://www.qmail.org/top.html by Dan himself. A tricky and cool answer actually. -- Regards: Kevin (Balazs)
On Tue, May 18, 1999 at 11:09:18PM +0200, Balazs Nagy wrote: # On Tue, 18 May 1999, John Gonzalez/netMDC admin wrote: # # > The question is now how to fix it. # # A very good answer is at the tips and advice section at # http://www.qmail.org/top.html by Dan himself. A tricky and cool # answer actually. is that the fixcr pipe? one problem with that is that it doesn't terminate the session correctly, the socket never closes after the quit command is issued, at least on my Solaris box at iq-ss5.iquest.net port 80025 -- /- [EMAIL PROTECTED] --------------- [EMAIL PROTECTED] -\ |Justin Bell NIC:JB3084| Time and rules are changing. | |Pearson | Attention span is quickening. | |Developer | Welcome to the Information Age. | \-------- http://www.superlibrary.com/people/justin/ ----------/
On Mon, May 17, 1999 at 03:32:53PM +0300, Anand Buddhdev wrote: > On Mon, May 17, 1999 at 12:12:14PM +0200, Andre Oppermann wrote: > > I figured it out (I think). After you mentioned qmail-local.c I looked at > the source code. There, I found a file called conf-patrn, which defines what > modes qmail-local.c will tolerate on home directories. Correct. I think. Greetz, Peter -- | 'He broke my heart, | Peter van Dijk | I broke his neck' | [EMAIL PROTECTED] | nognikz - As the sun | Hardbeat@ircnet - #cistron/#linux.nl | | Hardbeat@undernet - #groningen/#kinkfm/#vdh |
Hello. I am a new user of Qmail, well setting up MTAs really. I have a problem where I have set up fastforward-0.51 with qmail-1.03. The situation involves setting up an alias for a user with the name of the form firstname.lastname. It seems that fastforward is unable to alias names of the form firstname.lastname. As well, I am trying to forward mail to Cyrus-1.5.19... My setup configuration is as follows. defaultdelivery/rc /usr/local/cyrus/bin/deliver $USER alias/.qmail.default | /var/qmail/bin/fastforward -d /etc/aliases.cdb /etc/aliases firstname.lastname: foobar fudge: foobar The qmail log file comes up with... delivery 7: deferral: firstname.lastname:_Mailbox_does_not_exist_ which seems to be a message from the cyrus delivery program. Why hasn't the Cyrus delivery program been told to deliver to 'foobar' and not firstname.lastname. Is it a problem with fastforward? I have read, searched and played with this problem but am unable to resolve it. Any advice is most welcome. Stephen farrugia -- email: [EMAIL PROTECTED] Addr: 8/318 Auburn Rd, Hawthorn East, Victoria 3123, Australia Ph: (+613) 9816 5417 Fax: (+613) 9819 4275 Web: www.zoomsystems.com
On Wed, 19 May 1999, Stephen Farrugia wrote: > Hello. > > I am a new user of Qmail, well setting up MTAs really. > > I have a problem where I have set up fastforward-0.51 with qmail-1.03. > The situation involves setting up an alias for a user with the name > of the form firstname.lastname. It seems that fastforward is unable to > alias names of the form firstname.lastname. > > As well, I am trying to forward mail to Cyrus-1.5.19... > > My setup configuration is as follows. > > defaultdelivery/rc > /usr/local/cyrus/bin/deliver $USER > > > alias/.qmail.default > | /var/qmail/bin/fastforward -d /etc/aliases.cdb This is your problem. By the time ~alias/.qmail-default gets the address the "." has been converted to a ":" but you can't use a ":" in /etc/aliases. (I tried.) Replace this with: ~alias/.qmail-default: | env DEFAULT=`echo $DEFAULT | tr ":" "."` /var/qmail/bin/fastforward -d |/etc/aliases.cdb (all on one line) This works perfectly for me. > > > /etc/aliases > firstname.lastname: foobar > fudge: foobar > > > The qmail log file comes up with... > delivery 7: deferral: firstname.lastname:_Mailbox_does_not_exist_ > which seems to be a message from the cyrus delivery program. > > Why hasn't the Cyrus delivery program been told to deliver to 'foobar' > and not firstname.lastname. Is it a problem with fastforward? > > I have read, searched and played with this problem but am unable to > resolve it. > > Any advice is most welcome. > > Stephen farrugia > > > > -- > email: [EMAIL PROTECTED] > Addr: 8/318 Auburn Rd, Hawthorn East, Victoria 3123, Australia > Ph: (+613) 9816 5417 > Fax: (+613) 9819 4275 > Web: www.zoomsystems.com > > > --------------------------------- Timothy L. Mayo mailto:[EMAIL PROTECTED] Senior Systems Administrator localconnect(sm) http://www.localconnect.net/ The National Business Network Inc. http://www.nb.net/ One Monroeville Center, Suite 850 Monroeville, PA 15146 (412) 810-8888 Phone (412) 810-8886 Fax
Thanks for your help Timothy. You provided the next crucial step in the total solution. "Timothy L. Mayo" wrote: > On Wed, 19 May 1999, Stephen Farrugia wrote: > > > Hello. > > > > I am a new user of Qmail, well setting up MTAs really. > > > > I have a problem where I have set up fastforward-0.51 with qmail-1.03. > > The situation involves setting up an alias for a user with the name > > of the form firstname.lastname. It seems that fastforward is unable to > > alias names of the form firstname.lastname. > > > > As well, I am trying to forward mail to Cyrus-1.5.19... > > > > My setup configuration is as follows. > > > > defaultdelivery/rc > > /usr/local/cyrus/bin/deliver $USER > > > > > > alias/.qmail.default > > | /var/qmail/bin/fastforward -d /etc/aliases.cdb > > This is your problem. By the time ~alias/.qmail-default gets the address > the "." has been converted to a ":" but you can't use a ":" in > /etc/aliases. (I tried.) Replace this with: > > ~alias/.qmail-default: > > | env DEFAULT=`echo $DEFAULT | tr ":" "."` /var/qmail/bin/fastforward -d >/etc/aliases.cdb > > (all on one line) > > This works perfectly for me. > It is also necessary to have an entry in users/assign of the following nature: +.+:alias:80:80://var/qmail/alias::: so that all users of with names firstname.lastname were processed by ~alias/.qmail-default Stephen -- email: [EMAIL PROTECTED] Addr: 8/318 Auburn Rd, Hawthorn East, Victoria 3123, Australia Ph: (+613) 9816 5417 Fax: (+613) 9819 4275 Web: www.zoomsystems.com
Hi, folks, I've got qmail installed on one of my Linux boxes which is intermittently connected via ppp. I've just got things set up, and there are a few more things to work out (such as the ficticious domain name for my 192.168. subnet with DNS/bind/8) But the main problem that I have is that I keep getting messages like this: May 18 20:58:50 moby qmail: 927075530.735790 starting delivery 45: msg 2067 to local [EMAIL PROTECTED] May 18 20:58:50 moby qmail: 927075530.737594 status: local 1/10 remote 0/20 May 18 20:58:50 moby qmail: 927075530.812095 delivery 45: deferral: Home_directory_is_sticky:_user_is_editing_his_.qmail_file._(#4.2.1)/ May 18 20:58:50 moby qmail: 927075530.813810 status: local 0/10 remote 0/20 So, I know about chmod +/-t ., but root home dir is -t and there is no .qmail file. Can anyone offer any help with this? -Eric. -- Eric Berg http://www.nylug.org/~eberg Vice President, New York Linux Users Group [EMAIL PROTECTED]
On Tue, May 18, 1999 at 07:58:57PM -0500, Eric Berg wrote: > Hi, folks, > > I've got qmail installed on one of my Linux boxes which is intermittently > connected via ppp. I've just got things set up, and there are a few more > things to work out (such as the ficticious domain name for my > 192.168. subnet with DNS/bind/8) > > But the main problem that I have is that I keep getting messages like this: > > May 18 20:58:50 moby qmail: 927075530.735790 starting delivery 45: msg 2067 to local >[EMAIL PROTECTED] > May 18 20:58:50 moby qmail: 927075530.737594 status: local 1/10 remote 0/20 > May 18 20:58:50 moby qmail: 927075530.812095 delivery 45: deferral: >Home_directory_is_sticky:_user_is_editing_his_.qmail_file._(#4.2.1)/ > May 18 20:58:50 moby qmail: 927075530.813810 status: local 0/10 remote 0/20 > > So, I know about chmod +/-t ., but root home dir is -t and there is no .qmail > file. qmail _never_ does _anything_ with root or root's homedir. root is handled by the alias user. Check /var/qmail/alias. It's probably sticky. Greetz, Peter -- | 'He broke my heart, | Peter van Dijk | I broke his neck' | [EMAIL PROTECTED] | nognikz - As the sun | Hardbeat@ircnet - #cistron/#linux.nl | | Hardbeat@undernet - #groningen/#kinkfm/#vdh |
On Tue, May 18, 1999 at 07:58:57PM -0500, Eric Berg wrote: > Hi, folks, > > I've got qmail installed on one of my Linux boxes which is intermittently > connected via ppp. I've just got things set up, and there are a few more > things to work out (such as the ficticious domain name for my > 192.168. subnet with DNS/bind/8) > > But the main problem that I have is that I keep getting messages like this: > > May 18 20:58:50 moby qmail: 927075530.735790 starting delivery 45: msg 2067 to local >[EMAIL PROTECTED] > May 18 20:58:50 moby qmail: 927075530.737594 status: local 1/10 remote 0/20 > May 18 20:58:50 moby qmail: 927075530.812095 delivery 45: deferral: >Home_directory_is_sticky:_user_is_editing_his_.qmail_file._(#4.2.1)/ > May 18 20:58:50 moby qmail: 927075530.813810 status: local 0/10 remote 0/20 > > So, I know about chmod +/-t ., but root home dir is -t and there is no .qmail > file. qmail-local will never run as root, so it'll never try to deliver to root's home directory. If anything is sticky in this case, it's ~alias. You might check ~alias for stickiness. Chris
Bingo! Thanks, Peter and Chris. BTW, this was my first post to the qmail list -- I've been a little bit anxious about getting help with qmail because this list isn't on dejanews -- my main resource -- but the qmail community definitely seems to live up to its reputation. Thanks again. See you later. -Eric. Peter van Dijk: [Wednesday 19-May]: > On Tue, May 18, 1999 at 07:58:57PM -0500, Eric Berg wrote: > > Hi, folks, > > > > I've got qmail installed on one of my Linux boxes which is intermittently > > connected via ppp. I've just got things set up, and there are a few more > > things to work out (such as the ficticious domain name for my > > 192.168. subnet with DNS/bind/8) > > > > But the main problem that I have is that I keep getting messages like this: > > > > May 18 20:58:50 moby qmail: 927075530.735790 starting delivery 45: msg 2067 to >local [EMAIL PROTECTED] > > May 18 20:58:50 moby qmail: 927075530.737594 status: local 1/10 remote 0/20 > > May 18 20:58:50 moby qmail: 927075530.812095 delivery 45: deferral: >Home_directory_is_sticky:_user_is_editing_his_.qmail_file._(#4.2.1)/ > > May 18 20:58:50 moby qmail: 927075530.813810 status: local 0/10 remote 0/20 > > > > So, I know about chmod +/-t ., but root home dir is -t and there is no .qmail > > file. > > qmail _never_ does _anything_ with root or root's homedir. root is handled > by the alias user. Check /var/qmail/alias. It's probably sticky. > > Greetz, Peter > -- > | 'He broke my heart, | Peter van Dijk | > I broke his neck' | [EMAIL PROTECTED] | > nognikz - As the sun | Hardbeat@ircnet - #cistron/#linux.nl | > | Hardbeat@undernet - #groningen/#kinkfm/#vdh | -- Eric Berg http://www.nylug.org/~eberg Vice President, New York Linux Users Group [EMAIL PROTECTED]
Hi all you qmail Guru's!!! I've got a problem! I recently had a HDD die on me, and it contained /var/qmail/queue so I replaced the hdd, and downloaded and have run queue-fix from the qmail.org website... Well, most mail is working well, but I've got the following errors in my log file... May 18 11:40:00 www qmail: 926991600.631622 info msg 168665: bytes 5998 from <[EMAIL PROTECTED]> qp 31124 uid 1005 May 18 11:40:00 www qmail: 926991600.696032 starting delivery 3: msg 168665 to local [EMAIL PROTECTED] May 18 11:40:00 www qmail: 926991600.696210 status: local 1/10 remote 0/20 May 18 11:40:00 www qmail: 926991600.709150 delivery 3: deferral: Unable_to_forward_message:_qq_trouble_creating_files_in_queue_(#4.3.0)./ May 18 11:40:00 www qmail: 926991600.709300 status: local 0/10 remote 0/20 BUT.... This is the weird bit...... mail to real users works fine without a problem: May 18 11:39:54 www qmail: 926991594.343741 new msg 168665 May 18 11:39:54 www qmail: 926991594.343894 info msg 168665: bytes 5995 from <[EMAIL PROTECTED]> qp 31119 uid 1005 May 18 11:39:54 www qmail: 926991594.399797 starting delivery 2: msg 168665 to local [EMAIL PROTECTED] May 18 11:39:54 www qmail: 926991594.399945 status: local 1/10 remote 0/20 May 18 11:39:54 www qmail: 926991594.445211 delivery 2: success: did_1+0+0/ May 18 11:39:54 www qmail: 926991594.445362 status: local 0/10 remote 0/20 Now the error message above seems to me to be a permissions error, so here are my qmail daemons and the user they are running under: qmaill 31100 0.0 0.2 840 300 p5 S 11:37 0:00 splogger qmail qmailq 31103 0.0 0.1 832 224 p5 S 11:37 0:00 qmail-clean qmailr 31102 0.0 0.1 836 232 p5 S 11:37 0:00 qmail-rspawn qmails 31099 0.0 0.2 884 268 p5 S 11:37 0:00 qmail-send root 31101 5.5 0.1 844 244 p5 R 11:37 0:18 qmail-lspawn ./Maildir/ and here is the permissions of the /var/qmail/queue directory: drwx------ 2 qmails qmail 1024 May 18 11:36 bounce drwx------ 25 qmails qmail 1024 May 18 11:36 info drwx------ 2 qmailq qmail 1024 May 18 11:42 intd drwx------ 25 qmails qmail 1024 May 18 11:36 local drwxr-x--- 2 qmailq qmail 1024 May 18 11:37 lock drwxr-x--- 25 qmailq qmail 1024 May 18 11:36 mess drwx------ 2 qmailq qmail 1024 May 18 11:42 pid drwx------ 25 qmails qmail 1024 May 18 11:36 remote drwxr-x--- 2 qmailq qmail 1024 May 18 11:42 todo Anybody got a idea what might be wrong... right now, I have about 2100 messages queuing up for delievery, and they keep mulitpling... we get errors about unable to inject bounce messages as well.... Thanks Justin Hammond Dynamx Australia http://www.dynam.ac [EMAIL PROTECTED]
Try again! -----Original Message----- From: Justin Hammond <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]> Date: Wednesday, May 19, 1999 12:26 PM Subject: Help: deferral: Unable_to_forward_message:_qq_trouble_creating_files_in_queue_(#4.3.0)./ >Hi all you qmail Guru's!!! > >I've got a problem! > >I recently had a HDD die on me, and it contained /var/qmail/queue >so I replaced the hdd, and downloaded and have run queue-fix from the >qmail.org website... > >Well, most mail is working well, but I've got the following errors in my log >file... > >May 18 11:40:00 www qmail: 926991600.631622 info msg 168665: bytes 5998 from ><[EMAIL PROTECTED]> qp 31124 uid 1005 >May 18 11:40:00 www qmail: 926991600.696032 starting delivery 3: msg 168665 >to local [EMAIL PROTECTED] >May 18 11:40:00 www qmail: 926991600.696210 status: local 1/10 remote 0/20 >May 18 11:40:00 www qmail: 926991600.709150 delivery 3: deferral: >Unable_to_forward_message:_qq_trouble_creating_files_in_queue_(#4.3.0)./ >May 18 11:40:00 www qmail: 926991600.709300 status: local 0/10 remote 0/20 > >BUT.... This is the weird bit...... mail to real users works fine without a >problem: > >May 18 11:39:54 www qmail: 926991594.343741 new msg 168665 >May 18 11:39:54 www qmail: 926991594.343894 info msg 168665: bytes 5995 from ><[EMAIL PROTECTED]> qp 31119 uid 1005 >May 18 11:39:54 www qmail: 926991594.399797 starting delivery 2: msg 168665 >to local [EMAIL PROTECTED] >May 18 11:39:54 www qmail: 926991594.399945 status: local 1/10 remote 0/20 >May 18 11:39:54 www qmail: 926991594.445211 delivery 2: success: did_1+0+0/ >May 18 11:39:54 www qmail: 926991594.445362 status: local 0/10 remote 0/20 > >Now the error message above seems to me to be a permissions error, so here >are my qmail daemons and the user they are running under: > >qmaill 31100 0.0 0.2 840 300 p5 S 11:37 0:00 splogger qmail >qmailq 31103 0.0 0.1 832 224 p5 S 11:37 0:00 qmail-clean >qmailr 31102 0.0 0.1 836 232 p5 S 11:37 0:00 qmail-rspawn >qmails 31099 0.0 0.2 884 268 p5 S 11:37 0:00 qmail-send >root 31101 5.5 0.1 844 244 p5 R 11:37 0:18 qmail-lspawn >./Maildir/ > >and here is the permissions of the /var/qmail/queue directory: > >drwx------ 2 qmails qmail 1024 May 18 11:36 bounce >drwx------ 25 qmails qmail 1024 May 18 11:36 info >drwx------ 2 qmailq qmail 1024 May 18 11:42 intd >drwx------ 25 qmails qmail 1024 May 18 11:36 local >drwxr-x--- 2 qmailq qmail 1024 May 18 11:37 lock >drwxr-x--- 25 qmailq qmail 1024 May 18 11:36 mess >drwx------ 2 qmailq qmail 1024 May 18 11:42 pid >drwx------ 25 qmails qmail 1024 May 18 11:36 remote >drwxr-x--- 2 qmailq qmail 1024 May 18 11:42 todo > >Anybody got a idea what might be wrong... right now, I have about 2100 >messages queuing up for delievery, and they keep mulitpling... we get errors >about unable to inject bounce messages as well.... > >Thanks > >Justin Hammond > >Dynamx Australia >http://www.dynam.ac >[EMAIL PROTECTED] >
Hello Everybody, This may seem to be a bit off-line subject. I used to work for a company which has On-line server in Japan. I have registered a couple of domain names for my Mail and WWW purposes. And i have been using that server for hosting my Mailboxes as well as DNS record. Now since i have left that company some time ago, i can not continue to keep my mailboxes there. Could someone suggest me where can i find On-line server, where I can maintain my DNS record (MX and other) as well as have a mailbox, where all mails to my address like [EMAIL PROTECTED] and [EMAIL PROTECTED] be delivered to my mailbox. Earlier in the server we have qmail and i used to maintain MX records for PRADHAN.ORG.NP and used Virtual domains to get all the mail messages delivered to the mailbox using: pradhan.org.np:pradhan .pradhan.org.np:pradhan As i have a couple of domains to maintain, please suggest me where i can find such servers ( companies) who can provide me a mailbox for a cheapest cost. Any help and suggestion is appreciated. Thank in Advance, Manohar Pradhan Nepal
