1

Topic: backupmx setting causes problems on SMTP relay after upgrade to 0.8.6

==== Required information ====
- iRedMail version:
- Store mail accounts in which backend (LDAP/MySQL/PGSQL):
- Linux/BSD distribution name and version:
- Related log if you're reporting an issue:
======== Required information ====
- iRedMail version: 0.8.6
- Store mail accounts in which backend (LDAP/MySQL/PGSQL): MySQL
- Linux/BSD distribution name and version: Debian 7.1
- Related log if you're reporting an issue:
====

Hello Zhang,

some days ago I upgraded the iRedMail version from 0.8.5 to 0.8.6 following your upgrade guide.
Everything worked fine except for one issue:

You tell in your Wiki page that

There's a bug in Postfix MySQL query for domain transport, it doesn't check whether hosted domain is backup mx or not. Please fix it by following below steps.

http://iredmail.org/wiki/index.php?titl … ap_query_2

Historically we have been using the server to relay messages to other email servers.
We had to set "backupmx" in the database manually to 1 to make the relaying work correctly.

Now we have some domains with backupmx set to 1 and which have a relay setting enabled.
After applying the upgrade patch above, the relay does not work anymore - obvious, backupmx is 1 in database.

Now I undid the changes to the postfix file and restarted the service. The messages could now be delivered correctly.

As you have implemented the "Mark as Backup MX" option in iRedAdmin-Pro, it should reflect the actual setting in the database, right?
Unfortunately the checkbox is shown unchecked (with a blue question mark at the right side) even if the backupmx setting is "1" in the record.
It seems the checkbox is disabled and cannot be activated.
Maybe the software checks if a relay server is set and if yes it disables the checkbox?

Well, I have a relay server configured.
If I want to remove it (empty field "Relay/Transport Setting") and click on save, I get following error:

Error: (1064, "You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') WHERE domain='xxxx.de'' at line 1")

Ok, there should be a setting like "dovecot" but please show a warning or default an empty field to "dovecot" smile

When I set "backupmx" to 0 in the database, I get following error:

Recipient address rejected: User unknown in virtual mailbox table

Now I am confused.

- backupmx is required to accept emails, process and forward to a custom smtp server
- the blue question mark on the right side of the checkbox "Mark as backup MX" in iRedAdmin-Pro does tell "Backup MX does not work with custom relay"
- I cannot remove the relay setting but I can change it

What can I do?

Best regards,

Bernhard

----

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

2

Re: backupmx setting causes problems on SMTP relay after upgrade to 0.8.6

broth wrote:

Now we have some domains with backupmx set to 1 and which have a relay setting enabled.
After applying the upgrade patch above, the relay does not work anymore - obvious, backupmx is 1 in database.
Now I undid the changes to the postfix file and restarted the service. The messages could now be delivered correctly.

Oops, looks like this fix is invalid and becomes a new bug.

With 'AND backupmx=0' in file /etc/postfix/mysql/transport_maps_domain.cf, Postfix cannot find a custom transport/relay/route for this backup mx domain, then use default value 'relay' instead. This incorrect transport value causes the issue.

About issue in iRedAdmin-Pro, does it work if you remove 'AND backupmx=0' in file /etc/postfix/mysql/transport_maps_domain.cf? I will try to reproduce this issue right now.

3

Re: backupmx setting causes problems on SMTP relay after upgrade to 0.8.6

ZhangHuangbin wrote:

About issue in iRedAdmin-Pro, does it work if you remove 'AND backupmx=0' in file /etc/postfix/mysql/transport_maps_domain.cf? I will try to reproduce this issue right now.

Yes, this is my current workaround.

About iRedAdmin-Pro:
I just noticed if I replace the "smtp:[1.2.3.4]" with "dovecot" the previously disabled AND unchecked "Mark domain as backup MX" gets active and checked.

Hope this helps.
Thank you!

4

Re: backupmx setting causes problems on SMTP relay after upgrade to 0.8.6

Looks like i have to announce a hotfix for iRedMail-0.8.6, all users who installed with iRedMail-0.8.6 or upgraded from an old version to 0.8.6 have to revert this change in transport_maps_domain.cf.

5

Re: backupmx setting causes problems on SMTP relay after upgrade to 0.8.6

broth wrote:

If I want to remove it (empty field "Relay/Transport Setting") and click on save, I get following error:
Error: (1064, "You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') WHERE domain='xxxx.de'' at line 1")

I can reproduce this issue, it's a bug in iRedAdmin-Pro-MySQL-1.8.1. You can fix it with below steps:

*) Open file libs/mysql/domain.py, find below line (about line 480):

newTransport = settings.default_mta_transport,

*) Remove the ',' at the end of line:

newTransport = settings.default_mta_transport

*) Save your change and restart Apache service.

That's all.

6

Re: backupmx setting causes problems on SMTP relay after upgrade to 0.8.6

ZhangHuangbin wrote:

I can reproduce this issue, it's a bug in iRedAdmin-Pro-MySQL-1.8.1. You can fix it with below steps:

Your patch works, no SQL error anymore.

Please let me know about the rough timeframe for the hotfix (backupmx, disabled checkbox ...). I know the implementation of cluebringer was much work, I really appreciate that it works mostly. Thank you very much for your great software!

7

Re: backupmx setting causes problems on SMTP relay after upgrade to 0.8.6

broth wrote:

Please let me know about the rough timeframe for the hotfix (backupmx, disabled checkbox ...). I know the implementation of cluebringer was much work

There's nothing you should do for the hotfix, you already reverted changes.