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.


> 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.


Reply via email to