1

Topic: Alias table obsolete after upgrade?

==== Required information ====
- iRedMail version (check /etc/iredmail-release): 0.9.7
- Linux/BSD distribution name and version: Ubuntu 16.04
- Store mail accounts in which backend (LDAP/MySQL/PGSQL): MySQL
- Web server (Apache or Nginx): Apache
====

The 0.9.7 upgrade just went fine for me. After migrating user into the new structure, there just a few former aliases left in the vmail.alias table. I guess its because they never had a is_list or is_alias property (those are quite old aliases...). They got migrated to vmail.forwardings table properly but still remain in alias.
Therefore I'm questioning myself: Is or will there be a further use for vmail.alias table or is it obsolete? As far as I understood, everything is now managed via vmail.forwardings table. Is it safe to purge those old entries, if they're present in vmail.forwadings table?

Cheers,
Henrik

----

Spider Email Archiver: On-Premises, lightweight email archiving software developed by iRedMail team. Supports Amazon S3 compatible storage and custom branding.

2

Re: Alias table obsolete after upgrade?

Based on the documentation (http://www.iredmail.org/docs/sql.create.mail.alias.html), the alias table is used for mail alias acccounts. And the list members should have value 1 on column is_list.

3

Re: Alias table obsolete after upgrade?

RikuS wrote:

Based on the documentation (http://www.iredmail.org/docs/sql.create.mail.alias.html), the alias table is used for mail alias acccounts. And the list members should have value 1 on column is_list.

Ok, if this is the case, the the migration script failed to leave a lot aliases in vmail.alias table - It seems like they work anyway. Does anyone know, what tables are used where - it seem to me, the current layout is made for future improvements and the duplication of information in vmail.alias and vmail.forwarding is currently not needed for working aliases?!
I'm trying to figure out, if I urgently need to write a script for writing the missing alias information back to vmail.alias (according to the mentioned doc) or if this can be postponed a few days.

4

Re: Alias table obsolete after upgrade?

One additional Question: what is the difference between is_list and is_alias and why should be, according to documentation is_list, be used for setting up aliases?

5

Re: Alias table obsolete after upgrade?

Here's confirmed queries for aliases and forwardings, hope it helps:
http://www.iredmail.org/forum/post57850.html#p57850

The alias table should only have records for mail alias accounts (mailing lists), nothing else.

6 (edited by RikuS 2017-08-17 03:27:27)

Re: Alias table obsolete after upgrade?

henrikw wrote:

One additional Question: what is the difference between is_list and is_alias and why should be, according to documentation is_list, be used for setting up aliases?

is_list is the mail alias account with possibly multiple recipients and access policy:
http://www.iredmail.org/docs/sql.create.mail.alias.html
So if you want to create an alias address that forwards email to multiple recipients, this is what you need.

is_alias is an alias per mailbox user:
http://www.iredmail.org/docs/user.alias.address.html
If you want to have multiple alias addresses for a mailbox, so incoming mail for all of them comes to same box, this is what you need.

7

Re: Alias table obsolete after upgrade?

Thanks a lot, that is mostly what I was looking for!
Just to clarify once more: is_list is for m:n and is_alias is for n:1 relation?! So if I don't have any m:n relations my vmail.alias table is supposed to be empty?!

8 (edited by RikuS 2017-08-17 04:52:04)

Re: Alias table obsolete after upgrade?

One alias address in alias table can have multiple recipients in forwardings table (with is_list).

One mailbox can have multiple alias addresses in forwadings table (with is_alias).

One mailbox can have multiple forwarding addresses in forwardings table (with is_forwarding).

Also each mailbox has is_forwarding record for itself, to receive mail normally (both address and forwarding cols have same user mailbox address). To prevent receiving mail normally and only forward it, you can change active to 0 or delete the row.

9

Re: Alias table obsolete after upgrade?

RikuS wrote:

One alias address in alias table can have multiple recipients in forwardings table (with is_list).

One mailbox can have multiple alias addresses in forwadings table (with is_alias).

One mailbox can have multiple forwarding addresses in forwardings table (with is_forwarding).

Also each mailbox has is_forwarding record for itself, to receive mail normally (both address and forwarding cols have same user mailbox address). To prevent receiving mail normally and only forward it, you can change active to 0 or delete the row.

Clear so far smile The last thing I tried to figure out with my last question was, if a forwarding with is_alias needs to have an entry in vmail.alias or not!? As I don't have any forwardings that are applicable for is_list=1 my assumption was, that vmail.alias should be empty.
Thanks again!

10 (edited by RikuS 2017-08-17 05:15:00)

Re: Alias table obsolete after upgrade?

Neither is_alias nor is_forwarding needs entries in alias table, so if you don't have any mail aliases (often called mailing lists) with is_list = 1 then alias table should be empty.

11

Re: Alias table obsolete after upgrade?

Mailinglists are managed via Mailman, so it seems good, as it is now.
Thanks for your time and patience!

12

Re: Alias table obsolete after upgrade?

You can find details about this sql structure change in this issue:
https://bitbucket.org/zhb/iredmail/issu … lias-table