-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 2009-02-25, at 0610, Robert Schulze wrote:
There is a mailbox called "baz2-bla", the user enabled the
copy&forward feature. The file ".qmail" gets created under /var/
qmail/vpopmail/domains/foo.bar/baz2-bla/ but will never be
recognized by qmail.
that file would never be recognized by qmail anyway. normally it would
be used by "vdelivermail", from the vpopmail package. (they should
have named the file something else, this confuses more people...)
If I copy the contents from "/var/qmail/vpopmail/domains/foo.bar/
baz2-bla/.qmail" to "/var/qmail/vpopmail/domains/foo.bar/.qmail-baz2-
bla", then the behaviour is correct.
at first glance, yes.
but because vdelivermail is no longer part of the process, the user's
quota is not being enforced. a domain-level ".qmail-mailbox" file is
processed by qmail-local, instead of the .qmail-default file causing
vdelivermail (which enforces quotas) to run.
Is this a bug with qmailadmin?
no... it's either a bug in vpopmail, or it's an unfortunate choice of
mailbox name.
qmail-local treats "-" as the separator between mailbox names and
extensions when building the EXT, EXT2, EXT3, and EXT4 environment
variables. this cannot be changed without patching qmail's source.
i'm looking at vdelivermail.c from vpopmail-5.4.26d. in the
get_arguments() function, at line 218, is a block of code bracketed by
"#ifdef QMAIL_EXT" which searches the "userid" portion of the email
address (from the EXT environment variable) to find where the real
mailbox name ends and the "extension" begins.
the code works by scanning the string from beginning to end, looking
for the "-" character. when it finds one, it ASSUMES that's where the
name splits. in your case, it determines that "baz2" is the real name
of the mailbox, because that's where it sees the first "-" character.
in the code is a comment about scanning backwards (i.e. from the end
to the beginning.) this comment is correct, the scan should be done
backwards so that "baz2-bla-abc" would be correctly interpreted as
"baz2-bla" for the mailbox name, and "abc" for the extension. in
addition, there should be an is_username_valid() call before the loop
ever starts, just in case "baz2-bla-abc" is also the name of a real
mailbox.
the other way to "fix" the bug would have been for vpopmail to simply
announce, back at the beginning, that mailbox names cannot contain the
"-" character. this would probably cause a lot of trouble for people
now, but if it had been a known issue back then, it wouldn't be a
problem now because you wouldn't have assign "baz2-bla" as a real
mailbox name to begin with.
Could this generally be fixed by always using ".qmail-user" files in
the domain directory?
yes, if the mailbox(es) aren't subject to quotas.
it might be possible to create the .qmail-mailbox-ext file in the
domain directory in such a way that it still uses vdelivermail, but it
manually specifies the mailbox directory and mailbox name (to dis-
ambiguate the decision of where the mailbox name ends and the
extension, if any, begins) on the command line. this would require re-
writing vdelivermail, changing qmailadmin, and possibly changing the
existing .qmail-default files at the time you do the upgrade, but it
might be worth it.
but until/unless the vpopmail developers actually fix the problem, the
work-around is to never use mailbox names with "-" in them.
- ----------------------------------------------------------------
| John M. Simpson --- KG4ZOW --- Programmer At Large |
| http://www.jms1.net/ <[email protected]> |
- ----------------------------------------------------------------
| http://video.google.com/videoplay?docid=-1656880303867390173 |
- ----------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
iEYEARECAAYFAkmlv/MACgkQj42MmpAUrRpZrgCgq+prHlMGnADvaXOshFEA00J7
MHAAn3h6+ZdObREJWAUric7tyX4VP8nV
=0oer
-----END PGP SIGNATURE-----
!DSPAM:49a5bffe32682009826947!
