RE: Humorous
> -Original Message-
> From: Greg Kopp [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, September 20, 2000 10:53 AM
> To: Chris Johnson; [EMAIL PROTECTED]
> Subject: RE: Humorous
>
>
> It's too bad that the article was somewhat accurate. Although
> I cannot say
> that I have experienced the same kind of treatment, I have
> seen it, and it
> is deplorable. I don't pretend I am an expert on qmail, but I
> have been
> successful with several installations of it. Maybe I've been lucky.
>
Unfortunately, the qmail list wants to just be a discussion for high-level/
difficult qmail problems, and not a hand-holding/question-redirect list.
What's unfortunate about it? There aren't really any other forums for the
discussion.
Is there a solution? Well, the obvious one is to allow people to ask
newbieish
questions without being flamed. Even though qmail is logical, it's complex;
just because something is logical and coherent, doesn't mean it's
comprehensible.
Quantum physics theory is even more elegant, but considerably less
comprehensible.
But I understand that many people don't want the list inundated and their
mailboxes
invaded. I think that's perfectly reasonable. So, is there any alternative?
In fact, there are several. I think the best is to create a qmail newsgroup,
as that's
the perfect forum for both newbieish and slightly less newbieish discussion.
Contrary
to the opinions that were stated when a newsgroup was recently proposed
(first week of
June), I don't think a newsgroup would unnecessarily or improperly infringe
upon the
mailing list; rather, the mailing list would remain as a high-quality, low
volume
discussion of complex or arcane or theoretical qmail issues.
Another alternative that I find less appealing but perhaps more qmailian is
to create
another mailing list that expressly handles such qmail problems, like
[EMAIL PROTECTED]
or the such. Or maybe a whole host of mailing lists. Modularize the list!
I hope this isn't improper, but I'm attaching below my earlier post in
support of
comp.mail.qmail.
>
> On Wed, May 31, 2000 at 08:36:43AM -0400, Russell Nelson wrote:
>
> > I agree with you in general, Russ. The only benefit I can see to
> > comp.mail.qmail is that there is also a comp.mail.sendmail.
>
> The impression I gain is that reception amidst vocal
> qmail advocates is at best lukewarm. How many replied ?
> 4 or 5 on a list containing upwards of 800 list members.
Though I didn't comment, especially as I am not yet seasoned,
I want to state that I am in favor of comp.mail.qmail. I
intended my silence to be interpreted as implicit agreement
with the idea of forming the group; as it seemed that the RFD
would likely be presented to the news.groups, I didn't see
where my words would be particularly necessary.
Now, can I justify my position of wanting the newsgroup?
The primary arguments I found against the formation of
comp.mail.qmail are 1) The current situation is fine;
2) a newsgroup would take traffic away from the mailing
list 3) Usenet is Useless! (i.e. it used to be better than
mailing lists, now its not).
I don't personally see 1) as a real argument against the formation
of the newsgroup, unless it's coupled with 2). Yes, the current
situation is good, but it could be better.
2) is a slightly strange one. I'd actually like traffic on the
qmail list to go down, or more, stay where it is. Mailing lists
are good for small, relatively closed communities; ones that I
subscribe to include the excellent libwww-perl which is mainly
trafficked by the module owners, plus some newbie-q traffic.
Higher volume lists like the WWWAC list and Perl-Win-32-Web are
a pretty big mess.
3) Usenet needs updating. I've got some ideas on that, and anyone
who is interested in some bold ideas for shaking up the newsgroups
should drop me a line. However, I still think it's better than
mailing lists for a number of reasons, the first being threading.
Also, when traffic gets high, then newsgroups are clearly are
more rational option, as fewer copies of the messages are sent out.
Etc. etc.
These rejoinders offer some reasons for a newsgroup, but I want to
add that in my opinion, qmail is at the stage where a newsgroup is
appropriate. It's well-documented and tested, and I do expect it
to supplant sendmail over time. A newsgroup not only allows the
qmail community to grow gracefully, but it also serves as an excellent
advertisement for qmail. ("sendmail has its own newsgroup, but qmail
doesn't. Hmm, guess qmail isn't really ready/well supported/well
advocated.")
I hope there are some points here that seem to make sense.
Bounce handling: newbie
I know this is a newbie-esque q, but what's the best way of knowing what the intended email address was on a bounce? I know there are VERPs and QSBF involved, but I'm not sure where to go next. My basic understanding is that the best way is to have outgoing messages have a special Return-Path header so that you have the headers To: [EMAIL PROTECTED] From: [EMAIL PROTECTED] Return-Path: [EMAIL PROTECTED] Is that a VERP? Once that's been set up, then what? Are the MAILER-DAEMON "failure notice" messages useful? Here's specifics: I run a specially configured moderated mailing list, and don't really want to try to use ezmlm because the current setup functions (but needs to be improved). (For example, people can't subscribe to the list by sending a request to the list.) There's a server that handles the database of subscribers and incoming mail. (list.com) I'm using perl to handle incoming messages. (A basic NT SMTP server receives them and dumps them in a folder.) There's a FreeBSD server whose only purpose is to run qmail to send outgoing mail. (qmailer.backend.com). When a message needs to be sent off, list.com hands off the messages to qmailer.backend.com. No problem, everything cool. Then list.com gets all the [EMAIL PROTECTED] bounce messages (and all the other bounce messages, like AOL's bounce). I want to unsubscribe the bounces. (Is there any reason I shouldn't?) My guess is that ezmlm's bounce handler is the best method, but what exactly is it? I know it sends out a probe, but what's the mechanism for emulating that behavior? Is just grepping the MAILER-DAEMON messages for the QSBF a reasonable option? It seems like there should be a better way.
Bounce handling--VERP
What's the best way to build a bounce-handling capability in coordination with qmail? What are the proper source files to look at in ezmlm to discover how it does it? The qmail-ezmlm bounce picture would be helpful, something in higher detail than "ezmlm uses qmail's VERPs to send a bounce-probe and unsubscribe" I'm not necessarily interested in using ezmlm, but I'll also ask this question on the ezmlm list. Brad Johnson [EMAIL PROTECTED]
FW: Help with overwhelmed system
Hi; I'm running qmail on freebsd on a HP Vectra with 64megs of RAM and running into what I'm sure is a stupid and avoidable problem. I was sending out about 100,000 messages through the box. It churned through about 50,000, but with the queue at around 35,000, it started choking and stopped accepting new messages: May 9 09:55:36 free /kernel: pid 191 (qmail-send), uid 87 on /var: out of inodes May 9 09:55:36 free qmail: 957866136.697686 alert: unable to append to bounce message; HELP! sleeping... May 9 09:55:46 free /kernel: pid 191 (qmail-send), uid 87 on /var: out of inodes May 9 09:55:46 free qmail: 957866146.705195 alert: unable to append to bounce message; HELP! sleeping... May 9 09:55:56 free /kernel: pid 191 (qmail-send), uid 87 on /var: out of inodes May 9 09:55:56 free qmail: 957866156.715425 alert: unable to append to bounce message; HELP! sleeping... May 9 09:56:06 free /kernel: pid 191 (qmail-send), uid 87 on /var: out of inodes May 9 09:56:06 free qmail: 957866166.728117 alert: unable to append to bounce message; HELP! sleeping... Filesystem 1K-blocks UsedAvail Capacity iused ifree %iused Mounted on /dev/wd0s1a29766380875 19297530%1043 73835 1% / /dev/wd0s1f 1599187 404570 106668327% 65823 33564716% /usr /dev/wd0s1e396895 121201 24394333% 99832 6 100% /var procfs 440 100% 28 504 5% /proc This is what I suspect I need to do. 1) Add more memory to the box. I know how to do this. 2) Get qmail working concurrently. I know how to do this: qmail FAQ 8.1 3) Set an inode limit on qmailq (??) I don't know if I should do this and I don't know how to do this. 4) Fix the filesystem somehow. Something like increasing the # of available inodes, partitioning? I don't know how to do this. I know this is semi-off-topic. 5) do the the "Patches for high-volume servers" http://qmail.org/top.html#large I'm not sure if this would be necessary. Maybe 1-4 (or something else?) would be sufficient.
RE: Purpose of this list
> -Original Message- > From: Eric Cox [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, May 17, 2000 10:14 PM > To: [EMAIL PROTECTED] > Subject: Re: Purpose of this list > > I think the reason repeated rtfm-style questions are so frustrating > (for me, anyway) is that qmail itself has some of the best "newbie" > documentation I think I've ever seen - it's all of the "do this, > then this, then this" variety - which was extremely friendly to me > the first time I installed qmail. Whether it was DJB, or whoever > wrote it went to great pains to aim it straight at the newbie. I > didn't even need Dave's excellent LWQ the first time I installed > it - and that reflects far more on the person that wrote the > INSTALL.* files than my mediocre prowess as an admin. > I'd just like to say that the qmail documentation is brilliant. Because of that, I myself have come upon the problem of knowing more about qmail than *nix administration; setting up qmail has been my first task as a freebsd admin. Thus the qmail docs break down where they assume knowledge of *nix stuff--which isn't really a fault of qmail. However, qmail does suffer from the same issue as BSD traditionally has, which is that everyone involved is too damned smart, so they write in terse, dense and frighteningly useful language and get annoyed when people have difficulty parsing the information. The qmail.org page is also a bit confusing. It would be nice if the main answers pages were organized together: Life With qmail, the qmail HOWTO, and the qmail man pages. They're all listed under User-Contributed Documentation, but they're mixed along with a whole bunch of other more specialized links. There's just a little bit TOO much info on the qmail.org page; it would be nice if it were separated out a bit. I only just looked at the "big picture" link, which is immensely useful. I didn't click on it, because I generally avoid links in the middle of a paragraph if I'm looking for particular information, especially a paragraph with a lot of links. If there were a quick meta-manual, which listed and described the most-important manual/documentation links, that would be extremely useful. If it exists, then it should be one of the #1 links on the qmail.org page. The other section that doesn't exist (or does it? It's not easy to find) is "Qmail for users" which would talk about qmail just from the perspective of the *nix user, with the userland commands, without mixing it all in with the admin info.
RE: Purpose of this list
> From: Dave Sill [mailto:[EMAIL PROTECTED]] > > Brad Johnson <[EMAIL PROTECTED]> wrote: > > >However, qmail does suffer from the same issue as BSD traditionally > >has, which is that everyone involved is too damned smart, so they > >write in terse, dense and frighteningly useful language and get > >annoyed when people have difficulty parsing the information. > > I worked hard to make "Life with qmail" newbie-friendly, and I try > hard to be newbie-friendly on this list. If you have specific > constructive suggestions on how I can improve either, please let me > know. > I purposely didn't want the above to sound like a criticism; that's why it was contained within tags. It's meant to praise you with faint damnation: "too damned smart" and "frighteningly useful" is not meant to be an effective insult. However, I don't think it's unreasonable to draw an analogy between qmail and BSD; even though qmail came after sendmail and BSD before Linux, the language used by qmailers to describe sendmail is heavily reminiscent of the language used by BSDers to describe Linux; also, qmail shares many basic goals with BSD (security,clean code,superiority). I think that qmail is more like Linux in that qmail seems destined to replace sendmail over time as the dominant MTA. All IMHO. I think I was trying to say that reasonable people can be confused by qmail, just because it's a very powerful and complex program, not because it's poorly documented. There's no way to make building a mile-long bridge simple and easy; there's no way to make building a robust, secure and flexible MTA simple and easy. That said, I'd say that qmail and the qmail community comes as close as possible to that goal. In other words, qmail is pretty damn newbie friendly, even though it's an impossible task. Suggestions: the qmail.org page should highlight "Life with qmail" and the other generally useful documents. It's buried near the bottom of the User-Contributed Documentation page, below broken links to Michael Samuel and a bunch of specialty documentations. I also sent a bunch of hopefully useful suggestions/tweaks for "Life" to Dave.
RE: DRAFT RFD - comp.mail.qmail - Comments Sought (Was: qmail advocacy questions)
>
> On Wed, May 31, 2000 at 08:36:43AM -0400, Russell Nelson wrote:
>
> > I agree with you in general, Russ. The only benefit I can see to
> > comp.mail.qmail is that there is also a comp.mail.sendmail.
>
> The impression I gain is that reception amidst vocal
> qmail advocates is at best lukewarm. How many replied ?
> 4 or 5 on a list containing upwards of 800 list members.
Though I didn't comment, especially as I am not yet seasoned,
I want to state that I am in favor of comp.mail.qmail. I
intended my silence to be interpreted as implicit agreement
with the idea of forming the group; as it seemed that the RFD
would likely be presented to the news.groups, I didn't see
where my words would be particularly necessary.
Now, can I justify my position of wanting the newsgroup?
The primary arguments I found against the formation of
comp.mail.qmail are 1) The current situation is fine;
2) a newsgroup would take traffic away from the mailing
list 3) Usenet is Useless! (i.e. it used to be better than
mailing lists, now its not).
I don't personally see 1) as a real argument against the formation
of the newsgroup, unless it's coupled with 2). Yes, the current
situation is good, but it could be better.
2) is a slightly strange one. I'd actually like traffic on the
qmail list to go down, or more, stay where it is. Mailing lists
are good for small, relatively closed communities; ones that I
subscribe to include the excellent libwww-perl which is mainly
trafficked by the module owners, plus some newbie-q traffic.
Higher volume lists like the WWWAC list and Perl-Win-32-Web are
a pretty big mess.
3) Usenet needs updating. I've got some ideas on that, and anyone
who is interested in some bold ideas for shaking up the newsgroups
should drop me a line. However, I still think it's better than
mailing lists for a number of reasons, the first being threading.
Also, when traffic gets high, then newsgroups are clearly are
more rational option, as fewer copies of the messages are sent out.
Etc. etc.
These rejoinders offer some reasons for a newsgroup, but I want to
add that in my opinion, qmail is at the stage where a newsgroup is
appropriate. It's well-documented and tested, and I do expect it
to supplant sendmail over time. A newsgroup not only allows the
qmail community to grow gracefully, but it also serves as an excellent
advertisement for qmail. ("sendmail has its own newsgroup, but qmail
doesn't. Hmm, guess qmail isn't really ready/well supported/well
advocated.")
I hope there are some points here that seem to make sense.
> I don't accept the "there's a comp.mail.sendmail so
> yeh, there should be a comp.mail.qmail" argument, as I
> think it is plainly flawed, and will be shot to death
> on news.groups.
>
> This 'thread' started in 1998, when I asked some simple
> advocacy questions viz. who is using qmail ? ISPs etc.
> I note that the www.qmail.org webmaster, later amended
> some of the replies, and put them on the web page. Good. This
> kind of information gives people useful insight.
>
> I originally suggested firmly I would post the RFD formally
> this week, or thereabouts. I'll re-phrase that as, I'll
> "try again here in 15 months' time, to see if there is interest".
> That's being prudent about things and qmail is a prudent MTA.
>
> Meantime, some of you may be interested in the alt.*
> newsgroup alt.comp.mail.qmail (newgrouped 27 Feb 2000).
> If your ISP does not carry this group, and you'd like
> access to it, one usually writes to [EMAIL PROTECTED],
> or your usual support contact asking "please add ..."
>
> I would also suggest a
