User	Group	Group
Users Aliases Forwards Special Global Add User Add Aliases  Add Forward Add Auto Notify List all users all groups Delete User Delete Aliases Delete Forward Delete Auto Notify List All Aliases Email a User List Aliases List All Forwards List Auto Notifications Logins Last hrs Configurations Encrypt Tool Display: 100 500

Version: 4.0.20-log
User Table Details
Number of users:  567
Number of aliases =  1137
Configured Auto Replies =  0
Configured Auto Notifications =  11
Recent logins =  7
Mail Table Details
Mailboxes =  85
Messages =  0
Physical Messages =  0
Message Blocks =  0

Checking MailBox Content

Part of the job maintaining your DbMail system will be making certain that mail marked for deletion is getting deleted when your crontab dbmail-utils run. DBMA will help you do that as well as maintain a close eye on mail distribution. In each user account window are listed the users mail boxes. Clicking the mailbox icon brings up a technically detailed list of all mail in descending order displaying physmessage_id, message_id, internal_date, unique_id, rfcsize, blockSize etcetras. Below is what you will see. You can also access messages making certain they are being stored intact by clicking the email icon on the left side of each listing. This is a good method for checking headers as well.

Group ID's

The term GroupID is indigenous to DBMA and should not be confused with Unix-Group or other IMAP daemons use of the term "Mail Group"

The GroupID is a structural organization within the database. Users are organized into client_idnr's. You can have as many GroupID's as you wish. Thousands, if you like; whatever your database setup can handle.

The DbMail structure in this regard is unique. You will see that it offers excellent feature possibilities and is more "future-proof" than most alternatives.

You might notice that several terms of reference in DBMA (GUI names) differ slightly from the table and field names used in the DbMail database. 

The Mail Administrator is seldom a database engineer and likely wants to work in his/her own terms of reference.

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 as well as the 'machine room' mail team. 

"GroupID" refers to the 'dbmail_users' field 'client_idnr'. 

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. 

DbMail does not in any way discriminate client_idnr's (GroupID). This is for local use. There are things like a patch to enable group quotas with PostgreSQL and other ideas will come along. You may have your own database schema change ideas. That is beyond the scope of this article.

GroupID's Common Practice

Let's consider some common practice guidelines for "GroupID's'

You will find that DbMail developers are going to claim Group "0". In it will be internal use members like the "Delivery Agent or  Anybody for ACL "public" folders.

DBMA restricts (not denies) access to GroupID "0" just in case a "newbie" accidentally deletes the delivery agent. That would make a mess, wouldn't it? You can still list users in Group "0" by selecting "List any and all" but there are limitations imposed against open access to GroupID "0".

Down the road, your own system team may have an internal-system special user to add to this group.

Can we set aside groups 1 and 2 for local admin use? That would include mandatory and useful network and systems administration addresses plus common, never accessed generic business accounts. They could be accounts that never actually receive mail (forwarding everything to real people) and which have horrid passwords known to no one, encrypted with an MD5 hash using a eight character random salt key.

Example GroupID Structure:

Your permanent pseudo accounts, organized by groups, can store mail in the accounts of real humans (in the humans Group) and can be easily changed from time to time to point to different humans as they come and go.

The easiest way to do this with DBMA is to create the account with a wacky encrypted password say for "info" WITHOUT an alias. If Harry Smith is responsible for answering queries to "info" open Harry's account and add an alias "[email protected]". All mail for "info" will go to Harry.

GroupID 0 is Reserved for The MAIL DELIVERY SYSTEM

• secret black magic users owned by the internal system

GroupID 1 Systems and RFC-required access points

• user: postmaster,  password: **encrypted-DBMAutogen-unknown**
  alias: James_elected_postmaster@your_domain.tld ==> user_idnr of James
  
  
• user: abuse,  password: **encrypted-DBMAautogen-unknown**
  alias: [email protected]_domain.tld ==> user_idnr of human_name
  
  
• user: dns,  password: **encrypted-DBMAautogen-unknown**
  alias: [email protected]_domain.tld ==> user_idnr of human_name
  
  
• user: privacy,  password: **encrypted-DBMAautogen-unknown**
  alias: [email protected]_domain.tld ==> user_idnr of human_name
  
  
