[ Following up to my own message... ]
Tim Legant <[EMAIL PROTECTED]> writes:
> I have some scribbled notes about the two mail managers. I have been
> busy (and out-of-town) and haven't had a chance to think through all
> the ramifications. I'll try to post something tomorrow (Thursday,
> 12/19) about what I've figured out.
Hmph. That whole busy thing hasn't stopped. I hope to spend Monday
and Tuesday on this problem.
I will explain. No, there is no time. I will sum up.
There are two virtual domain manager add-ons for qmail: VPopMail and
VMailMgr. In neither case do virtual email users correspond to local
Unix system users. They are not listed in /etc/passwd and do not have
home directories discoverable by the system.
There are two variations on how external or "roaming" users indicate
their username and domain to the software.
1) The user can configure his/her email client with a POP/IMAP
username of '[EMAIL PROTECTED]' or 'user%domain.com'. This allows
the use of multiple domains on a single IP address.
2) The system administrator can use a unique IP address for each
domain. This means a user can configure his/her email client with
a POP/IMAP username of 'user', in the typical POP fashion. This
also means that tmda-ofmipd has absolutely no idea what the domain
is.
In no case does tmda-ofmipd (currently) parse or attempt to understand
the virtual user's name (or domain). It simply passes it whole to
whatever authentication mechanism has been specified.
Using the checkpassword, POP or IMAP authentication, tmda-ofmipd can
authenticate the virtual user, but when it tries to set effective UID
(in the case where it's run as root) or pass the --config-file
parameter to tmda-inject (when it's run as the vpopmail user, e.g), it
dies, since in the first case there is no system user and in the
second case, it's passing a path based on the home directory of the
authenticated user and again, since there's no such system user,
there's no such path. The --config-file path generated by
tmda-ofmipd, in case number one above, ends up looking like this:
~[EMAIL PROTECTED]/.tmda/
Ick.
In VPopMail's case, the path to a user's home directory is often
/home/vpopmail/domains/example.com/username/
However, if your installation supports a large number of virtual
domains, the directory search in .../domains/ can be slow (Unix
file-system issues), so VPopMail provides a compile-time option to use
a hashing mechanism to spread the domain directories across a tree.
In that case, the path to a user's home directory will look something
like this:
/home/vpopmail/domains/9/example.com/username/
where the '9' is one of a number of sub-directories, depending on the
hash.
So what's the best way to figure out the path to the user's home
directory for use in constructing the --config-file option to
tmda-inject? Jesse Guardiani suggested a simple script (two, really,
one for each virtual domain manager) that, given the username and
password, would print the full home directory on stdout. tmda-ofmipd
would run one of these (based on a command-line paramaeter), read this
output and use it to construct the --config-file path.
I would imagine we would distribute these scripts (Python, shell,
whatever) in our contrib/ directory. I will personally take
responsibility for the VMailMgr one. Hopefully one of our VPopMail
users will step up and build the VPopMail script. I can't imagine
these being more than a few lines that call the appropriate virtual
domain manager utilities, parse the appropriate information out of
their output and print it.
Another factor with VPopMail is that, in order for IP-based virtual
domains to reverse properly (with a username of just 'user'), the
TCPLOCALIP environment variable must be present and must contain the
IP address of the server. This comes from the assumption that the
VPopMail utilities are running during an SMTP session under qmail. It
is not a problem to set this from tmda-ofmipd, but it is something we
must remember to do.
Finally, it would be of great value to have this exact information
(the virtual user's home directory) available to the configuration
files, particularly /etc/tmdarc. With this path, in many virtual
installations a per-user config file would not be necessary. The
DATADIR, LOGFILE_* and FILTER_* config options could be set from the
global tmdarc. This would be the equivalent of making the
os.path.expanduser() Python function work for virtual domains.
I do not know how to do this cleanly yet. I hope to figure out how by
Monday and build this capability into tmda-rfilter and tmda-ofmipd by
Tuesday. If anyone has any ideas on how to integrate this information
into filename paths, please speak up.
If any of you -worker types have any questions about this email,
please ask specifically. I'll try to answer and clarify anything that
comes up between now and Monday.
Whew.
Tim
_________________________________________________
tmda-workers mailing list ([EMAIL PROTECTED])
http://tmda.net/lists/listinfo/tmda-workers
