T+1 Year with PostfixAdmin...
Almost a year after talking about this project...I'm finally posting about it.

Been working on a new schema for postfix, I'll say that I did learn a few things about database design from someone before they left (or where asked to leave or were fired...whatever). I found that the current postfix admin schema is horribly incomplete. Sure it's a step up from using flat file configs, but it doesn't scale much further from it. The initial design we proposed was a multi-home domain with sub-domains defining user location on the multi-homed scope. Although very flexible, some serious custom work had to go into making the postfix admin schema work with this layout. Mix in some MySQL Master/Slaves, and the added complexity makes things interesting.

From what we found, the postfix admin schema is designed for a single homed server or cluster to only look at the data one way. We immediately blew that up once we added a second server taking an alternate look at the data. The quick solution was to add unique identifier to each domain row to give it a "home" locale.

"Great now the servers know how to differentiate between hosts in their home locale", we all thought.

Although this was technically true, the servers could then differentiate between locations it added duplicate data into the domain tables. Making PostfixAdmin interface completely unusable for domain management. Additionally, user management then became near impossible. The work flow was thus:

1. Log-in to the parent server hosting the maildir and create the maildir
2. Log-in to PostfixAdmin and create the mail user account on a child domain
3. Create an alias in PostfixAdmin from the parent alias domain to the child domain user account
4. Do anything extra like add to mailing lists etc...
   

...And then do that for every new account you need to create. Sure you can batch up the creation process for the existing users that you're porting over from whatever mail system you already have, but for new users it's sorta a pain in the ass. And don't even get me started on access control or transaction tracking for any of that.

The idea of PostfixAdmin is a nice one. Centralize the configs for a server somewhere that all the servers can reach (say in the same location as the mail server cluster). But anything outside of that scope and the tower comes crumbling down. Change a domain name somewhere and you have to update most of an entire table. Scaling...not such a high point.

Some solutions to the problem that I cobbled together are Perl and Bash scripts to help automate some of the process of user and maildir creation. But there in lies the problem. Some admins aren't so versed in *nix and require a fluffy hand holding interface. With the primary interface a little borked from the addition of the locales, I started work on a new schema that would allow better scaling, real transaction accounting, granular message ACLs (Getting a crap load of mail to only one locale or domain and not another? *bzzzz* Done; Don't like getting email from x92mS212-s.com? Great! Have the user add a rule to permanently block that email from their box and after a threshold from everyone else's too).

With the new schema complete, and +80% of stored functions and procedures in the can, I'll be able to start working on the new UI soon and deploying the transaction tracking triggers to all the dependent tables.