• webmaster, hostmaster, noc, spf, etceteras....

GroupID 2 Business Generics

• user: info,  password: **encrypted-DBMAautogen-unknown**
  alias: Sue_PR_Mgr@your_domain.tld ==> user_idnr of human_name
  
  
•  user: sales,  password: **encrypted-DBMAautogen-unknown**
  alias: Bob_salesmanager@your_domain.tld ==> user_idnr of human_name
  
  
• user: contracts password: **encrypted-DBMAautogen-unknown**
  alias: Sam_the_Lawyer@your_domain.tld ==> user_idnr of human_name
  
  
• help, support, accounts, receivables, eteceteras....

GroupID 3

• Real People eteceteras...

Adding Users and Aliases  - Configuration Defaults

1. A user name is the local part of [email protected].
2. The whole address, local part at domain part, is entered as an alias.

DBMA's options (select "configurations" and press "Go" button) configuration allows an automated method for cutting down the number of key presses when entering a large number of new users. Just type the users name and DBMA will create the account. 

These options can make adding new users a snap.

If you complete all of the optional configs, creating a new user is a matter of typing the name. You can populate your database with a large number of users in very short order. 

Auto-Password

DBMA will refuse to encrypt an auto-generated password until you have told the user what is their password. Well, that's isn't quite true. DBMA is not triggered to release a constraint once an email has been sent. DBMA will instead refuse to encrypt an auto-generated password from the initial create-new-user regime. Your next window will show the created password and give you a button to press to notify the user of the password. Remember that you may need to send this message to an alternate address like "[email protected]". If you don't have such an account from the user, and the user is local, use your browser's PRINT command, [Cntrl P] maybe, and print the mail message, stick it into an envelope and mail it or give it to the user. There isn't much point setting a new password and sending the message about that to a locked mailbox. 

