Tom Collins wrote:
Who the heck is Charles Cazabon and why should I care that he thinks
our files shouldn't be called .qmail?
Charles is probably the most knowledgeable person answering questions on
the qmail list. He can be a pain to work with sometimes, but if Charles
and DJB were arguing about how something works in the current version of
qmail, I'd bet on Charles.
Since we are dependent on qmail I think it is a good idea to have a good
name on their list. I asked Charles what he thought was wrong wit
vpopmail after he dissed it on the list one time. As I recall there are
three things. Using the name .qmail for files that are not executed by
qmail. Using the .qmail name and not fully implementing it. The way we
hijack users/assign.
I am hopeful that since renaming the files takes care of his two biggest
complaints maybe we will get off his 'brain dead' list. (something
like that...)
DAve wrote:
You must swing a dead chicken around your office five times. Then
> (after putting the chicken down) hop on your left foot five times
> while chanting "Only I interpret RFCs... Only I interpret RFCs...".
You may still protect your offspring from the wrath of the qmail
> list. You however are doomed, sorry to say. Hurry, it's not too
> late.
You know the place! :) Its certainly not for newbies. If you don't
follow the protocol you can get your head bitten off. Still its worth
reading to learn about the deep dark secrets within qmail. Its got some
pretty entertaining flame wars too.
Tom Collins wrote:
If vdelivermail handled the file identically to the way qmail-local
does, would he be OK with that?
Identical functions would reduce his biggest complaint, the irritation
of people asking on the qmail list about things that are not handled the
same between vdelivermail and qmail-local. I suspect he would prefer
the rename, since he specifically mentioned it, and even suggested the name.
DAve wrote:
> Do it for the children.
I thought it was for the kittens... :)
Tom Collins wrote:
> Now that .qmail files are fully supported in vpalias.c, we can
> update QmailAdmin to use the vpopmail API to work with the files,
> and it won't know anything about their contents.
I'm planning on it. I may even have it done in some of the old code I
have around here. I was working on unifying aliases when Ken released
the daemon.
Here's where I get worried: QmailAdmin and (I think) SquirrelMail
> plugins and who-knows-what-else already make use of .qmail files.
I do worry about version compatibility though -- someone running new
> vpopmail and old qmailadmin.
Well, you have to re-compile qmailadmin anyway, so you may as well get
the latest version. :) If you have made too many modifications, or for
some other reason want to continue using .qmail files, set the
./configure switch to block the new names. Unless someone has a good
reason to keep the old names, they should switch to the new ones.
I see limited benefit to changing at this point. If we're going to
> make vdelivermail more and more like qmail-local, then I'm for
> keeping the .qmail filenames.
I admit the benefits are fairly small. Newbies may have a clue that
some files are executed by vdelivermail and others by qmail; and we act
on one of the reasons vpopmail has a bad reputation of the qmail list.
That's it. <shrug>
I think if we are ever going to change, now is the time. Currently some
users may have one .qmail file in their directory. We just gave them
the ability to have a constellation of .qmail-extension files which
gives us an even bigger problem later.
John Simpson wrote:
> i agree- any files which are currently processed by qmail-local
> should retain the ".qmail-*" names, and others (i.e. the per-mailbox
> files) should use the ".vpopmail" names EXCLUSIVELY, so as to make
> it obvious to anybody poking through the directory structure that
> those files are processed by vpopmail rather than by qmail itself.
Exactly.
> as for making .vpopmail* files fully compatible with .qmail* files,
> that could also be a good thing- however the interface (in terms of
> which environment variables will be passed to scripts run from the
> .vpopmail file, what values will be contained in those variables, and
> how the return values will be interpreted) should be not only
> documented, but made to be as compatible as possible with what qmail-
> local would pass to a script in the .qmail file of a system account
> mailbox.
I'd bet a little bit that we are there already, I think extension
handling was the last missing piece. I compared vdelivermail.c with man
qmail-local and nothing stood out. Before I say they _are_ the same
I'll have to compare the source code of both and do some testing. Since
it took a week to write my last message, I make no promises when that
will happen... maybe I'll just wait till someone discovers a difference.
Rick.
