Thanks for your prompt reply.

Your LDAP script is useful. I will try to adapt it to automatically migrate all the existing accounts onto LDAP.

Regarding the forwards, I've just noticed that the LDAP mailUser object class has a mailForwardingAddress attribute. Would it not be possible to use that?
Right now I'm more concerned in making sure that the existing forward settings can be carried over to the new server and continue working as expected, even without having the webmail interface to change it.

I've also found this forward tab patch: http://www.roundcubeforum.net/plug-ins/ … d-tab.html
Seems like the old server that I am migrating from is using an adaptation of this patch that works with its vhcs2 setup.
I could try to adapt it to change the mailForwardingAddress attribute on LDAP.

Either way, the roundcubemail upgrade tutorial will be a welcome addition.

On the old server it is stored in a MySQL table but I apparently VHCS2 only uses it to update postfix's alias file.
I will be working on a script that reads the table and creates the right data on the new LDAP setup.

For your reference the VHCS2 table structure is as follows:

mysql> describe mail_users;
+-------------------+------------------+------+-----+---------+----------------+
| Field             | Type             | Null | Key | Default | Extra          |
+-------------------+------------------+------+-----+---------+----------------+
| mail_id           | int(10) unsigned | NO   | PRI | NULL    | auto_increment |
| mail_acc          | varchar(200)     | YES  |     | NULL    |                |
| mail_pass         | varchar(150)     | YES  |     | NULL    |                |
| mail_forward      | text             | YES  |     | NULL    |                |
| domain_id         | int(10) unsigned | YES  |     | NULL    |                |
| mail_type         | varchar(20)      | YES  |     | NULL    |                |
| sub_id            | int(10) unsigned | YES  |     | NULL    |                |
| status            | varchar(255)     | YES  |     | NULL    |                |
| mail_auto_respond | text             | YES  |     | NULL    |                |
+-------------------+------------------+------+-----+---------+----------------+

The passwords are surprisingly stored as clear text!

A mail forwarding user

+---------+------------+-----------+----------------+-----------+----------------+--------+--------+-------------------+
| mail_id | mail_acc   | mail_pass | mail_forward   | domain_id | mail_type      | sub_id | status | mail_auto_respond |
+---------+------------+-----------+----------------+-----------+----------------+--------+--------+-------------------+
|    1111 | test_user1 | clearTXT  | ext@email.dom  |         2 | normal_forward |      0 | ok     | _no_              |
+---------+------------+-----------+----------------+-----------+----------------+--------+--------+-------------------+

and a normal non-forwarding user

+---------+------------+-----------+----------------+-----------+----------------+--------+--------+-------------------+
| mail_id | mail_acc   | mail_pass | mail_forward   | domain_id | mail_type      | sub_id | status | mail_auto_respond |
+---------+------------+-----------+----------------+-----------+----------------+--------+--------+-------------------+
|    2222 | test_user2 | clearTXT  | _no_           |         2 | normal_mail    |      0 | ok     | _no_              |
+---------+------------+-----------+----------------+-----------+----------------+--------+--------+-------------------+

Which simply results in the following entries in /etc/postfix/vhcs2/aliases

test_user1@mydomain.dom  ext@email.dom
test_user2@mydomain.dom  test_user2@mydomain.dom

I will now test if adding a mailForwardingAddress attribute to a user on LDAP does the job.

Update: I am happy to report that it works

Thanks for the tip, I have now applied the latest schema and managed to create a few mailAlias aliases.

However, please note that in order to make it work I had to create a new file:
/etc/postfix/ldap_virtual_aliases_maps.cf
which is an exact copy of the existing /etc/postfix/ldap_virtual_alias_maps.cf
but I changed the following line:

query_filter  = (&(mail=%s)(objectClass=mailAlias)(accountStatus=active)(enabledService=mail)(enabledService=forward))

Naturally, in /etc/postfix/main.cf I now have:

virtual_alias_maps = ldap:/etc/postfix/ldap_virtual_alias_maps.cf, ldap:/etc/postfix/ldap_virtual_aliases_maps.cf

I'm not sure if this is the best way to do it (i.e. the need for a separate file, or the enableService=forward bit), but now it works great.

I tried that combined query but it broke my mailUser forwarding. I guess because in my case users with forwarding only have the mailForwardingAddress but not the enabledService=forward. Until I get/build an easy to use maintenance app it is easier to just add/remove the mailForwardingAddress without worrying about setting another attribute.

I now use:

query_filter    = (&(mail=%s)(accountStatus=active)(enabledService=mail)(|(objectClass=mailUser)(objectClass=mailAlias)))

and it seems to work fine with the single ldap_virtual_alias_maps.cf, both for mailUsers with mailForwardingAddress set, and for mailAliases.

Hopefully this will solve a problem that I have noticed recently: an alias 'AliasA' which contains a large number of addresses, including other aliases (i.e. 'AliasB' and 'AliasC') was causing the following errors:

Undelivered Mail Returned to Sender

<AliasB>: user unknown
<AliasC>: user unknown

even though those alias do exist. I am hoping this was caused by the slow LDAP query due to the poor performance of querying the directory twice. It's already quite a big directory and kind of sluggish (with 1600+ mailUser and mailAlias entries) so every little performance boost helps.

And forgot to say: everything in iRedMail -current is unstable, not recommend used in product server, include the ldap schema file (i improved it several days ago)

Although there is still some tweaking of configuration required, plus some customisation, I'm happy with the current setup based on iRedMail's installation script. Soon I think I'll call it a success story.

Again Zhang, thanks for your work on this project.

My original question regarding LDAP management and forward option still stands. I think I'm am going to implement this myself. However I would like to ask for your opinions on implementation options.

I'm a Java developer, and very keen on my language of choice, but I think using Java just for postfix/LDAP management on the sever is a little overkill.

I'm happy to learn Python and/or PHP in order to develop something more suitable for this setup.0

What I need to implement is:

* web-based virtual domain/user/alias management tool that works with the LDAP backend, but that hides all the LDAP specific complexities (phpLDAPadmin is not a solution for us)
* web-based (or perhaps networked client-side app) management tool for postfix queue management (we need something that will be able to replace another server, which is running the Windows based MDaemon Email Server).
* forwarding tab on roundcube (already discussed, and perhaps no need to develop this if new version of roundcube ships with it)

Any tips/suggestions on how to approach these tasks is welcome.

That's looking very good and useful. I see it is written in Python, which is a good choice. Will it work with the LDAP backend as well?

I will need to look at the codebase, you see, even though we're starting with your current stable LDAP schema, we need to eventually customise it to accomodate more information such as user full name, user ID number, windows domain info, etc. Our goal is to create a single sign-on system using the current LDAP as a starting point. So I will also need to customise the admin webapp to accomodate those changes.

It would be nice if it can be designed to allow for easy customisation, so that any future version updates can be applied with mininum effort.

Yes, but ideally we'll use a GUI for queue management. Perhaps this will be difficult to implement, but I will give it a try.

I agree.