Univention Bugzilla – Bug 56482
Creating remote mail retrieval configuration (single drop and multi drop) via UMC doesn't check for primary email-address
Last modified: 2024-01-09 09:08:26 CET
Although a user has no primary email-address configured, it is possible to create a Remote mail retrieval (Single drop) configuration for that user. This results in the following error in the listener.log: 24.08.23 12:44:58.437 LISTENER ( PROCESS ) : ox-connector: modify of uid=testuser99,cn=users,dc=musterfirma1,dc=intranet (id: b'ec474c78-d6b6-103d-8bc3-2bee4944f44c', file: /var/lib/univention-appcenter/listener//ox-connector/2023-08-24-12-44-58-436398.json) Traceback (most recent call last): File "/usr/lib/univention-directory-listener/system/fetchmailrc.py", line 226, in handler objappend_single(flist, new, oldatt_passwd) File "/usr/lib/univention-directory-listener/system/fetchmailrc.py", line 166, in objappend_single mail_address = new['mailPrimaryAddress'][0].decode('UTF-8') KeyError: 'mailPrimaryAddress' 24.08.23 12:44:58.440 LISTENER ( WARN ) : handler: fetchmailrc (failed) Restarting fetchmail (via systemctl): fetchmail.service. The configuration file /etc/fetchmailrc is kept untouched, but the service fetchmail will be restarted. Something similar happens by creating a Remote mail retrieval (Multi drop) configuration. The resulting error looks like this: 24.08.23 12:56:18.137 LDAP ( PROCESS ) : connecting to ldap://mf1primary.musterfirma1.intranet:7389 24.08.23 12:56:18.184 LISTENER ( PROCESS ) : updating 'uid=testuser99,cn=users,dc=musterfirma1,dc=intranet' command m 24.08.23 12:56:18.187 LDAP ( PROCESS ) : connecting to ldap://localhost:7389 24.08.23 12:56:18.212 LISTENER ( WARN ) : replication: Can't contact LDAP server: retrying 24.08.23 12:56:18.212 LISTENER ( WARN ) : additional info: Broken pipe 24.08.23 12:56:18.282 LISTENER ( PROCESS ) : ox-connector: modify of uid=testuser99,cn=users,dc=musterfirma1,dc=intranet (id: b'ec474c78-d6b6-103d-8bc3-2bee4944f44c', file: /var/lib/univention-appcenter/listener//ox-connector/2023-08-24-12-56-18-281177.json) Traceback (most recent call last): File "/usr/lib/univention-directory-listener/system/fetchmailrc.py", line 226, in handler objappend_single(flist, new, oldatt_passwd) File "/usr/lib/univention-directory-listener/system/fetchmailrc.py", line 166, in objappend_single mail_address = new['mailPrimaryAddress'][0].decode('UTF-8') KeyError: 'mailPrimaryAddress' 24.08.23 12:56:18.284 LISTENER ( WARN ) : handler: fetchmailrc (failed) Restarting fetchmail (via systemctl): fetchmail.service. All this was tested with (same levels as customer): UCS: 5.0-4 errata771 Installed: fetchmail=6.3.26 mailserver=12.0 ox-connector=2.2.4 oxseforucs=7.10.6-ucs9 Upgradable:
Correction regarding multi-drop: In my tests the single-drop still has existed. The creation of a multi drop config creates an entry in fetchmailrc and there is no traceback in the listener.log.
Changes: - Check that the user has a mailPrimaryAddress in fetchmailrc.py listener. Commits: univention-fetchmail (13.0.7-1) 417f5763d957 | Bug #56482: Changelog univention-fetchmail (13.0.6-5) fb54255f66dc | Bug #56482: Check that user has mailPrimaryAddress on Fetchmail listener New version: Package: univention-fetchmail Version: 13.0.7-1 Branch: ucs_5.0-0 Scope: ucs5.0-5
- Check that the user has a mailPrimaryAddress in fetchmailrc.py listener. Reopen: - objappend_single() calls objappend(), which tries to access mailPrimaryAddress. Only after that, the new check_attributes() function is called. This will still lead to a traceback. - What is the expected expected behavior with this fix? What should happen, if for example the mailPrimaryAddress is removed from a user? Right now, the listener will just exit. Should the fetchmailrc be updated and the entry about that user / users mailbox be removed?
Changes: - Changes in the fetchmail user detection in fetchmailrc.py listener that allows the update of the fetchmailrc file with the correct changes. - Avoid traceback when configuring a fetchmail user without a mailPrimaryAddress Commits: univention-fetchmail.yaml c45a0bd79d31 | Bug #56482 Check that user has mailPrimaryAddress in Fetchmail listener univention-fetchmail (13.0.7-3) c45a0bd79d31 | Bug #56482 Check that user has mailPrimaryAddress in Fetchmail listener New version: Package: univention-fetchmail Version: 13.0.7-3 Branch: ucs_5.0-0 Scope: ucs5.0-5
QA: - The fetchmail listener module checks whether `mailPrimaryAddress` is set before it tries to add a configuration for the corresponding user to the fetchmailrc: OK - A warning gets logged in case the fetchmail listener tries to add a configuration to the fetchmailrc for a user that does not have a `mailPrimaryAddress`: OK - Advisories: OK
<https://errata.software-univention.de/#/?erratum=5.0x888>
I have received feedback from the customer about this bug. Here is the feedback: If the mailPrimaryAddress of a user is not available, this is now logged in the listener.log. I would find it more helpful if the users were at least shown a message. At the moment, however, users may not even notice if there is a fetchmail-single-drop configuration but no mailPrimaryAddress, which may result in emails not being delivered. The behavior of the OX App Suite for fetchmail would be more extensive than a hint, because a user can only be activated for the OX App Suite if a mailPrimaryAddress exists. If a user does not have a mailPrimaryAddress, a corresponding message appears and the user object is not saved. Here is the error in the bug solution: For the creation of fetchmail-multi-drop configurations, no mailPrimaryAddress is required, because yes, with multi-drop the recipient email address comes on the envelope header. Nevertheless, a newly created and valid fetchmail-multi-drop configuration is not entered in /etc/fetchmailrc, but the same error "Adding user to "fetchmailrc" failed. Missing mailPrimaryAddress attribute in user" is logged in the listener.log. This is an error and should be corrected. Should i create a separate bug for that?
(In reply to Mirac Erdemiroglu from comment #7) > Should i create a separate bug for that? Yes, create a new bug. In general, we will not work on CLOSED bugs, if an artifact was already build and shipped for it.