• Our team is looking to connect with folks who use email services provided by Plesk, or a premium service. If you'd like to be part of the discovery process and share your experiences, we invite you to complete this short screening survey. If your responses match the persona we are looking for, you'll receive a link to schedule a call at your convenience. We look forward to hearing from you!
  • The BIND DNS server has already been deprecated and removed from Plesk for Windows.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS. We strongly recommend transitioning to Microsoft DNS within the next 6 weeks, before the Plesk 18.0.70 release.
  • The Horde component is removed from Plesk Installer. We recommend switching to another webmail software supported in Plesk.

Forwarded to devs Duplicate and zombie entries in email forwarding list when a mailbox is renamed to the same name like an existing forwarding entry

Bitpalast

Plesk addicted!
Plesk Guru
Username: Peter Debik

TITLE

Duplicate and zombie entries in email forwarding list when a mailbox is renamed to the same name like an existing forwarding entry

PRODUCT, VERSION, OPERATING SYSTEM, ARCHITECTURE

CentOS 7.9, latest MU

PROBLEM DESCRIPTION

An email address a1@test.xx has forwarding configured to at least two addresses, e.g. a2@test.xx, a3@text.xx

An email address a3@test.xx exists in Plesk.

That email address a3@test.xx is renamed to a2@test.xx.

Plesk updates the visible part of the email forwarding list of a1@test.xx to show only a2@test.xx. It looks as if a3@test.xx has been removed from the forwarding list, because that address was renamed and the forwarding list shall not contain duplicates.

However, while the list does not display the renamed address as a duplicate, in the background it obviously has at least one empty zombie entry somewhere. Because when you send an email to a1@test.xx, that email is now forwarded to the remaining a2@test.xx plus to a non-existent email address (which is normally either rejected or forwarded to the catchall address).

STEPS TO REPRODUCE

1. Create an email address a1@text.xx that has or has not a mailbox, but that does have a forwarding to at least two addresses or more, e.g. a2@test.xx, a3@test.xx.

2. Create an email mailbox address a3@test.xx.

3. Rename the mailbox a3@test.xx to a2@test.xx.

4. Open the forwarding list of a1@test.xx and see that this only shows the a2@text.xx entry (the a3@test.xx entry has been properly removed, because that mailbox was renamed, so that no duplicates are shown in the forwarding list).

5. Send an email to a1@test.xx.

ACTUAL RESULT

The mail to a1@test.xx will be forwarded to the remaining address a2@test.xx and to an undefined email address, which normally results in a a forward to the catchall mail address.

EXPECTED RESULT

The mail to a1@test.xx should only be forwarded to the addresses that are visible in the forwarding list, e.g. "a2@test.xx" in this example.

ANY ADDITIONAL INFORMATION

The solution for us was to remove the renamed entry from the forwarding list, then to re-add that entry. This seems to have removed the invisible additional zombie entry in the background. In the example above we'd have to remove a2@test.xx, save the forwarding configuration, then re-add a2@test.xx. Afterwards, forwarding was working as expected again.

YOUR EXPECTATIONS FROM PLESK SERVICE TEAM

Confirm bug
 
Peter, here is the developer's response:

I was able to reproduce the issue and I have reported a cosmetic bug PPPM-13175.

As you can see here it says "1 more" but in the forwarding tab only 1 email address is shown:

Screenshot 2021-08-25 at 12.05.52.png

Also duplicate items can be seen in the mail_redir table:

select * from mail_redir\G;
*************************** 1. row ***************************
id: 6
mn_id: 26
address: a2@example.com
*************************** 2. row ***************************
id: 7
mn_id: 26
address: a2@example.com
2 rows in set (0.000 sec)

In regards to emails being sent and I did not find any issues. The email was forwarded to a2@ and no mention of undefined mailbox is found in maillog:

[root@ppu18-0-multi ~]# grep CA6BE374427C /var/log/maillog
Aug 25 16:46:15 ppu18-0-multi postfix/smtpd[26098]: CA6BE374427C: client=localhost[::1], sasl_method=PLAIN, sasl_username=test@admin1.ppu18-0-multi.demo.pp.plesk.ru
Aug 25 16:46:15 ppu18-0-multi psa-pc-remote[20690]: CA6BE374427C: from=<test@admin1.ppu18-0-multi.demo.pp.plesk.ru> to=<a1@admin3.ppu18-0-multi.demo.pp.plesk.ru>
Aug 25 16:46:15 ppu18-0-multi postfix/cleanup[26105]: CA6BE374427C: message-id=<2bc2dff7d89985ab0322d3a681d06d3e@admin1.ppu18-0-multi.demo.pp.plesk.ru>
Aug 25 16:46:15 ppu18-0-multi psa-pc-remote[20690]: CA6BE374427C: spf: stderr: PASS
Aug 25 16:46:15 ppu18-0-multi psa-pc-remote[20690]: CA6BE374427C: check-quota: stderr: SKIP
Aug 25 16:46:16 ppu18-0-multi postfix/qmgr[23908]: CA6BE374427C: from=<test@admin1.ppu18-0-multi.demo.pp.plesk.ru>, size=718, nrcpt=1 (queue active)
Aug 25 16:46:16 ppu18-0-multi postfix-local[26112]: CA6BE374427C: from=<test@admin1.ppu18-0-multi.demo.pp.plesk.ru>, to=<a1@admin3.ppu18-0-multi.demo.pp.plesk.ru>, dirname=/var/qmail/mailnames
Aug 25 16:46:16 ppu18-0-multi postfix-local[26112]: CA6BE374427C: spam: stderr: PASS
Aug 25 16:46:16 ppu18-0-multi dk_check[26116]: CA6BE374427C: DKIM Feed: No signature
Aug 25 16:46:16 ppu18-0-multi postfix-local[26112]: CA6BE374427C: dk_check: stderr: PASS
Aug 25 16:46:16 ppu18-0-multi postfix-local[26112]: CA6BE374427C: dmarc: stderr: PASS
Aug 25 16:46:16 ppu18-0-multi postfix-local[26112]: CA6BE374427C: send message: id=S26112 from=<SRS0=iotA=NQ=admin1.ppu18-0-multi.demo.pp.plesk.ru=test@admin3.ppu18-0-multi.demo.pp.plesk.ru> to=<a2@admin3.ppu18-0-multi.demo.pp.plesk.ru>
Aug 25 16:46:16 ppu18-0-multi postfix/pipe[26110]: CA6BE374427C: to=<a1@admin3.ppu18-0-multi.demo.pp.plesk.ru>, relay=plesk_virtual, delay=0.49, delays=0.2/0.01/0/0.28, dsn=2.0.0, status=sent (delivered via plesk_virtual service)
Aug 25 16:46:16 ppu18-0-multi postfix/qmgr[23908]: CA6BE374427C: removed
 
O.k., but there has got to be this issue with the forwarding, too, because only because a customer reported what he did I went into the customer's account and did see the additional catch-all forward in the maillog, too. Anyway, let's start with the cosmetic bug, maybe developers will find the other one automatically when they fix the display.
 
Back
Top