On Mon, Jan 15, 2007 at 05:43:51PM +0100, Tony Earnshaw wrote:
Giulio Fidente wrote:
Uhmmm ... maildrop can create both the user's (even virtual users')
$HOME/Maildir/ and all subdirectories; the only directory it cannot
create is the user's $HOME directory.
`test -d $HOME/Maildir/`
if( $RETURNCODE == 1 )
{
`/usr/bin/maildirmake $HOME/Maildir/`
}
thank you tony, anyway I think the question remains.
for example, in a standard environment with only posix accounts the
'Maildir' directory is strictly related to the email messaging system,
the $HOME directory is not and most probably already exist... so the
courier-maildrop works in the right way
but in a larger environment with multiple domains and eventually
separate stores, the accounts will be not posix but virtual and even if
the courier-maildrop contemplates this case, it doesn't fit well...
simply because if the $HOME directory is not already present, it does
not deliver the email
No indeed. The $HOME directory has to exist before $HOME/Maildir/ can be
created and that is why God invented Unix and shell scripting (the devil
Perl), just to take care of such eventualities.
Indeed. Which is why you put the creation of $HOME and $DEFAULT into
your account creation scripts where it belongs and _not_ in your
mailfilters.
Putting the $DEFAULT creation into your mailfilter means that the test
will have a useful outcome when the account receives its very first
e-mail but that test then gets invoked uselessly for the thousands upon
thousands of e-mails that follow. If you are running a mail site of
any size at all, then those disk accesses and processor cycles start to
add up. Why not just get rid of it and do it the right way from the
start?