FAQ - DbMailAdministrator (DBMA) V2.1.x Copyright 2004 **
Trouble? Contact: http://dbma.mobrien.com/DBMA_contact.htm
#################################################################
ABOUT RESTRICTGroupID
Q> I have five different groups I want managed by different people, each having access
only to the group they are administering and no other. How do I do that?
A> After DBMA has been configured from the GUI, "root"; can enable or
disable a very restrictive "RESTRICTGroupID" mode.
You must configure DBMA in your web browser FIRST before setting
DBMA to this "RESTRICTGroupID" mode.
Pay special attention to "Pre-Set Options"
You can pre-configure the default domain, disable statistics
(Recommended), auto-create alias, Default mailbox size
and so on. You have a lot of control over how the restricted Group Administrator
will use DBMA.
This option DRAMATICALLY REDUCES DBMA FUNCTION to a single group.
This feature also denies access to the "Configuration GUI" and to
all "Global Functions". The only way in which full function can be
returned is to (with root access) edit DBMA.cgi and comment out
the configuration setting which turns the mode on.
RESTRICTGroupID mode
- hard codes the "Group" you specify
- removes access to all Global Functions
- removes access to DBMA Configuration GUI
- restricts access to a single group
- prevents duplicate user accounts across mail Groups
- returns a notice and denies access if a search yields
a user outside the restricted group
To enable RESTRICTGroupID mode you will need to open DBMA.cgi
in a text editor and uncomment the "$RESTRICTGroupID" configuration
setting.
ONLY IF YOU WISH TO RESTRICT ACCESS would you uncomment this
line and set the $RESTRICTGroupID to the Group you wish to allow.
When you open DBMA.cgi in vi or whatever text editor you choose,
you will see what is set out below.
# $RESTRICTGroupID = '3'; Uncomment and set ...
This mode requires that a unique implementation of DBMA
be assigned to each Group Administrator,
each having their own (.htaccess) password.
This configuration has a very wide range of applications.
Here's your example.
If you were to have 5 groups and 5 Group Administrators
(you may call them "field offices" or "customers" or whatever),
you would need to do something like the following with
your DBMA installations. (This assumes you are on the console, telnet,
XTerm or whatever as "root". In Win32 Windows or X Windows
(Gnome/KDE/etc.), drag, drop and rename to your heart's content.)
> tar xvf DBMA_SQL_V2.tar
Point your browser to /dbmailadministrator/ and change the
configuration to suit your system. (This presumes you have your
DBI/DBD/MD5::Digest etc. PERL modules installed.)
DBMA will store the config data in a flat-file database.
Chown everything to the correct system user and group
(i.e.: chown www:www) and chmod 755 *.cgi,
just as you would do for a normal installation.
Now make unique copies of the works for each Group Administrator
> cp -r dbmailadministrator dbmailadministrator3
> cp -r dbmailadministrator dbmailadministrator4
> cp -r dbmailadministrator dbmailadministrator5
> cp -r dbmailadministrator dbmailadministrator6
> mv dbmailadministrator dbmailadministrator7
You would then have something like this:
/usr/local/www/dbmailadministrator3
/usr/local/www/dbmailadministrator4
/usr/local/www/dbmailadministrator5
/usr/local/www/dbmailadministrator6
/usr/local/www/dbmailadministrator7
... each package configured for your database. Nice. :o)
Next open DBMI.cgi in each directory and point $RESTRICTGroupID
correspondingly to the correct Group number.
(For some recommended conventions on assigning Group ID's,
you might like to take a look at "DBMA_User_Management.htm"
contained within the DBMA tarball or visit http://dbma.mobrien.com/.)
The link for the Group 3 Administrator would then be something
like: https://thehost.thedomain.int/dbmailadministrator3/
The link for the Group 4 Administrator would then be something
like: https://thehost.thedomain.int/dbmailadministrator4/
And so on.
( You could also build DBMA (in RESTRICTGroupID mode) into an
end-to-end secure and authenticated Web resource (authenticated SSL)
by which your external customers' Admin or internal/remote departments' Admin could
administer their own DbMail accounts. In the case where there are only
single known users of the resource you could easily use a self-issued
High Grade Encryption (AES-256 256-bit) server certificate if you don't have
nor want the cost of a 'store-bought' Server Cert (i.e. Thawte, VeriSign, SSL,
etc.). (http://www.ssl.com/ now offers an SSL128SCG2.5 single-domain
Cert for under $100. USD) )
Don't forget yourself. You should perhaps also install a
global (unrestricted) DBMA implementation for yourself or for
whomever you will designate as Senior Mail Administrator etc.
Remember to set unique passwords
( /usr/local/bin/htpasswd -cb .htpasswd user secret) and usernames
on your Inranet host for each of your mail Group Administrators either
with .htaccess or (preferred method) in your Intranet HTTP Daemon's
configuration.
ABOUT Operating Systems
Q> Oops. I have a Windows workstation. Can I use DBMA?
A> DBMA was built on Unix servers and tested and tuned on several Windows
variants. You can fully administer your DbMail IMAP / POP3 system using
DBMA on a Win32 host (NT4Server, W2kServer, WinServer-2003). On either
Unix or Windows, DBMA will start up instantly and fly up a configuration
window or just login to the database if the default configurations match yours.
If you are running Windows Server 2003 with IIS6, make sure that your CGI
is turned on for the dbmailadministrator directory. It is best to use PerlIS.dll
instead of the executeable (Perl.exe) and you won't even need to alter the
shebang line. Make certain that the *.DB files are writeable by the account
the server runs as (IUSR_hostname).
Be certain your PERL is up to speed by installing the needed modules.
Configure everything correctly and there's nothing you can't do from a
Windows box that can be done from a Unix host.
ABOUT Installation
Q> I just untarred DBMA into my web docs, what do I do next?
A> Point your browser to http://localhost/dbmailadministrator/
and a configuration window will open unless you do not have the required
PERL modules or unless your permissions have not been set correctly.
For missing modules (i.e.: PERL DBI): run this command
(perl -MCPAN -e shell) and then (install DBI). Do the same with
(install DBD::mysql) or (install DBD::Pg) if you are using PostgreSQL.
(i DBD::Pg). For the best help available on the subject of installing
PERL modules, visit http://www.cpan.org.
NOTE: This package requires the following PERL modules.
DBI and DBD for your database (i.e.: DBD::mysql or DBD::Pg)
CGI::Carp (Lincoln D. Stein's ubiquitous CGI.)
*NET::SMTP (part of Graham Barr's libnet.)
*Digest::MD5 (RFC 1321 MD5 implementation.)
*Crypt::PasswdMD5 (Poul-Henning Kamp's Unix Crypt.)
*included in this tarball.
HOWTO use the included module tarballs.
> cd dbmailadministrator/ready_to_install_modules
> gunzip module_name.tar.gz
> tar xvf module_name.tar
> cd module_name
> perl Makefile.PL
> make
> make test
> make install
HOWTO use CPAN to install/update modules.
> perl -MCPAN -e shell
> install Digest::MD5
> install Bundle::libnet
> install DBI
> install DBD::Pg
> install DBD::mysql
> install Crypt::PasswdMD5
ABOUT Scalability
Q> Is DBMA applicable to enterprise operations?
A> Scalability. Like DbMail, DBMA is vastly scalable.
Millions of users can be accomodated depending on the scope of your
database servers (or cluster). You might notice some terms of
reference in DBMA (GUI names) differ slightly from the table and
field names used in the DbMail database. DBMA is
a management tool as well as a customer support
tool. DBMA favours the use of 'friendly' terminology
which fits the most likely usage by front line
Level One Support people and by the 'machine room'
mail team. "Group" refers to the 'dbmail_users'
field 'clientid', for example.
Q>Is DBMA for ISP's too?
A> In the case of an ISP, each user is a client.
You might consider organizing your clients/users into geographic groups
or net segment groups or whatever you like, to keep the total number
of users broken up into manageable lots of up to 1000-1500
accounts per group. With just 999 groups you can
manage as many email accounts as some countries have internet users.
Both DbMail and the DBMA GUI are highly scalable.
ABOUT Useage
Q> What type of menus does the GUI use?
A> By using simple "radio check buttons" and pressing "SQL Tool" DBMA lets
you add or delete users, aliases, forwards, notifications, check mail
limits, monitor IMAP mailboxes, and more as well as show and modify
single users or display a list of all existing users in any group or all
groups displaying all information including current mail stats.
Q> Will DBMA delete user accounts?
A> Deleting the user removes the account as well as all aliases and auto
notifications for that user. Heed the 'Alert' popup asking "Are you sure
you want to do this?" Once deleted, all aliases, forwards, mailboxes and
mail associated with the deleted user are GONE for good.
Q> How do I delete aliases?
A> Remove separate aliases by User ID (even if the user no longer exists)
or by complete alias. Some orphaned rows may exist in your database
between dbmail-utils / dbmail-maintenance crontab runs. More often than
not this is an admin-user error. Hush. DBMA can help you monitor and
oust straggler aliases. Just type the full alias and press "Delete
Alias" and presto it's gone. In the alternative you can type the UserID
and press "Delete All Aliases" and zap, they are all gone.
Q> How do I manage "forwards"
A> Forwards including external address forwards like [email protected]
==> [email protected] are accomplished by checking 'Add Forwards'
and pressing the "SQL Tool" button from the Admin page. You will get
another GUI window which is self-explanatory on adding email internal
and external forwards. You can also list all the forwards and delete any
which need to go.
Q> I keep finding deleted_flag "1" and status "000" no matter how many
times I run dbmail-util/maintenance. Can DBMA help?
A> Yes. In the global functions (right-hand-side of menu)in the full
administrative configuration(i.e.: not RESTRICTGroupID) since v2.1.2
there is a "Update Delete Status"check box.
Select it and press "Go". DBMA will set 'dbmail_'messages.status
to '003' where the deleted_flag has been set to '1' by the user client.
This setting will mean that the next crontab run of "dbmail-util -d" will
remove all "003" status messages from the system's database.
Q> I have "orphaned messageblks" what can I do?
A> Select "Update Delete Status" check box and press "Go"
DBMA is a good fixer. When you select "Update Delete Status" the function
"fix_deletes" searches for:
1. messages marked delete by the client;
2. messages having no 'owned mailbox' (whatever the reason, it happens); and
3. messages having no owner (somehow owner got deleted but not their messages)
If DBMA finds some orphaned messages DBMA will, with nicely executed grace,
set their dbmail_messages.status to just a 001 and their deleted_flag to a
certain "1" preparing them for the ultimacy of the utilities firing squad.
Why 001? In case you learn that you accidentally deleted a good user account
and need to reinstate them (keeping their messages) in the next few hours or
seconds as the case may be in terms of dbmail utility crontab runs;
you are covered somewhat in the extremely unlikely case of your user-delete
booboo. (In that case use the DBMA create User" function, create the user,
open their account; open their mailboxes and presse the "Undelete all mail.." button.
If you again hit "Go" on the "DBMA::Update Delete Status" checkbox
any orphaned messages that DbMailAdministrator (DBMA) found here will be
escalated to 003 (the biblical "kiss on the cheek") in a FLASH and deleted
from the database on the next Utility/Maintenance run. You will perhaps
someday appreciate this two-step flexibility.
NOTE1: The Update delete status function is not available to
"Group Administrators" under the RESTRICTGroupID constrict.
NOTE2: Look for changes in the MAIN MENU statistics column:
"Number of deletes pending"
Q> What is the best way to structure my user regime?
A> Please visit
/managing_users_with_dbma.htm
for a detailed discussion which may help you establish your user architecture
and some policies to boot.
Q> How do I handle duplicate users?
A> Let's face it, public email addresses uniquely identify each person
on planet earth. As a mail administrator or postmaster you already realize
that folks take their email address and their email seriously and personally.
Very much so. Keeping the mail running and folks happy is your aim but you
will encounter many heretofore inconceivable complaints or requests from users.
It's nice to know you are ready for most anything.
So, the new user wants the name "bob" in his email address, empatically.
You already have a "bob" (or whatever the request may be) at another
virtual domain and this new user who wants to be "bob" won't take no for
an answer. No problem. Use DBMA with "Add User" checked to open an
"(Add) User" window. Type a uniqe name like "boblastname" for the "User
Name", enter the new Bob's password and "Client (Group) ID" then enter
the email address as "[email protected]". Bob must login with
account name "boblastname" but his email address is
"[email protected]". All mail for "[email protected]"
will go to the mailbox of "boblastname" and the other "Bob" is unscathed
by all this.. You can have as many "bob's @ different_domains.tld" as
you like.
Q> Will DBMA encrypt user passwords for me?
A> Yes. Many people will find that plain text passwords are
sufficient for email user accounts. If that is not true for you, DBMA
will encrypt your passwords. Choose from md5-hash, md5sum or crypt.
Auto Notify is accomplished by knowing the UserID number of the user you
want to cause a notification. Enter the UserID number and the full email
address of the mail box you want a notification sent to. It will work
like a charm.
Q> Must I encrypt user passwords?
A> When you are creating or modifying a user account in DBMA you are given
the option of encrypting passwords. Keep in mind that this applies only
to the password communication between DbMail and its database and how the
password is actually stored in the database. Unless you are using one of
the many options available for authenticating encrypted user passwords
across the internet; on ports 143 and 110, plain text login passwords are
passed across the internet. So also are the emails passed in plain text.
If someone wants to read your emails they certainly don't need your
POP3/IMAP login password. Best practices suggest however that you do
encrypt the password. DBMA developers sugest you encrypt your user
passwords but it is entirely up to you.
Q> Some accounts have many aliases. How do I do that, fast?
A> A simple way to add an alias is to call up the user in a manner of your
choosing and then use the "Modify..." button. In the window which
appears, without changing any of the main entries, add an alias to the
"alias" text window at the bottom and press "Update". A similar window
will popup again showing the change. You can repeat the above over again
to add more aliases very quickly.
Search for users can be accomplished using the email address, the user
name or the user ID number. Your most unequivocal method uses the ID
number.
Q> Will DBMA give me a cross section of users, say in a single group?
A> You can view all users in all groups by selecting "List all users all
group" and pressing the "Go!" button, but if you have 100 groups each
with a thousand users, you won't be seeing the list for quite some time.
To be more selective, in the top row of functions, enter the group
(ClientID) number and press either the "Users" or "Aliases" buttons. An
alphabetical list will appear. Click the name of the user or alias you
wish to modify and a data page for that user will open. If it proves
true that this is the user you seek, press the "Modify User" button and
make your changes, updates or whatever.
Q> How do I find accounts where I only know the alias?
A> List Aliases GUI helps you manage scores of information and functions;
forwards or aliased accounts and more. You can list every alias but if
the numbers are high you should limit the display to under 1500 users.
The ideal method is to list aliases by groups. Mail forwarders can also
be listed separately. Each alias listing has a link to a data window or
a search function. In the case of an external forward you obviously will
not find the alias as a user account but in the case where you have
[email protected] forwarded to [email protected], the
two links will take you to the User Data Window for the two
corresponding user accounts. Did you follow that? Each line has two
links. The mail for x@x goes to xx@xx. It is possible that the link on
the right is an external address. Clicking it will fetch an "account
doesn't exist" message. On the other hand, accounts like "noc", "dns",
"abuse", "privacy" etc are likely aliased to the addresses of persons or
titles. The DBMA Alias List GUI allows you to quickly select which
Account window you wish to open, the account with mail forwarded (left
link), or the account where the mail goes to (right link).
Q> We have a little newsletter. How do I make sure everyone in my group gets it?
A> Distribute your NewsLetter with forwarding is one good option.
If you are creating forward aliases like
"[email protected]" to be forwarded to each and every
user at "@ourdomain.tld" you might forget to actually create the account
"newsletterfromtheprez", but if you thought "Flubber" had bouncing problems,
watch what happens with this scenario when things go wrong. In other words,
if you are going to create a "newsletter" alias for mail distribution to
various mail account groups, for each "newsletter" forwarder, create a
full user account for your "newsletter".
Q> I know the user's name. How do I fetch that user's account?
A> To view the data for a single user, type the user's name or ID number
beside the "Get User" button and press that button. From there you can
modify or even delete the user.
Q> I have an older version of DbMail. I get blank rows in some DBMA columns?
A> Earlier versions of DbMail do not have a "curmail_size" column in
the "dbmail_users" (users) table. The 'listall' sub-routine of DBMA runs
a sequenced query across the "dbmail_users" (users) table and will stop
at Current Mail if the field does not exist. The information is available
by clicking the user link and opening the User Data Window. "Last Logins"
will not be displayed, however, in the user listings where curmail_size
does not exist. There are two ways to correct this situation. Add the
field (`curmail_size` bigint(21) NOT NULL default '0';) to the 'users'
table, or upgrade to the current version of DbMail. We reccommend the
InnoDB database for MySQL if you are going the upgrade route.
|