A typical response to someone converting from Sendmail
>Currently we store and maintain all our users in Mysql.
> We generate the
> passwd, shadow, access, aliase and virtusertable from the database for
> sendmail. Here is the key elements:
>
> * For each user,
>
> - user name is unique.
> - password is Linux style, not Mysql style.
> - all users are maintained by existing programs. Thus the user
> maintenance feature of dmail is not needed.
> - with these setting, our users have these simple set up in their email
> programs:
>
> # outgoing email server: mail.bob.com
> # incoming email server: mail.bob.com
> # incoming email account: ...their.login.name...
> # incoming email password: ...their.login.password...
>
> * For all users,
>
> - aliases to equate different names to the same user
> - aliases to provide email forwarding. We do not use .forward files as
> there is no real home directory for the users in the mail server. -
> aliases to provide lists or multiple forwardings
>
> * For virtual domains, using virtusertable,
>
> - maps domain email addresses to unique user names.
> - define default email address or user for each domain.
>
> As an on-going business, we just cannot stop the current email
> arrangement and ask all users to change their settings. How can dMail be
> programmed to simulate the above settings?
>
> We maintain our own database and do not mind if I have to create or
> modify tables to suit the dMail structure. Please give us some
> suggestion and do not hesitate to ask if there is any query.
You have 2 options.
1. you can continue to use the same system
password file,passwd, shadow, access, aliase and virtusertable
created from the database. You should find that there is not too much to
change in converting to DMail.
2. you can run our new SQLAuth authentication module
so that the DMail servers talk directly to the MySQL database.
I suggest that you start with 1 as that will be quickest and
then once you are happy with that you can look to simplify your
setup and take advantage of things like our proper virtual domains
(rather than the virtusertable) by moving to option 2.
So for option 1, here are the things that I can think of for you to
consider, in addition to what is in the Moving to DMail FAQ (i.e. this page)...
1.RE: system password file, i.e. passwd and shadow passwords
If you install DMail on a linux box it will default to,
authent_method unix_user
in /etc/dmail.conf.
This means that DSMTP and DPOP will use the standard system user
calls so you should not have any problems staying with those files
as your mail user database.
(Note: Because your usernames are unique and I presume they are
not the full user's email address, you do not need to use
the authent_domain or preserve_domain settings, which you will see talked
about throughout the manual).
2. RE: access
I don't know which file you are talking about. I presume that it is for
restricting who can access the server - maybe to stop you from being
an open relay and other uses.
Can you send me an example of this file and tell me more about its function.
3. RE: aliases and virtusertable
DSMTP uses the sendmail style alias files (99% of features are covered), so again you should not have any problems with these. They are specified for you main domain (as set by the first host_domain setting in dmail.conf),
alias_file <filename>
and for specific domains with,
alias_file_domain domain <filename>
where domain can be a wildcard, e.g.,
alias_file_domain *bob.com /etc/aliases
We have also recently added support for sendmail's virtusertable. Previously you had to convert all entries within that table to a mixture of our dmail.conf settings,
forward
forward_cc
fallback_address
and aliases within alias files.
With beta version 2.8d, you should be able to use the setting,
virtual_user_pre <filename>
and it should work without modification.
NB: virtual_user_pre is a new beta feature so be aware that it is possible
there are problems with it. Please let me know straight away if you
come across any such problems.
Version 2.8d is available from the
beta directory
of our site.
4. general settings:
I recommend that you take advantage of the free trial period to set up
a test box using your configuration. If you come across any problems
please send us your dmail.conf file and either the dsmtp.log or
dpop.log file showing the problem from the log_path directory. NB: it
is best to send us the logs created when the logging level is set to debug.
To set this edit log_level to read,
log_level debug
and then reload both dsmtp and dpop with the commands,
tellsmtp reload
tellpop reload
(as required by most dmail.conf settings).