(You can alter the encryption type and password of auto-gens in the user modify form. By forcing plaintext initially, DBMA saves you some annoyance if you forget to jot down the password because it's still visible. You can always change it to an encrypted form once the user is notified and has logged in at least once. You will know this from checking your recent logins with DBMA.)

Password Encryption

Yes. You really should, especially if yours is a corporate, ISP or enterprise system. DbMail uses "crypt", "md5" and "md5sum" in addition to clear text (plain). What follows is a set of encrypted passwords using the string example "encrypthelp"

DbMail uses "crypt", "md5" and "md5sum" in addition to clear text (plain).

 Encryption in the database makes no difference to the user's email client as it will be passing the 'secret' in plaintext. There is something ironic about that, but best practices say don't allow access points to your database through unencrypted user (data) accounts. Under most circumstances you are only putting at risk the user's mail, but don't be too sure that some messed-up-brained attacker couldn't plague your database server with a little bit of access. The choice is yours to encrypt or not to encrypt. You will find wide ranging views on the subject.

Keep in mind that this discussion of encryption applies only to the password communication between DbMail and its database and how the password is actually stored in the database. The user's handling of their password is in plain text.

Let's put this in perspective with a hypothetical anecdote.

You are sitting at your workstation as a Level One Support person in a corporate environment. Open on your workstation screen is DBMA displaying the Corporate Management group of users: rows of executive mail accounts all with plain text passwords in full view. The CEO walks by and sees his name and 'secret' password (fifi~loves^me2) on your giant flat screen along with those of the VP Finance, VP Legal, VP Human Resources, Payroll etc.

Like Donald Trump says, "You're fired!".

Storing encrypted passwords is the right choice.

Unless you are using one of the many options available for authenticating encrypted user passwords across the internet; on 143 and 110, plain text login passwords are passed across the internet. So also are email messages passed in plain text across the internet. If someone wants to read your emails they certainly don't need your POP3/IMAP login password. But any level of unauthorized access to your database management system's passwords is a potentially serious failure of your system's security.

The password DBMA auto-gen feature is a good way of doing plain text passwords if 'clear text' is your preference because DBMA generates gibberish passwords which look like mush to a sniffer as compared to typical user passwords.

Sending Mail with DBMA

It is a nice touch to send a quick note to a user who has requested a Mailbox quota increase or password change. NET::SMTP is what DBMA uses to send mail to your users. 

Their contact address can be outside your operation (necessary in the case of a password change).  

The NET::SMTP module is part of Graham Barr's libnet. 

The configurable SMTP_ServerName in DBMA should point to your DbMail MTA.

You can send mail to a bare username in your local system if your MTA is configured to pass it to DbMail.

User Names and the MTA Unix-Style versus Alias addresses

This section considers some "best practices" and aims at getting you thinking about "future-proofing" your mail system setup. This may be controversial but as Bob Dylan said, "These times are a'changin'".

Some DbMail users using SQL features of their MTA (i.e.: Postfix) to point their MTA at authorized recipients in the dbmail_aliases table. In Postfix for example, "local_recipient_maps" would look something like this:

 "mysql:/etc/postfix/sql-recipients.cf"

where "sql-recipients.cf" would look something like this:

user = <username>
password = <password>
host = <dbhost>
dbname = <dbname>
table = aliases
select_field = alias
where_field = alias

Would this indicate that the choice of aliases over usernames for a recipient table is because not all aliases actually have an account?

In the "main.cf" notes of the current "official" release of Postfix, this is OK. It will work; but obsolete in the new development branch of Postfix. Spammers have caught on to this flaw and forward looking thinkers are making some changes.

"The local_recipient_maps parameter specifies optional lookup tables with all names or addresses of users that are local with respect to $mydestination, $inet_interfaces or $proxy_interfaces."

In future releases of Postfix, this is not OK.

In the new Postfix configuration notes for the V2.2 developmental branch, " The local_recipient_maps parameter specifies optional lookup tables with all names (not addresses) of users that are local with respect to $mydestination and $inet_interfaces. If this parameter is defined, then the SMTP server will reject mail for unknown local users." 

In fact, try it, it will not work and Postfix will reject all mail.

NOTE: On release of 2.2, this has changed. 

What you see here is "future proofing"

"sql-recipients.cf" Should be, in this instance:

user = <username>
password = <password>
host = <dbhost>
dbname = <dbname>
table = dbmail_users
select_field = userid
where_field = userid

Stay Future Proof and Create Accounts for All Users

This is a decison you may or may not face. The object here is to show you an alternative method of  recipient mapping -- do we have this user? 

The future of MTA's could point to authentication on the basis of first_part user names only. A number of factors prevail, nontheleast of which may be your desire to implement key pair sender-authenticion regime. 

Every user must have their own account. Itcan't be just an alias. 

That is by far, a more extensible approach but initially requires a little more work.

Where you may now be pointing your MTA at the aliases table, you find it necesary to point to the first_part (left of the @) in the users.userid column. What are the ramifications?

It's not that hard. 

If webmaster@ has an alias of web@, an account for web should exist. Web doesn't need to receive mail, but the account must exist. Aliases like info@, sales@ may be directed to a real person name, but when that real person leaves the company, gets promoted or goes on vacation, info@, sales@ need to be redirected to someone else. They can even have encrypted auto-generated passwords which no one knows; their mail being stored only in the mailboxes of real people.

Each of these 'system' accounts would need to have their own user accounts in order to do that correctly and easily. If for example, you needed to know "who's handling info@" unless "info" has its own account, you would theoretically need to search through every single account and GroupID until you found "info@". Well, DBMA provides a tool for accomplishing this quickly, because there are likely many users who do not follow the best practices of creating a user account for all users. 

It's a matter of what works best; or in the future, what will break completely.

 Several RFC's require that mail be accepted for certain accounts. Don't make these orphaned aliases. Create user accounts within their appropriate system account GroupID.

In short, create accounts for all users. If you have info@, sales@, marketing@, then create accounts for them. Have set their alias to real people; something you can quickly change as personnel change.

More about redirecting mail for pseudo accounts to real humans.

The easiest way to do this with DBMA is to create the account with a wacky encrypted password say for "info" WITHOUT an alias. If Harry Smith is responsible for answering queries to "info" open Harry's account and add an alias "[email protected]". All mail for "info" will go to Harry.

The day Harry moves on to bigger and better things and you need to move "info" over to "Bob Jones", open the "info" account and you will see the alias pointed to Harry's userID. Delete that alias. Next, open the account for "Bob Jones" and create "[email protected]" in the "Bob Jones" account. Bob Jones will now get all the "info" mail.

It's easy. It's foolproof.