-----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/                         <jms1@jms1...> |
- ----------------------------------------------------------------
| 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!