Ben Rosengart writes:
This behavior seems to vary with the setting of
"--enable-restrict-trusted" for some reason. If it is set to 1,
then the userdb is consulted, but delivery to users with UIDs other
than the trusted one is impossible. If it is set to 0, then the
below-described behavior occurs. Please advise.
What exactly is unclear about the following description from INSTALL:
* --enable-restrict-trusted=flag - if set to 1, maildrop permits
only certain "trusted" user or group IDs to use the -d option.
Setting this variable to 0 allows anyone to use the -d option
(provided that maildrop has set-userid-to-root privileges). This
allows certain denial-of-service attacks, so this setting is not
recommended. The default value is 1.
* --enable-trusted-users='...' - sets the list of users allowed to
use the -d option if --enable-restrict-trusted is set to 1. If
--enable-restrict-trusted is set to 0, this option is not used.
Put a list of user IDs allowed to use the -d option between the
apostrophes, separated by single spaces. If your mail transport
agent uses maildrop as the local delivery agent this list must
include the userid that the mail transport agent runs as. If this
option is not specified, maildrop attempts to put together a list
including common mail system user ids.
16 messages in net.sourceforge.lists.courier-maildrop[maildropl] Re: maildrop 1.5.0 not fi...
.userdb
