qmail Digest 18 Feb 1999 11:00:01 -0000 Issue 555
Topics (messages 22092 through 22138):
file names = inodes : why?
22092 by: [EMAIL PROTECTED]
22099 by: Peter Green <[EMAIL PROTECTED]>
22100 by: Mate Wierdl <[EMAIL PROTECTED]>
22102 by: Peter van Dijk <[EMAIL PROTECTED]>
22103 by: Mate Wierdl <[EMAIL PROTECTED]>
22104 by: Greg Hudson <[EMAIL PROTECTED]>
22105 by: Harald Hanche-Olsen <[EMAIL PROTECTED]>
22107 by: David Villeger <[EMAIL PROTECTED]>
22122 by: Mark Delany <[EMAIL PROTECTED]>
Qmail for NT
22093 by: Peter van Dijk <[EMAIL PROTECTED]>
Qmail mailing list and ReplyTo:
22094 by: Mate Wierdl <[EMAIL PROTECTED]>
22095 by: Peter van Dijk <[EMAIL PROTECTED]>
22097 by: Peter Green <[EMAIL PROTECTED]>
22120 by: Kai MacTane <[EMAIL PROTECTED]>
22123 by: Bruno Wolff III <[EMAIL PROTECTED]>
22124 by: Kai MacTane <[EMAIL PROTECTED]>
22126 by: Tim Pierce <[EMAIL PROTECTED]>
22127 by: Peter Green <[EMAIL PROTECTED]>
22130 by: Russell Nelson <[EMAIL PROTECTED]>
Email addresses containg . ; eg <name>.<surname>@domain.net
22096 by: [EMAIL PROTECTED]
22098 by: Mate Wierdl <[EMAIL PROTECTED]>
Qmail Documentation (was addresses containing . )
22101 by: [EMAIL PROTECTED] (Chris Naden)
22108 by: [EMAIL PROTECTED]
22110 by: [EMAIL PROTECTED] (Chris Naden)
22125 by: Peter van Dijk <[EMAIL PROTECTED]>
22129 by: Scott Schwartz <[EMAIL PROTECTED]>
22131 by: Russell Nelson <[EMAIL PROTECTED]>
Moving post office to qmail
22106 by: Chris Nelson <[EMAIL PROTECTED]>
22109 by: Andre Oppermann <[EMAIL PROTECTED]>
AutoTURN
22111 by: Carles Latorre <[EMAIL PROTECTED]>
22112 by: Chris Johnson <[EMAIL PROTECTED]>
Prodigy Internet Postmaster: UNSOLICITED EMAIL ([EMAIL PROTECTED])
22113 by: Mate Wierdl <[EMAIL PROTECTED]>
Maildir
22114 by: Mark Zugsmith <[EMAIL PROTECTED]>
22115 by: Chris Johnson <[EMAIL PROTECTED]>
22136 by: [EMAIL PROTECTED] (Mirko Zeibig)
same user name in different virtual domain ????
22116 by: <[EMAIL PROTECTED]>
22117 by: Chris Johnson <[EMAIL PROTECTED]>
22118 by: <[EMAIL PROTECTED]>
22119 by: Roger Walker <[EMAIL PROTECTED]>
22121 by: Chris Johnson <[EMAIL PROTECTED]>
two copies (was Re: Qmail mailing list and ReplyTo:)
22128 by: Scott Schwartz <[EMAIL PROTECTED]>
New Configuration--Partition size
22132 by: MountaiNet Tech Support <[EMAIL PROTECTED]>
22134 by: "Justin M. Streiner" <[EMAIL PROTECTED]>
Script Question
22133 by: "Peter Samuel" <[EMAIL PROTECTED]>
No incoming mail
22135 by: Bill Hults <[EMAIL PROTECTED]>
Qmail (as seen on a not so good day).
22137 by: Jere Cassidy <[EMAIL PROTECTED]>
22138 by: Jere Cassidy <[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]
----------------------------------------------------------------------
On Wed, 17 Feb 1999, Brian Reichert wrote:
> On Wed, Feb 17, 1999 at 01:18:33PM +1100, Mark Delany wrote:
> > >Is the inode just a handy unique number? Or are there file access
> > >speed tricks, e.g. opening files directly using inode.
> >
> > Handy unique filename. Vastly superior to tmpnam() and all the lame
> > variants that go with it.
I often wondered why Dan chose to do queue filenames by inode, but use
timestamp-pid-host for creating unique filenames within a maildir. Then I
remembered that qmail-queue is a long-running daemon and so will have the
same pid for long periods of time. It seems that there ought to be
another piece of information that could be used to make a similar filename
unique, without going through tmpnam. I suppose you could even use
timestamp-inode. There are two reasons I can think of for this change: 1)
it makes the queue portable, which isn't very important, and 2) it makes
message identifiers which are valid for long periods of time. The latter
makes it much easier to look through logs for a particular message. It
shouldn't be much slower; it should only cost an extra time(2) call, as
you already need a stat to get the inode.
Just a suggestion.
> > It's not for speed - excepting speed of creating a unique filename.
>
> I seem to recall the inode numbers biting people who were copying
> filesystems (backups, changing disks). If your assertions are
> correct, wouln't it make some sense to come up with some other
> cheap unique filename?
>
> --
> Brian 'you Bastard' Reichert [EMAIL PROTECTED]
> 37 Crystal Ave. #303 Current daytime number: (603)-434-6842
> Derry NH 03038-1713 USA Intel architecture: the left-hand path
>
--
"Life is much too important to be taken seriously."
Thomas Erskine <[EMAIL PROTECTED]> (613) 998-2836
On Wed, 17 Feb 1999, Mark Delany wrote:
> At 02:26 AM 2/17/99 -0500, Brian Reichert wrote:
> >I seem to recall the inode numbers biting people who were copying
> >filesystems (backups, changing disks). If your assertions are
> >correct, wouln't it make some sense to come up with some other
> >cheap unique filename?
[...]
> An alternative to your suggestion is to alert people to this dependency and
> write a few tools/scripts to assist on those rare occassions that people need
> to migrate or restore.
I've run into this problem in the past. One visit to the qmail home page,
search on "queue", and I found queue-fix. It does exactly what Mark is
describing above (in addition it saves the mail admin's butt). One more
reason I'm thoroughly happy with qmail...
/pg
--
Peter Green
Gospel Communications Network, SysAdmin
[EMAIL PROTECTED]
On Wed, 17 Feb 1999, Mark Delany wrote:
> At 02:26 AM 2/17/99 -0500, Brian Reichert wrote:
> >I seem to recall the inode numbers biting people who were copying
> >filesystems (backups, changing disks). If your assertions are
> >correct, wouln't it make some sense to come up with some other
> >cheap unique filename?
[...]
> An alternative to your suggestion is to alert people to this dependency and
> write a few tools/scripts to assist on those rare occassions that people need
> to migrate or restore.
I've run into this problem in the past. One visit to the qmail home page,
search on "queue", and I found queue-fix. It does exactly what Mark is
describing above (in addition it saves the mail admin's butt). One more
reason I'm thoroughly happy with qmail...
As for saving sysadms butt: the program Ghost can back up block by
block a whole harddisk. Then you can reghost the whole thing to a
harddisk of the same size. I know this is not the best solution, but
if you have serious mail traffic, you might have qmail on a separate
disk...
This works really well for us here.
Mate
On Wed, Feb 17, 1999 at 08:16:35AM -0500, [EMAIL PROTECTED]
wrote:
> On Wed, 17 Feb 1999, Brian Reichert wrote:
>
> > On Wed, Feb 17, 1999 at 01:18:33PM +1100, Mark Delany wrote:
> > > >Is the inode just a handy unique number? Or are there file access
> > > >speed tricks, e.g. opening files directly using inode.
> > >
> > > Handy unique filename. Vastly superior to tmpnam() and all the lame
> > > variants that go with it.
>
> I often wondered why Dan chose to do queue filenames by inode, but use
> timestamp-pid-host for creating unique filenames within a maildir. Then I
> remembered that qmail-queue is a long-running daemon and so will have the
> same pid for long periods of time. It seems that there ought to be
> another piece of information that could be used to make a similar filename
> unique, without going through tmpnam. I suppose you could even use
> timestamp-inode. There are two reasons I can think of for this change: 1)
> it makes the queue portable, which isn't very important, and 2) it makes
> message identifiers which are valid for long periods of time. The latter
> makes it much easier to look through logs for a particular message. It
> shouldn't be much slower; it should only cost an extra time(2) call, as
> you already need a stat to get the inode.
Yeah well.. what will you do with several messages per second? Even with usec
precision, there is a (very) small chance that you'll generate the same name
twice, which is unacceptable.
Hmm.. timestamp.qmail-queue pid.qmail-queue internal counter perhaps?
Greetz, Peter.
Yeah well.. what will you do with several messages per second? Even with usec
precision, there is a (very) small chance that you'll generate the same name
twice, which is unacceptable.
Hmm.. timestamp.qmail-queue pid.qmail-queue internal counter perhaps?
Greetz, Peter.
Well, the qmail log entries are generated using a timestamp accurate
to microseconds.
Mate
Mark Delany <[EMAIL PROTECTED]> wrote:
> Possibly. What do you propose? The current method guarantees a
> unique file name first time, every time. Since it's needed for every
> new mail, you want it to be efficient, right?
Not a very good argument. If some other technique gets a unique
filename the first time with 1-epsilon probability, then the
performance difference will be negligible. Having to handle more
conditions, though undesirable, does not imply significantly reduced
performance.
- [EMAIL PROTECTED]:
| Then I remembered that qmail-queue is a long-running daemon and so
| will have the same pid for long periods of time.
You are confused. qmail-queue runs once per injected message. Its
pid is reported, for example by qmail-smtpd as qp:
ok 915060448 qp 17770
qmail-send also prints this information for the log.
Provided the clock is never set back, and the pid counter cannot
repeat within one second, the combination of these two numbers
(timestamp and qp) would generate a suitable unique identifier.
The advantage of using the inode number is twofold: It's shorter (fits
in 32 bits), and it works even without the above two preconditions.
This discussion isn't all that interesting anyhow; I can hardly
imagine Dan bothering to change this in qmail 1.x, and qmail 2 will
have a totally different queue structure anyway, so the point is moot.
- Harald
At 03:00 PM 2/17/99 +0100, Peter van Dijk wrote:
>> I often wondered why Dan chose to do queue filenames by inode, but use
>> timestamp-pid-host for creating unique filenames within a maildir. Then I
>> remembered that qmail-queue is a long-running daemon and so will have the
>> same pid for long periods of time. It seems that there ought to be
No, qmail-queue is not a long running daemon. It runs every time it is
called by qmail-inject.
But you certainly have a point, condidering that qmail-queue does exactely
what you suggest:
qmail-queue creates a temporary file named timestamp-pid-sequence in the
pid directory, then gets the inode number and uses it as a unique name (if
I'm not mistaken).
So why does it have to change the name to an inode number instead of using
the original name (guaranteed to be unique too)? Maybe to have a 32 bit
wide number in a consistent manner?
David.
As Harold said in another part of this thread, it may well be moot by 2.0.
At 09:49 AM 2/17/99 EST, Greg Hudson wrote:
>Mark Delany <[EMAIL PROTECTED]> wrote:
>> Possibly. What do you propose? The current method guarantees a
>> unique file name first time, every time. Since it's needed for every
>> new mail, you want it to be efficient, right?
>
>Not a very good argument. If some other technique gets a unique
>filename the first time with 1-epsilon probability, then the
>performance difference will be negligible. Having to handle more
>conditions, though undesirable, does not imply significantly reduced
>performance.
I'm not sure I was presenting an argument. I see that a simple, safe and
efficient method has been used to generate a unique file name. You think a
more complex method with failure detection code and "negligible" performance
costs is better because you can move the queue without thinking.
Is should come as no surprise that Dan traded off complexity and occassional
inconvenience for simple, smaller and safe. Especially in code paths that:
a) manage internal, short-lived structures (contrast with Maildir)
b) occur in multiples of concurrency settings
c) create an inconvenience on rare occassions only
d) create an inconvenience that can be mitigated relatively easily with
out-of-band code
It will likewise come as no surprise to long-time watchers if the difference
is a single line of code.
Given that it's not my code I tend to simply explain the choices as I
understand them rather than argue about them.
Regards.
On Wed, Feb 17, 1999 at 09:16:47AM +0100, Rok Papez wrote:
> On Tue, 16 Feb 1999 23:51:17 +0100 (MET), Stefan Paletta wrote:
>
> >I don't know for sure (FATfs at least hasn't).
> >The question is rather, does cygwin have inode numbers?
> >I just tried (on 95) and "ls -i" reports something reasonable.
>
> All FSs have a unique ID for a smallest allocation block they can
> allocate. FAT does *not* have an inode number, but it *has* cluster
> number; cluster number is unique just in the same way as inode
> number.
Until DEFRAG runs, that is.
Greetz, Peter.
[sigless]
Hi!
Why doesn't Qmail mailing list set the
Reply To: field to "[EMAIL PROTECTED]".
It is very anoying that I must type the
mailing list address for every message
I respond to.
What if a poster is not a subscriber? he would set the reply-to field
to his personal address.
Look up your MUAs doc, and see how you can reply to the addresses in
the cc or to fields.
Mate
On Wed, Feb 17, 1999 at 11:52:26AM +0300, Roman V. Isaev wrote:
> On 02/17, Rok Papez wrote:
>
> > Why doesn't Qmail mailing list set the
> > Reply To: field to "[EMAIL PROTECTED]".
> > It is very anoying that I must type the
> > mailing list address for every message
> > I respond to.
>
> Touchy question. As listowner, I can say Reply-To brings more
> harm than good: people tend to forget about it and post private
> messages to the list. Very embarassing, and sometimes leads to
> THE conflict (I saw some).
Auto-responders also wreak havoc on lists with Reply-To set.
Greetz, Peter.
> Why doesn't Qmail mailing list set the
> Reply To: field to "[EMAIL PROTECTED]".
> It is very anoying that I must type the
> mailing list address for every message
> I respond to.
Check out http://www.unicom.com/pw/reply-to-harmful.html for a great
reason *not* to set the Reply-To: header. Any reasonable mailer should
have some sort of "reply to (l)ist, (s)ender, (b)oth" option.
/pg
--
Peter Green
Gospel Communications Network, SysAdmin
[EMAIL PROTECTED]
At 08:32 AM 2/17/99 -0500, Peter Green wrote:
>Check out http://www.unicom.com/pw/reply-to-harmful.html for a great
>reason *not* to set the Reply-To: header. Any reasonable mailer should
>have some sort of "reply to (l)ist, (s)ender, (b)oth" option.
And also see the discussion forum that's linked to at the bottom of that
essay for some differing opinions. One of the more common responses is that
without munging, people who hit "Reply to All" in their MUA then need to
trim or cull the To: and Cc: fields to remove all other email addresses;
otherwise, people will get multiple copies of replies to their own posts.
Oddly enough, I have seen quite a few messages on this list start off with
things like "Please don't cc: me, I'm on the list." I strongly suspect that
these illustrate instances of people forgetting to trim their headers while
replying.
And, as many people point out in the forum, Mr. Rosenthal's essay doesn't
handle the simple reality that most list participants prefer to have
Reply-To: set to point back to the list. Before I started running a few
mailing lists, I had already seen the "Reply-To Munging Considered Harmful"
essay, and referred a few of my list members to it. They didn't care. They
said "we want replies to go back to the list!" After a week or two of
participating in those lists and having to rewrite the headers every damn
time I wanted to reply, I agreed with them.
I now munge quite happily, and have had no complaints.
-----------------------------------------------------------------
Kai MacTane
System Administrator
Online Partners.com, Inc.
-----------------------------------------------------------------
>From the Jargon File: (v4.0.0, 25 Jul 1996)
cough and die /v./
Syn. barf. Connotes that the program is throwing its hands up by
design rather than because of a bug or oversight. "The parser saw a
control-A in its input where it was looking for a printable, so it
coughed and died." Compare die, die horribly, scream and die.
On Wed, Feb 17, 1999 at 01:36:47PM -0800,
Kai MacTane <[EMAIL PROTECTED]> wrote:
>
> And also see the discussion forum that's linked to at the bottom of that
> essay for some differing opinions. One of the more common responses is that
> without munging, people who hit "Reply to All" in their MUA then need to
> trim or cull the To: and Cc: fields to remove all other email addresses;
> otherwise, people will get multiple copies of replies to their own posts.
That is why people should add Mail-Followup-To headers when posting to lists.
That way the responder doesn't need to worry about whether the author
was on the list or not, that header will indicate where group replies
should go.
This feature can even be used to redirect stuff to a smaller subset of lists
or to an alternate list. Or it could be used to redirect replies to just
the author so that he can summarize them.
A reply-to header set by the list server can't do any of that and will break
things if the author had a reply-to header of his own that was removed.
At 04:00 PM 2/17/99 -0600, Bruno Wolff III wrote:
>
>That is why people should add Mail-Followup-To headers when posting to lists.
>That way the responder doesn't need to worry about whether the author
>was on the list or not, that header will indicate where group replies
>should go.
Interestingly, I just got two copies of this message. If you were using the
feature you mention, it wasn't handled properly by this list.
And I don't see any Mail-Followup-To header in either of the messages I got.
I know that, were I to try to use this feature, I'd have to get a different
mailer, as Eudora 3.0.5 has no facility for inserting extra headers. (And
folks, please don't tell me to "get a real mailer". I use Eudora because it
has a variety of features that I do need a lot more than the ability to
customize my headers.)
-----------------------------------------------------------------
Kai MacTane
System Administrator
Online Partners.com, Inc.
-----------------------------------------------------------------
>From the Jargon File: (v4.0.0, 25 Jul 1996)
drool-proof paper /n./
Documentation that has been obsessively dumbed down, to the point
where only a cretin could bear to read it, is said to have succumbed
to the `drool-proof paper syndrome' or to have been `written on
drool-proof paper'. For example, this is an actual quote from
Apple's LaserWriter manual: "Do not expose your LaserWriter to open
fire or flame."
On Wed, Feb 17, 1999 at 08:32:16AM -0500, Peter Green wrote:
> > Why doesn't Qmail mailing list set the
> > Reply To: field to "[EMAIL PROTECTED]".
> > It is very anoying that I must type the
> > mailing list address for every message
> > I respond to.
>
> Check out http://www.unicom.com/pw/reply-to-harmful.html for a great
> reason *not* to set the Reply-To: header. Any reasonable mailer should
> have some sort of "reply to (l)ist, (s)ender, (b)oth" option.
Unfortunately, there's an awful lot of unreasonable mailers in the
world, which makes that philosophy impractical. While I sympathize
with the opinions offered in "Reply-to Considered Harmful," it's
mostly ivory tower theorizing.
--
Regards,
Tim Pierce
RootsWeb Genealogical Data Cooperative
system obfuscator and hack-of-all-trades
On Wed, 17 Feb 1999, Tim Pierce wrote:
> On Wed, Feb 17, 1999 at 08:32:16AM -0500, Peter Green wrote:
> > Check out http://www.unicom.com/pw/reply-to-harmful.html for a great
> > reason *not* to set the Reply-To: header. Any reasonable mailer should
> > have some sort of "reply to (l)ist, (s)ender, (b)oth" option.
>
> Unfortunately, there's an awful lot of unreasonable mailers in the
> world, which makes that philosophy impractical.
Impractical for whom? The only people inconvenienced by not setting the
Reply-To: are people using "broken" mailers. Maybe they will get tired of
having to type the list name in every time and get a more fully-featured
MUA.
I certainly think the ideas expressed above are *far* superior to the
daily messages I see on other lists that consist of "Oops, I meant to send
that privately -- sorry, people" which only creates more traffic and noise
through which everyone has to filter.
/pg
--
Peter Green
Gospel Communications Network, SysAdmin
[EMAIL PROTECTED]
Tim Pierce writes:
> On Wed, Feb 17, 1999 at 08:32:16AM -0500, Peter Green wrote:
> > > Why doesn't Qmail mailing list set the
> > > Reply To: field to "[EMAIL PROTECTED]".
> > > It is very anoying that I must type the
> > > mailing list address for every message
> > > I respond to.
> >
> > Check out http://www.unicom.com/pw/reply-to-harmful.html for a great
> > reason *not* to set the Reply-To: header. Any reasonable mailer should
> > have some sort of "reply to (l)ist, (s)ender, (b)oth" option.
>
> Unfortunately, there's an awful lot of unreasonable mailers in the
> world, which makes that philosophy impractical.
Pandering to the unreasonable mailers doesn't help. The chief cost is
one of embarrassment to the poor slob who forgot that he was replying
to a mailing list. We've all seen it happen. I can't imagine that
anybody thinks that's a good thing.
How's about we get the unreasonable mailers fixed?
--
-russ nelson <[EMAIL PROTECTED]> http://crynwr.com/~nelson
Crynwr supports Open Source(tm) Software| PGPok | There is good evidence
521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace.
On Wed, 17 Feb 1999, Chris Naden wrote:
> I've searched the archives and i couldn't locate
> anything dealing with this.
FAQ 4.6, also man dot-qmail:
------ cut here ------
WARNING: For security, qmail-local replaces any dots in ext
with colons before checking .qmail-ext. For convenience,
qmail-local converts any uppercase letters in ext to lower-
case.
------ cut here ------
<rant>
I've heard many people complain about the lack of documentation that comes
with qmail; I'd like to put in a contrary opinion. I've never seen so
completely documented a system. Everything is there. The only gotcha is
that, apart from the FAQ, nothing is repeated. The moral of the story is:
read through *all* the qmail docs quickly once, or at least read the FAQ.
</rant>
> I'm trying to set up an email address @ a virtual
> domain using qmail (current release). You guys
> were very helpful to me in getting it set up at all
> and everything has worked smoothly so far. Now I wanted
> to set up an address with a . in it; that is for example
> [EMAIL PROTECTED]
> qmail file;
> /var/qmail/alias/.qmail-dom-foo.bar
>
> containing
>
> &foobar, then &foobar@localhost then &[EMAIL PROTECTED]
>
> It repliled 'no mailbox here' with all of
> the above variations.
>
> I then removed .bar from the filename; as with
>
> /var/qmail/alias/.qmail-dom-foo
>
> containing &[EMAIL PROTECTED]
>
> the user does exist, everything else is right. The second
> config worked.
>
> Can anyone tell me why I can't have <>.<> email
> names and what I should do about it?
>
> ~cHris
>
>
--
"Life is much too important to be taken seriously."
Thomas Erskine <[EMAIL PROTECTED]> (613) 998-2836
I couldn't find a manual entry for it,
but provided it works that doesn't bother
me.
FAQ/4.6
Mate
>> I've searched the archives and i couldn't locate
>> anything dealing with this.
>
>FAQ 4.6, also man dot-qmail:
>------ cut here ------
> WARNING: For security, qmail-local replaces any dots in ext
> with colons before checking .qmail-ext. For convenience,
> qmail-local converts any uppercase letters in ext to lower-
> case.
>------ cut here ------
You're entirely right; sorry! I completely forgot to
check the FAQ, having searched the list archives etc.
><rant>
>I've heard many people complain about the lack of documentation that comes
>with qmail; I'd like to put in a contrary opinion. I've never seen so
>completely documented a system. Everything is there. The only gotcha is
>that, apart from the FAQ, nothing is repeated. The moral of the story is:
>read through *all* the qmail docs quickly once, or at least read the FAQ.
></rant>
>
You are right again. After ppl have pointed me to the appropriate
place (not all of which are easy to find if you're a relative
novice in sysadmin terms) everything *is* in the docs. Understanding
it once it's there is another matter. New sysadmin's have to learn
somewhere. If they haven't the advantage of a degree, they have to
learn from the friendly and helpful people who make up the internet
community. Let's face it guys, it all works because you guys help
out the new guys, who become experienced and help out more new guys.
That's why we're a *community* right?
I've asked several stupid questions and some relevant questions
since I've been here, and i've recieved a great deal of very
valuable help and instruction from this list, noteably Mate Wierdl
and Mr Sam. I'm new to sysadmining. However, I've been able to pass
on what I@ve learnt, both in the Apache sphere and the qmail sphere,
to other ppl even newer, so that they don't bother you experienced
guys, but they do get their systems running.
Qmail documentation is impressive in it's comprehensiveness but
it is a little less so in it's comprehension. It can be very difficult
to understand what is being said, be it as it may that what is said
is entirely accurate. One example of this is the sheer number of ppl
(I was one and i@ve seen the thread recur several times just in the
month I've been here) who read the setup info as instructing them to
place virtual domains in rcpthosts, virtualdomains *and*locals*; the
documentation isn't wrong, but it's quite easy to misunderstand.
The fact that everything can be found and that some questions are
stupid (the particular question I asked which prompted this thread
happens to be one of them; if I'd re-read the FAQ rather than the
list archives I'd have caught it myself) doesn't mean that ppl,
particularly people new to the game like myself, are going to need
*and*benefit*from* advice and help from more experienced users like
yourselves.
Do, please, be tolerant and patient with us; we do learn, it's
just a little hard for us if we are rebutted and end up trying
to learn in a vaccuum. Fortunately for *my* operations, that
hasn't happned to me.. I pray it doesn't happen to anyone else here.
~cHris
On Wed, 17 Feb 1999, Chris Naden wrote:
[snip]
> ><rant>
> >I've heard many people complain about the lack of documentation that comes
> >with qmail; I'd like to put in a contrary opinion. I've never seen so
> >completely documented a system. Everything is there. The only gotcha is
> >that, apart from the FAQ, nothing is repeated. The moral of the story is:
> >read through *all* the qmail docs quickly once, or at least read the FAQ.
> ></rant>
> >
>
> You are right again. After ppl have pointed me to the appropriate
> place (not all of which are easy to find if you're a relative
> novice in sysadmin terms) everything *is* in the docs. Understanding
> it once it's there is another matter. New sysadmin's have to learn
I wasn't meaning to come across as mad-at-you, and I hope you didn't take
it that way. There are many different right ways to configure qmail and
to find the one that's right for you requires that you understand how
qmail works. It's not difficult, but there is a lot of it. That's why I
suggested reading *all* the man pages; unless you're a slow reader, you
can do it in an evening. If you've even skimmed them all, you'll remember
vaguely what's there.
I admire Dan's documentation for coverage: everything's there. On the
other hand, something a bit more like the original Perl book, starting off
using it, then documenting commands and finally some cookbook-style
recipies might be easier to take. However, if you print /var/qmail/doc/*
and /var/qmail/man/cat*, and order it appropriately, you've almost got it.
But then you've got a book, effectively. [Everybody will appreciate it
when the qmail book is available.]
> somewhere. If they haven't the advantage of a degree, they have to
> learn from the friendly and helpful people who make up the internet
> community. Let's face it guys, it all works because you guys help
> out the new guys, who become experienced and help out more new guys.
> That's why we're a *community* right?
That's why I answered your original question; I do agree with you. On
the other hand, it does get old answering FAQs.
Anybody who's new to qmail, please do yourself and the list a favour:
read the FAQ, all of it.
[snip]
> Qmail documentation is impressive in it's comprehensiveness but
> it is a little less so in it's comprehension. It can be very difficult
> to understand what is being said, be it as it may that what is said
> is entirely accurate. One example of this is the sheer number of ppl
> (I was one and i@ve seen the thread recur several times just in the
> month I've been here) who read the setup info as instructing them to
> place virtual domains in rcpthosts, virtualdomains *and*locals*; the
> documentation isn't wrong, but it's quite easy to misunderstand.
I personally don't read it that way, but you're right that many peopl have
misunderstood. How about beefing up the man pages:
for qmail-send: for its description of locals to explicitly say that
virtual domains should *not* be placed in locals?
for qmail-smtpd: for its description of rcpthosts to say that it
should contain all the hosts in locals and virtualdomains plus
those hosts you act as MX for.
Actually, in stead of the latter suggestion, I'd prefer that there be
another control file: mxhosts, and drop rcpthosts, which is just
confusing everyone. Then we have simple explanations for what goes where.
> The fact that everything can be found and that some questions are
> stupid (the particular question I asked which prompted this thread
> happens to be one of them; if I'd re-read the FAQ rather than the
> list archives I'd have caught it myself) doesn't mean that ppl,
> particularly people new to the game like myself, are going to need
> *and*benefit*from* advice and help from more experienced users like
> yourselves.
Again, I agree with you that newcomers will need some help, and it's the
job of more experienced people to help them. (Imagine how much better the
real world would work if we used this thinking there, but I digress :-).
We just wish that more people would read the documentation, especially the
FAQ.
> Do, please, be tolerant and patient with us; we do learn, it's
Yeah, I'm getting snippy in my old age [smarten up Tom <whack-on-the-head>]
Sorry about that.
> just a little hard for us if we are rebutted and end up trying
> to learn in a vaccuum. Fortunately for *my* operations, that
> hasn't happned to me.. I pray it doesn't happen to anyone else here.
>
> ~cHris
--
"Life is much too important to be taken seriously."
Thomas Erskine <[EMAIL PROTECTED]> (613) 998-2836
At 12:33 PM 2/17/99 -0500, you wrote:
<rant snipped>
>> You are right again. After ppl have pointed me to the appropriate
>> place (not all of which are easy to find if you're a relative
>> novice in sysadmin terms) everything *is* in the docs. Understanding
>> it once it's there is another matter. New sysadmin's have to learn
>
>I wasn't meaning to come across as mad-at-you, and I hope you didn't take
>it that way.
Not at all... *8-)
<snip>
> That's why I
>suggested reading *all* the man pages; unless you're a slow reader, you
>can do it in an evening. If you've even skimmed them all, you'll remember
>vaguely what's there.
True; when I read the FAQ I was in a hurry and only
read the immediately relevant entry, I intend now to
remedy that.
<snippage>
Let's face it guys, it all works because you guys help
>> out the new guys, who become experienced and help out more new guys.
>> That's why we're a *community* right?
>
>That's why I answered your original question; I do agree with you. On
>the other hand, it does get old answering FAQs.
>
>Anybody who's new to qmail, please do yourself and the list a favour:
>read the FAQ, all of it.
Thoroughly agreed, and my own guilt admitted in my
followup below. However, I have retained my comment
about community because I'm going to return to it later.
>[snip]
>> Qmail documentation is impressive in it's comprehensiveness but
>> it is a little less so in it's comprehension. It can be very difficult
>> to understand what is being said, be it as it may that what is said
>> is entirely accurate.
This is partly to expand for later comment. What I mean here
is that if you are new to the unix admin community and
terminology and *concepts*, thought patterns (eg me; I've been
involved for all of 6 months, sporadically because I have this
work thing getting in the way *8-) then qmail documentation
can be confusing not through innaccuracy but through assumed
knowledge. It's written for the experienced/talented, by
the experienced/talented. Not a fault in the documentation, but
a good reason for the help that you guys provide in this list here.
<snippage of manual suggestions>
>
>> The fact that everything can be found and that some questions are
>> stupid (the particular question I asked which prompted this thread
>> happens to be one of them; if I'd re-read the FAQ rather than the
>> list archives I'd have caught it myself) doesn't mean that ppl,
>> particularly people new to the game like myself, are going to need
>> *and*benefit*from* advice and help from more experienced users like
>> yourselves.
>
>Again, I agree with you that newcomers will need some help, and it's the
>job of more experienced people to help them. (Imagine how much better the
>real world would work if we used this thinking there, but I digress :-).
>We just wish that more people would read the documentation, especially the
>FAQ.
True, sir; I thoroughly agree with you both in content
and in digression. But as above, reading the docs (which in
this particular case I didn't but in others I have done and
still gone slightly or majorly wrong) is not synonymous with
fully understanding what's going on.
>> Do, please, be tolerant and patient with us; we do learn, it's
>
>Yeah, I'm getting snippy in my old age [smarten up Tom <whack-on-the-head>]
>Sorry about that.
My response to your rant was as much an over-reaction
as anything you might have said. I've seen similar but
stronger-worded rants frequently in different lists/faq's/news
groups over the last few weeks, and i guess my response
was building. The feeling is rapidly appearing among the experienced
of the internet that the clueless are a bad thing. I
(possibly because I am a teacher of sorts at times) view
the clueless as tomorrows experts and feel it to be my job
to help 'em get there if I know more than they do.
I know ppl who are capable of working out linux and similarly
mind-bending things effectively from first principles by
having an os to play with and then playing. I also know that
the majority of us are simply not in that league. Of the various
forums in which I've tried to get help recently (and there are
a few; my inexperience is farily wide-spread in this sphere)
the two most universally helpfull have been this list and
the apache-ssl list. The only reason the rant that I responded
with got posted here, I guess, is actually because I think here
it would be usefully recieved in a way that in some more cliquey
forums it would be simply ignored/flamed. I certainly implied
no serious personal criticism of either Tom or anyone else
here.
Thanks for your extended attention,
cHris
On Wed, Feb 17, 1999 at 12:33:04PM -0500, [EMAIL PROTECTED] wrote:
> On Wed, 17 Feb 1999, Chris Naden wrote:
>
> for qmail-send: for its description of locals to explicitly say that
> virtual domains should *not* be placed in locals?
>
> for qmail-smtpd: for its description of rcpthosts to say that it
> should contain all the hosts in locals and virtualdomains plus
> those hosts you act as MX for.
>
> Actually, in stead of the latter suggestion, I'd prefer that there be
> another control file: mxhosts, and drop rcpthosts, which is just
> confusing everyone. Then we have simple explanations for what goes where.
You're not saying that qmail-smtpd should just read in locals and virtualdomains and
accept mail for all domains in there, right?
Greetz, Peter.
--
.| Peter van Dijk | <mo|VERWEG> stoned worden of coden
.| [EMAIL PROTECTED] | <mo|VERWEG> dat is de levensvraag
| <mo|VERWEG> coden of stoned worden
| <mo|VERWEG> stonend worden En coden
| <mo|VERWEG> hmm
| <mo|VERWEG> dan maar stoned worden en slashdot lezen:)
Peter van Dijk <[EMAIL PROTECTED]> writes:
| You're not saying that qmail-smtpd should just read in locals and virtualdomains and
| accept mail for all domains in there, right?
Of course it should! (cdb optional.) That avoids the whole multiple
redundancy plus illogical defaults problem that the current scheme
suffers from.
If you want an optional rcpthosts or mxhosts for special cases, then
fine, that's a special case, which mostly no one will ever need to know
about.
Scott Schwartz writes:
> Peter van Dijk <[EMAIL PROTECTED]> writes:
> | You're not saying that qmail-smtpd should just read in locals and virtualdomains
>and
> | accept mail for all domains in there, right?
>
> Of course it should! (cdb optional.) That avoids the whole multiple
> redundancy plus illogical defaults problem that the current scheme
> suffers from.
>
> If you want an optional rcpthosts or mxhosts for special cases, then
> fine, that's a special case, which mostly no one will ever need to know
> about.
You still need to be able to subtract local-only domain names, and add
non-local domain names. I would say that qmail-smtpd should access a
cdb which is constructed from locals + virtualdomains + a new file
named receivebysmtp, which has lines that start with a + if the host
should be acceptable for receipt via SMTP, and a minus if the host
should not be acceptable (which is another way of saying "was found in
locals or virtualdomains but we wish to reject").
--
-russ nelson <[EMAIL PROTECTED]> http://crynwr.com/~nelson
Crynwr supports Open Source(tm) Software| PGPok | There is good evidence
521 Pleasant Valley Rd. | +1 315 268 1925 voice | that freedom is the
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | cause of world peace.
I'm in the process of doing this right now.
The answer is: You Can't.
I've spent weeks with the post.office technical support staff, just to
have them finally give me that answer. They told me something stupid like
"This is a proprietary algorithm and for ours and our customers security,
we can not divulge the algorithm"
This has forced me to do this:
I've written a checkpassword implementation in perl that checks a sql
database first (replacement for post.office) if the users has all his
info, then the authentication proceeded normally. If the user exists but
has no password then it goes out and passes then authentication to the old
post.office server and checks if it is valid, if so it crypts the password
and places it into the database so this only has to be done once for each
post.office user.
The overhead is a little more than I'd like but, I couldn't come up with a
better solution.
We all know how secure proprietary algorithms are, I plan to try and figure
out their process after having a large plain text->post.office encryption
table built. If I can figure out what they are doing I will post my
results on the Internet.
They say they are using MD5 but MD5 returns a 128bit hash if I remember
right and post.office returns a 256bit hash, the only algorithm I could
find that will return a 256bit hash is GOST, and post.offfice does not
appear to be using GOST.
-Chris Nelson
On Wed, 17 Feb 1999, A.Y. Sjarifuddin wrote:
> Date: Wed, 17 Feb 1999 14:04:42 +0700
> From: "A.Y. Sjarifuddin" <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Delivered-To: [EMAIL PROTECTED]
> Delivered-To: mailing list [EMAIL PROTECTED]
> Subject: Moving post office to qmail
>
> We'd like to move our post office to qmail, the problem is in the users
> password.
> Post office using MD5 encryption with a seed (64 char).
> Any idea how to change this MD5 encryption to qmail?
>
> Thanks in advance.
>
Chris Nelson wrote:
-snip-
> I've spent weeks with the post.office technical support staff, just to
> have them finally give me that answer. They told me something stupid like
> "This is a proprietary algorithm and for ours and our customers security,
> we can not divulge the algorithm"
-snip-
> They say they are using MD5 but MD5 returns a 128bit hash if I remember
> right and post.office returns a 256bit hash, the only algorithm I could
> find that will return a 256bit hash is GOST, and post.offfice does not
> appear to be using GOST.
AFAIK they use BASE64 encoded MD5 hashes. Take a look into the DEBUG
compiled checkpassword implementation in the qmail-ldap patches at
http://www.nrg4u.com.
--
Andre
Hello, I hope someone could help me.
I'm configuring a connection between an Exchange Server and
a qmail server. I've installed serialmail and ucspi-tcp and I'm
running qmail-smtpd from tcpserver -v.
I also have created a /var/qmail/autoturn directory and changed
it to the qmail group, and then I've granted it the 2755 permissions.
I've continued as described in a documentation I've downloaded
from the Internet, i.e., I've appended the line
+autoturn-:qmaild:1115:500:/var/qmail/autoturn:-::
and then I've runned the qmail-newu command. This didn't work:
it returns me the following message:
qmail-newu: fatal: bad format in users/assign
What are the next steps I must do?
Will this process affect in any way the right mail delivery of the
other virtual domains?
Thanks,
Carles.
On Wed, Feb 17, 1999 at 07:48:10PM +0100, Carles Latorre wrote:
> Hello, I hope someone could help me.
>
> I'm configuring a connection between an Exchange Server and
> a qmail server. I've installed serialmail and ucspi-tcp and I'm
> running qmail-smtpd from tcpserver -v.
>
> I also have created a /var/qmail/autoturn directory and changed
> it to the qmail group, and then I've granted it the 2755 permissions.
> I've continued as described in a documentation I've downloaded
> from the Internet, i.e., I've appended the line
>
> +autoturn-:qmaild:1115:500:/var/qmail/autoturn:-::
>
> and then I've runned the qmail-newu command. This didn't work:
> it returns me the following message:
>
> qmail-newu: fatal: bad format in users/assign
Does the last line of your users/assign file consist of a single period? It
should.
>From man qmail-users:
STRUCTURE
/var/qmail/users/assign is a series of assignments, one
per line. It ends with a line containing a single dot.
Lines must not contain NUL.
Chris
This was for the message with
Subject: New Dual Mount Copy Holder by Rubbermaid
Mate
------- Forwarded Message
Dear Internet User,
Thank you for contacting the Prodigy Postmaster regarding unsolicited
commercial email (UCE) you have received.
The Prodigy account listed in the UCE, [EMAIL PROTECTED], has
been canceled.
Prodigy Postmaster
[EMAIL PROTECTED]
------- End of Forwarded Message
Sorry folks, I am brand new to qmail and I am just getting it up and
running on a test box. I setup Maildir for my home directory and I am just
wondering if root in fact is the owner for the users Maildir/ directory..
-----snipit-------
ls -alg Maildir/
ls: Maildir/: Permission denied
[mark@rati mark]$ su
Password:
[root@rati mark]# ls -alg Maildir/
total 5
drwx------ 5 root root 1024 Feb 17 11:37 .
drwx------ 6 mark mark 1024 Feb 17 12:09 ..
drwx------ 2 root root 1024 Feb 17 11:37 cur
drwx------ 2 root root 1024 Feb 17 11:37 new
drwx------ 2 root root 1024 Feb 17 11:37 tmp
Do I have my ownerships and permissions completely @#$%#! up?
Thanks folks.
Mark
[EMAIL PROTECTED]
http://www.thisaddress.net
On Wed, Feb 17, 1999 at 11:10:10AM -0800, Mark Zugsmith wrote:
> Sorry folks, I am brand new to qmail and I am just getting it up and
> running on a test box. I setup Maildir for my home directory and I am just
> wondering if root in fact is the owner for the users Maildir/ directory..
>
>
> -----snipit-------
> ls -alg Maildir/
> ls: Maildir/: Permission denied
> [mark@rati mark]$ su
> Password:
> [root@rati mark]# ls -alg Maildir/
> total 5
> drwx------ 5 root root 1024 Feb 17 11:37 .
> drwx------ 6 mark mark 1024 Feb 17 12:09 ..
> drwx------ 2 root root 1024 Feb 17 11:37 cur
> drwx------ 2 root root 1024 Feb 17 11:37 new
> drwx------ 2 root root 1024 Feb 17 11:37 tmp
>
> Do I have my ownerships and permissions completely @#$%#! up?
I don't know about completely @#$%#! up, but it's not right and won't work. As
it stands, your Maildir and its contents are owned by root. You need to chown
-R mark.mark ~mark/Maildir.
Chris
On Wed, 17 Feb 1999 15:25:19 -0500,
Chris Johnson <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 17, 1999 at 11:10:10AM -0800, Mark Zugsmith wrote:
> > Sorry folks, I am brand new to qmail and I am just getting it up and
> > running on a test box. I setup Maildir for my home directory and I am just
> > wondering if root in fact is the owner for the users Maildir/ directory..
> > -----snipit-------
> > ls -alg Maildir/
> > ls: Maildir/: Permission denied
> > [mark@rati mark]$ su
> > Password:
> > [root@rati mark]# ls -alg Maildir/
> > total 5
>
> I don't know about completely @#$%#! up, but it's not right and won't work. As
> it stands, your Maildir and its contents are owned by root. You need to chown
> -R mark.mark ~mark/Maildir.
For your next users you should su to the user before running maildirmake. Or
better do a maildirmake (as root) in /etc/skel, so new users on your system
will get it automatically. During creation of a new user the ownerships
will be switched afterwards.
Regards
Mirko
--
mailto:[EMAIL PROTECTED] myhome_aka_~:http://sites.inka.de/picard
RedHat=~/rh52_isdn.html teles16.3c=~/teles163c/teles163c_contents.html
XL97-Classes ~/vba-classes/
be aware of culture www.uni-karlsruhe.de/~etcetera
I have a user ezmlm handling two virtual domains. The problem is that
we have a few users have email addresses in both domain, but some of
them want to have their mail in different domain treated differently.
~qmail/control/virtualdomains
dom1.net:ezmlm
dom2.net:ezmlm
Say the user name is bob. then ~ezmlm/.qmail-bob will handle both
[EMAIL PROTECTED] and [EMAIL PROTECTED] with the same mean.
what can I do to treat them differently.
Thanks.
On Thu, Feb 18, 1999 at 08:09:27AM +1100, [EMAIL PROTECTED] wrote:
> I have a user ezmlm handling two virtual domains. The problem is that
> we have a few users have email addresses in both domain, but some of
> them want to have their mail in different domain treated differently.
>
> ~qmail/control/virtualdomains
> dom1.net:ezmlm
> dom2.net:ezmlm
>
>
> Say the user name is bob. then ~ezmlm/.qmail-bob will handle both
> [EMAIL PROTECTED] and [EMAIL PROTECTED] with the same mean.
>
> what can I do to treat them differently.
FAQ 3.3
By the way, there was no need to cross-post this question. It's a qmail
question, and has nothing to do with ezmlm.
Chris
On Wed, 17 Feb 1999, Chris Johnson wrote:
> On Thu, Feb 18, 1999 at 08:09:27AM +1100, [EMAIL PROTECTED] wrote:
> > I have a user ezmlm handling two virtual domains. The problem is that
> > we have a few users have email addresses in both domain, but some of
> > them want to have their mail in different domain treated differently.
> >
> > ~qmail/control/virtualdomains
> > dom1.net:ezmlm
> > dom2.net:ezmlm
> >
> >
> > Say the user name is bob. then ~ezmlm/.qmail-bob will handle both
> > [EMAIL PROTECTED] and [EMAIL PROTECTED] with the same mean.
> >
> > what can I do to treat them differently.
>
> FAQ 3.3
>
> By the way, there was no need to cross-post this question. It's a qmail
> question, and has nothing to do with ezmlm.
I have read FAQ3.3. and the reason I cross post this is because I already
have a few mailing list running under these two domains. If I adopt the
way FAQ3.3 suggest, Then I will have to set up all these lists from
scrtch. since there is only "a few" user have this problem, I thought
there might be another way of doing it ?
Thanks.
On Thu, 18 Feb 1999 [EMAIL PROTECTED] wrote:
> I have a user ezmlm handling two virtual domains. The problem is that
> we have a few users have email addresses in both domain, but some of
> them want to have their mail in different domain treated differently.
>
> ~qmail/control/virtualdomains
> dom1.net:ezmlm
> dom2.net:ezmlm
>
> Say the user name is bob. then ~ezmlm/.qmail-bob will handle both
> [EMAIL PROTECTED] and [EMAIL PROTECTED] with the same mean.
>
> what can I do to treat them differently.
You run into the problems because each domain is pointing to the
same 'real' account. The first thing to do is to have a different account
handling QMAIL duties for each domain.
The real issue with virtual domains (versus the actual host's
domain) is the way QMail handles accounts for virtual domains. I'll
illustrate like so:
dom1.net:domain1
dom2.net:domain2
su - domain1
ezmlm-make ~/LIST ~/.qmail-bob domain1-bob dom1.net
You will have to edit the ~/LIST/config file to remove "domain1-"
from the line containing "domain1-bob". You may also have to edit the
~/LIST/text/* files in the same way.
With virtual domains, you are dealing with the fact that QMail is
using the real account for controlling the virtual accounts, besides
using virtual accounts to deal with virtual-virtual accounts.
I just downloaded ezmlm-idx a couple of days ago and have done
just this to set up two mailing lists for separate domains.
--
Roger Walker Voice/Fax 780-440-2685 Network Manager,
Director & Senior Consultant, Pager 780-917-5817 ROPE Internet Services
ROSCO Associates Technology <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
Staffing Ltd. (RATS!) <www.rat-hole.com> <www.rope.net>
"HIS Pain; YOUR Gain" BLACK RAT: <www.rat-hole.com/black-rat>
On Thu, Feb 18, 1999 at 08:21:00AM +1100, [EMAIL PROTECTED] wrote:
>
>
> On Wed, 17 Feb 1999, Chris Johnson wrote:
>
> > On Thu, Feb 18, 1999 at 08:09:27AM +1100, [EMAIL PROTECTED] wrote:
> > > I have a user ezmlm handling two virtual domains. The problem is that
> > > we have a few users have email addresses in both domain, but some of
> > > them want to have their mail in different domain treated differently.
> > >
> > > ~qmail/control/virtualdomains
> > > dom1.net:ezmlm
> > > dom2.net:ezmlm
> > >
> > >
> > > Say the user name is bob. then ~ezmlm/.qmail-bob will handle both
> > > [EMAIL PROTECTED] and [EMAIL PROTECTED] with the same mean.
> > >
> > > what can I do to treat them differently.
> >
> > FAQ 3.3
> >
> > By the way, there was no need to cross-post this question. It's a qmail
> > question, and has nothing to do with ezmlm.
>
> I have read FAQ3.3. and the reason I cross post this is because I already
> have a few mailing list running under these two domains. If I adopt the
> way FAQ3.3 suggest, Then I will have to set up all these lists from
> scrtch. since there is only "a few" user have this problem, I thought
> there might be another way of doing it ?
I think the better way would be the FAQ 3.3 way (and it shouldn't be too hard
to change--just fix the .qmail files and maybe DIR/inlocal), but this should
work too:
In ~ezmlm/.qmail-bob:
| condredirect [EMAIL PROTECTED] [ $HOST = "dom1.net" ]
&[EMAIL PROTECTED]
Mail to [EMAIL PROTECTED] will be delivered to [EMAIL PROTECTED], and mail to
[EMAIL PROTECTED] will be delivered to [EMAIL PROTECTED]
Chris
Fact: SMTP does not guarantee that you won't see two copies of any
given message. We all know this, right? It's come up again and again,
and the fair comment is always that anyone who cares about that problem
will have their MTA set up to deal with it.
Irony: what's the point of complaining if your name appears twice
(perhaps indirectly) in the headers, when you simply cannot avoid
seeing some messages twice, for *whatever* reason? So deal with it
quietly.
I am configuring a new machine for qmail. The machine is a Dual 400 with
512 Meg of RAM. Currently we will be using an 18gig drive (RAID 5 setup)
for e-mail only. What would be the best way to partition this drive for
qmail to allow for queue and everything for optimal performance? Also, if
later I add another drive to it increasing it to 27 gig, how hard will it
be to add this extra space to my /home dir for additional storage? How big
of a swap file should I make?
Thanks
On Wed, 17 Feb 1999, MountaiNet Tech Support wrote:
> I am configuring a new machine for qmail. The machine is a Dual 400 with
> 512 Meg of RAM. Currently we will be using an 18gig drive (RAID 5 setup)
> for e-mail only. What would be the best way to partition this drive for
> qmail to allow for queue and everything for optimal performance? Also, if
> later I add another drive to it increasing it to 27 gig, how hard will it
> be to add this extra space to my /home dir for additional storage? How big
> of a swap file should I make?
That all depends a lot on your usage patterns and anticipated load. If
you anticipate lots of load, I would honestly put the queue on its own
disk at a minimum. Multiple smaller disks running in a RAID 0 or 0+1
would be better for the queue. RAID 5 is nice for survivability but you
pay a bit of a performance penalty on disk writes. considering how much
activity goes on in qmail's queue, every microsecond of latency on those
disks can have a big impact if your system gets hammered one day or your
usage patterns change drastically.
I would also go with something like having your OS/binaries on one disk,
your queue on another, and your mailstore itself on the RAID 5 set, with
careful balancing of swap as needed.
What OS are you using?
jms
On Tue, 16 Feb 1999, Harald Hanche-Olsen wrote:
> - "Matt D. Landry" <[EMAIL PROTECTED]>:
>
> | I'm trying to set up an auto-reply feature for employees that are
> | out of the office..can I set up a mailing list type script that
> | allows employees to set an option that they are out of the office
> | and my script will auto-reply to any messages sent to the employee,
> | and has anybody done anything like this?
>
> It's been done. It's called the vacation program (try man vacation on
> your system). Beware of home cooking in this area - it is just too
> easy to create mail loops. Also note that most (all?) versions of the
> vacation program must be run as ``|preline vacation ...'' from the
> .qmail file.
And also note that unless you've got a vacation built especially for
qmail, then using preline will fail for large messages. From the
www.qmail.org pages:
If you use qmail's preline utility, remember that preline expects
to pipe the _entire_ mail message through the specified program. If
the specified program closes standard input before preline has
finished, preline will exit with a transient failure and you'll see
the following error in your logs:
deferral: preline:_fatal:_unable_to_copy_input:_broken_pipe/
You'll see this problem if you try to use the sendmail version of
vacation [Peter Samuel]
Not wishing to beat my own drum (much), but this was the reason I
wrote my vacation implementation. See
ftp://ftp.uniq.com.au/pub/tools/qmail/qmail-vacation-1.3.tar.gz
Regards
Peter
----------
Peter Samuel [EMAIL PROTECTED]
Technical Consultant or at present:
Uniq Professional Services, [EMAIL PROTECTED]
a division of X-Direct Pty Ltd
Phone: +61 2 9206 3410 Fax: +61 2 9281 1301
"If you kill all your unhappy customers, you'll only have happy ones left"
Hi
I'm setting up my first qmail system & have hit a snag.
I can mail internally, access mailbox over inet & send mail over inet.
I cannot receive inet mail?
Any help would be appreciated.
TIA
--
Bill Hults Network Engineer
Vermont Systems Support Group
26 Sunset Ridge Jericho, VT 05465
Office(802)899-2549 Home(802)223-6249
What is wrong with the following setup:
less than 30K customers:
qmail 1.03 running on 3 high speed alpha's (each with 128MB ram)
Running 4 TCPSERVER daemon processes.
1 SMTP (port 25)
1 POP3 (port 110)
1 SMTP (port 2001)
1 POP3 (port 2002)
These 3 servers running these 4 daemons share a Netapp filer for backend
storage.
We have done major tuning to these servers time after time. Here is the
current situation:
3 of the daemons run fine. the SMTP (on regular port 25) does not
respond.
I have set the -b option for TCPserver(this helped us immensely before)
to 5000 (supposedly allowing tcpserver to respond to 5000 connections).
Is there some default limit somewhere that would only allow tcpserver to
pass so many connections to qmail-smtpd? The downtime on the servers is
getting rediculous because of this problem.
If I run /var/qmail/bin/qmail-smtpd it comes right up.
If I telnet localhost 2002 (simply another instance of tcpserver) it
comes right up.
Both POP3 connections come right up
If i do a "netstat -n|grep ":25 " I get almost 700 connections although
most of these are in the "CLOSE WAIT" stage or something similar.
On one of the servers, when this happens and qmail is totally
unresponsive on port 25, the load drops to 0.00 and the server just sits
there.
restarting qmail seems to help for about 5 minutes... then the imaginary
limit is hit and everything goes to hell.
Anyone have any suggestions for the current situation?
--
------------------------------------------------------------------------
// Jere Cassidy - System Administration - D&E SuperNet
email: [EMAIL PROTECTED] phone: (717)738-7054
web: http://www.desupernet.net/jere
pager/pcs: [EMAIL PROTECTED] - (717)203-0042
~~~ "While sowing the seeds of Utopia,
you invoked a convenient amnesia" -BR ~~~
------------------------------------------------------------------------
Thanks for the help guys. I am going to post this info to the list for general
review:
Mark Delany wrote:
> Sounds particularly nasty. It may well be a bug associated with establishing
> tcp sessions.
>
> 700 outstanding sessions sounds awfully high.
>
> It may also be a router issue. Is it possible that the tcp sessions are
> starting and not completing because certain packet types are being rejected?
>
> Btw. How are you getting 700 sessions? Do you have the concurrency on
> tcpserver set *that* high?
>
> Regards.
> John White wrote:
> Uhhh... You definitely want to check out that tcpserver manpage again.
> Especially the difference between -c and -b.
>
> Also, the listen manpage.
>
> It would greatly help if you would give me your current tcpserver
> invocation for qmail-smtpd
>
> --
> John White
> [EMAIL PROTECTED]
>
Yes, 700 connections seems high, but after some period of down time, it seems to
me to be within the realm of possibilities. Our Alteon ACEdirector (load
balancing switch) seemed to indicate approximately 600 connections and I had
originally thgought that this number was artificially inflated due to some
time-out value. The number that the Alteon showed was up as high as 1200
connections on a single server (when the other 2 were down). Here is the
invocation of tcpserver:
tcpserver -l$hostvalue -q -b100 -H -R -D 0 pop-3
/var/qmail/bin/qmail-popup $hostvalue /var/qmail/bin/CheckPasswd
/var/qmail/bin/qmail-pop3d Maildir &
tcpserver -l$hostvalue -q -b50 -H -R -D 0 2001
/var/qmail/bin/qmail-popup $hostvalue /var/qmail/bin/CheckPasswdVirtual cyb
/var/qmail/bin/qmail-pop3d Maildir &
tcpserver -l$hostvalue -t8 -q -b5000 -D -u502 -g2108
-x/var/qmail/control/tcprules.dat 0 smtp /var/qmail/bin/qmail-smtpd &
tcpserver -l$hostvalue -t8 -q -b50 -D -u502 -g2108
-x/var/qmail/control/tcprules.dat 0 2002 /var/qmail/bin/qmail-smtpd &
In case you are wondering, CheckPasswdVirtual (on port 2001) and SMTP (on port
2002) are actually accepting connections to a different switched address on the
Alteon. CheckPasswdVirtual attaches a "cyb-" to their username so that they did
not have to make any changes to accomodate a VirtualDomain type login.
ohh.. and $hostvalue = mailX.desupernet.net where X = [124]
After reading "man listen" I am reminded of the help this list gave us when we
had this problem before. Our connections were being artificially limited by
Linux to 5 at a time! This was solved with adding the -b20 (then later upping
it to 30, then 50, then 100) . Last night, I grew frustrated with this and set
it to 5000 on the port that was unresponsive (25). This had no effect. 'man
listen' seems to indicate that 128 may be a max value this can be set to? Is
that my actual limit?
If one server reaches this limit, it is overloaded and if lucky it is dropped
out of the rotation by the alteon. This causes the other servers to overload
and reach the same state.
SMTP connections will eventually get through, it just may take 5 or 10 or 15+
minutes for the
220 mail1.desupernet.net ESMTP
line to come up.
Thanks again for the help (I have been sleeping under my desk awaiting helpful
replies :) )
If you need any other info let me know.
> At 01:16 18/02/99 -0500, Jere Cassidy wrote:
> >
> >What is wrong with the following setup:
> >
> >less than 30K customers:
> >
> >qmail 1.03 running on 3 high speed alpha's (each with 128MB ram)
> >Running 4 TCPSERVER daemon processes.
> >
> >
> >1 SMTP (port 25)
> >1 POP3 (port 110)
> >1 SMTP (port 2001)
> >1 POP3 (port 2002)
> >
> >These 3 servers running these 4 daemons share a Netapp filer for backend
> >storage.
> >
> >We have done major tuning to these servers time after time. Here is the
> >current situation:
> >3 of the daemons run fine. the SMTP (on regular port 25) does not
> >respond.
> >
> >I have set the -b option for TCPserver(this helped us immensely before)
> >to 5000 (supposedly allowing tcpserver to respond to 5000 connections).
> >
> >Is there some default limit somewhere that would only allow tcpserver to
> >pass so many connections to qmail-smtpd? The downtime on the servers is
> >getting rediculous because of this problem.
> >
> >If I run /var/qmail/bin/qmail-smtpd it comes right up.
> >If I telnet localhost 2002 (simply another instance of tcpserver) it
> >comes right up.
> >Both POP3 connections come right up
> >
> >If i do a "netstat -n|grep ":25 " I get almost 700 connections although
> >most of these are in the "CLOSE WAIT" stage or something similar.
> >
> >On one of the servers, when this happens and qmail is totally
> >unresponsive on port 25, the load drops to 0.00 and the server just sits
> >there.
> >
> >restarting qmail seems to help for about 5 minutes... then the imaginary
> >limit is hit and everything goes to hell.
> >
> >Anyone have any suggestions for the current situation?
> >
> >
> >
> >
> >
> >
> >
> >
> >--
> >------------------------------------------------------------------------
> >
> >// Jere Cassidy - System Administration - D&E SuperNet
> > email: [EMAIL PROTECTED] phone: (717)738-7054
> > web: http://www.desupernet.net/jere
> > pager/pcs: [EMAIL PROTECTED] - (717)203-0042
> >~~~ "While sowing the seeds of Utopia,
> > you invoked a convenient amnesia" -BR ~~~
> >------------------------------------------------------------------------
> >
> >
> >
> >
> >
--
------------------------------------------------------------------------
// Jere Cassidy - System Administration - D&E SuperNet
email: [EMAIL PROTECTED] phone: (717)738-7054
web: http://www.desupernet.net/jere
pager/pcs: [EMAIL PROTECTED] - (717)203-0042
~~~ "While sowing the seeds of Utopia,
you invoked a convenient amnesia" -BR ~~~
------------------------------------------------------------------------
