Sorry this took so long to get written, I've been busy at work...
First a quick review of the new features added to the 5.4.18 release:
o The option of running a script each time a user or domain is added,
deleted or modified. This can be used for sending notification
messages, maintaining a list of valid users and what ever else you may
need to do. See README.onchange
o .vpopmail-extension abilities just like .qmail-local. Is there
anything left qmail-local does that vdelivermail does not? If there is,
should we consider it a bug and match qmail-local 100%?
I think vpopmail extensions should default to on, maybe even drop the
./configure option. It acts the same on existing setups and adds new
functionality. Is there a good reason to be able to disable this at the
./configure level? A disable bit in gid-flags is probably a good idea
so the system administrator, and domain admins can control it on
individual users.
o Complete alias handling. With this version you can add an address to
an alias, delete an address from an alias, delete an entire alias, or
delete all aliases from a domain. That pretty much takes care of all
the possibilities for unordered aliases. Full support is available in
cdb and MySQL back ends. The MySQL code can be used as a template for
other back ends.
--------------------------------------------------------------------------
Back to the future... after reviewing the threads '5.4.17 patches',
'.vpopmail instead of .qmail' and '5.4.18 & valias' this is what I think
should happen in 5.4.19.
I think the best thing to do with the localrelay patch is to put it into
the contrib directory where people who need it can find it easily. The
main reason I think this is because smtp after pop is obsolete. All the
email clients I know of have handled smtp auth for years now, and the
best thing we can do for the average user is to let smtp after pop die
off. Drastic improvements in the mainstream code will send the wrong
message.
I wrote the paragraph above before reading the 'Further thoughts...'
thread on Jan. third. If you want to do massive changes they will get
added, but is it really better than recommending smtp auth for everyone
and letting smtp after pop die?
I did not see any objections on changing to .vpopmail* files in user but
not domain directories. If anyone does object, now is the time. Files
in ~vppopmail/domains/user_name/ are executed by vdelivermail and will
be renamed. Files in ~vpopmail/domains/ will stay .qmail and are
executed by qmail-local.
Vdelivermail will look for .vpopmail files and .qmail files in the users
directory. If both exist, only the .vpopmail file will be executed. If
it does not check the sticky bit and defer messages like qmail-local it
needs to. Editing a user .qmail file with the library should result in
it being renamed to .vpopmail. If both exist, the .qmail file is
ignored. UPGRADE will recommend running Jeremy's script to bulk rename
the files when you install.
Adding an order field to aliases... I think we should "just say no!" to
ordered aliases. With 5.4.18 all the basic operations on an alias are
available. We just declare that you can not count on the order of
delivery of an alias, and call alias handling complete.
I realize that sometimes order is important. I propose to provide
another interface similar to aliases that are always ordered, called
scripts, or more formally mail scripts. Vdelivermail already supports
alias handling from a database so scripts and aliases should be able to
share the same code, if not the same table.
There are good arguments that scripts are best implemented as .qmail or
.vpopmail files but vdelivermail already supports all the delivery
methods from a database, and it will continue to do so. On the other
hand, I plan to do all I can to steer people towards using files for
mail scripts.
Once the script functions are added I plan to add a template system that
allows the system admin (or anyone with admin and expert abilities) to
manage the templates. Scripts will start with a comment that identifies
what kind of script they are. The comment will come from the template,
or be generated the first time an existing file is created.
Template system examples:
Template for a blackhole, .templates/blackhole
--------------------------------------------------------------------
Blackhole (Name of template)
A black hole deletes all messages sent to it.
The description can be more than one line, and ends with a period
on a line by itself. That line is not in the description or the
template code that follows it:
.
# blackhole
--------------------------------------------------------------------
This creates a .qmail or .vpopmail file containing:
--------------------------------------------------------------------
# blackhole
--------------------------------------------------------------------
Template for a qmailadmin like autoresponder, .templates/autorespond
--------------------------------------------------------------------
Autorespond
This template implements an autoresponder similar to the one
already provided by qmailadmin.
.
# autorespond
|$Autorespond_Path 10000 5 $UserDir/message $UserDir
&$Forward_To
--------------------------------------------------------------------
This might create the file .qmail-robot in the domain directory:
--------------------------------------------------------------------
# autorespond
|/usr/bin/autorespond 10000 5 /mail/domains/example.com/ROBOT/message
/mail/domains/example.com/ROBOT
&[EMAIL PROTECTED]
--------------------------------------------------------------------
(Ignore the line break in the autorespond command, it should all be one
line.)
Since vdelivermail already supports alias handling it will be left in
place. Scripts and aliases will share the same table. If any sequence
is non-zero it is a script.
Feel free to try to talk me out of scripts in the database at all! It
won't take much.
An alias will be a type of mail script. The first line in an alias will
be a comment that identifies it as an alias.
---------------------------------------------------------------------------
Finally, my response to various questions from the list...
there is a possible race condition- if process A is doing a delivery,
looks for a ".vpopmail" file, and doesn't find one, then process B
takes over and renames a ".qmail" file to ".vpopmail", then process A
takes over and looks for a ".qmail" file, then process A will think
that no file with either name exists.
The reader process needs to keep the stat that verifies the file exists
and the open close together. The open needs to handle the case where
the file suddenly disappears, possibly by sleeping for a few seconds and
trying both file names again. The writer process will copy the existing
file into a new temporary file, make its changes, then rename the file
to the vpopmail name. If the original file was a .qmail file deleting
it will be the last operation.
i think a safer way to do it would be to have a script which finds and
renames the files as needed, and tell the users to only run the script
while qmail-send is stopped. if they're upgrading the vpopmail binaries
anyway, they will probably be in some kind of maintenance window to
start with, and stopping qmail-send won't be a major deal.
I agree we should include or point people to the script, but if they
don't run it, I still want to change files to .vpopmail, unless they go
out of their way to disable it. I think Charles Cazabon's objection to
.qmail files that are executed by vdelivermail is a strong enough reason
to do so. I want to eliminate as many of his objections to vpopmail as
I can.
i had one incident where the domain's admin didn't realize that this
one alias was "special"- he accidentally added a new employee after the
text searching program instead of before it. i ended up having to fix
it by hand (after he realized that he couldn't fix it using qmailadmin
and called me about it) and at the same time i made it owned by root
and "chmod 644", so it works but qmailadmin can't change it by accident
any more.
granted, it's the only such alias i have, and i know the people
involved and their job functions well enough to be able to re-create
the .qmail-help file from memory if needed, but not everybody knows (or
wants to know) their clients' businesses that well.
In my vision, that would be a mail script that you create by logging in
as a user with expert rights and creating a custom script. The system
will protect your script from other administrators within the account.
The only thing non-experts can do with an expert edited script is delete
the whole thing. They will be warned that they can not edit or recreate
what is there before the delete.
Maybe you should write an expert script that forwards to one alias, runs
the program then maybe forwards to another script. That would allow
non-expert users to manage the address lists without touching the part
that checks for keywords.
besides, i'm not sure i understand the point of sorting the entries,
either within a .(q|vpop)mail file, or within the qmail control files.
there are certainly no performance reasons, and if you're trying to
encourage people to use the API instead of manually editing the files
(and potentially introducing errors) then i would think as long as the
files work the way they are, why worry about sorting them at all?
Completeness. Domains are sorted. Users are sorted. The list of
aliases within a domain is sorted. The list of addresses within an
alias should be sorted too. All that is to allow vpopmaild to handle
breaking result data into pages without having to load and sort the
entire dataset each time a web based interface requests a new page.
how often is one program invocation going to actually perform more than
one operation on a given alias? not very often, if at all...
For a list of addresses one line at at time will be fine, on the other
hand mail scripts pretty much need to update the whole thing each time.
Template expansion can produce multiple lines, and I want to be able
to allow 'experts' to edit .qmail files in a HTML TextArea.
3) Most importantly, to me the idea of storing aliases in the DB is just
that - it's for aliases. If you have a program that you want to pipe
the message through, or send a copy of your mail offsite, I'd much
rather have that be via .qmail file and not as a database line.
That is an example of the argument for not using the database for
scripts. I'm on the fence about it. A lot of work has gone into
vdelivermail to allow it to do aliases from a database, and there has
been considerable work on extending that to scripts. I would be happy
to just say that scripts should be stored in the filesystem, but it
seems a lot of database users want to keep everything in the database.
Let the argument commence...
I'm OK if you want to try to extend the functionality of Vpopmail to do
more stuff, just please don't break the current way of doing things.
I don't think I'm breaking any existing functionality. If you see
something that my plans would break, please let me know. Backwards
compatibility is very important.
