It’s the normal behavior of systemd-socket activation. Whenever the script is launched a log line is dropped
Maybe a line should be added in /etc/rsyslog.d/ignore-systemd-*.conf to ignore those useless messages.
Also is it normal that it launches so often and so many times ?
A better approach could be configuring proxymap, to reduce the number of re-connections.
See the “mysql” example.
@pagaille: please edit
/etc/postfix/main.cf and replace
systemctl restart postfix. And see what happens
To rollback my change:
Hi Dennis, do you have new elements? Does the issue arise from SOGo only? What about other mail clients? And what happens if the message comes from another external MTA?
The mail transport Postfix accepts messages through different channels:
- port 25 for MTAs
- port 587 for MUAs like Thunderbird
- localhost 10587 for web applications, like SOGo
- local CLI submission, with a
We have to understand if the issue is specific to one of them or not.
will report back tomorrow.
hi @davidep I’ll try my best to answer.
I’m not sure what you mean by new elements. The issue happens in in SOGo, and Roundcube installed on Nethserver. I have not tried other external clients yet but I will try to join one with EAS, and one IMAP today and retest, and also redirect from my existing MTA to Nethserver.
There is no external mailing coming in yet as this is not exposed beyond my firewall until I can see everything working.
I typically configure all my email clients to use 587
MTA’s inside the network use 25
I’ll try some more tests today and report back. Thanks
I just attempted to send from Tbird connecting to Nethserver using SMTP (465).
the 10.xx.xx.x address is the UCS server, so it looks like NS is attempting to deliver the mail to the UCS server instead of locally
The same message
This is the mail system at host sparky.sgvfr.com. I'm sorry to have to inform you that your message could not be delivered to one or more recipients. It's attached below. For further assistance, please send mail to postmaster. If you do so, please include this problem report. You can delete your own text from the attached returned message. The mail system <SGVFR-INSTRUCTORS@sgvfr.lan> (expanded from <email@example.com>): host sgvfr.lan[10.xx.xx.x] said: 550 5.1.1 <SGVFR-INSTRUCTORS@sgvfr.lan>: Recipient address rejected: User unknown in virtual mailbox table (in reply to RCPT TO command) Reporting-MTA: dns; sparky.sgvfr.com X-Postfix-Queue-ID: 67D7830044F42 X-Postfix-Sender: rfc822; firstname.lastname@example.org Arrival-Date: Tue, 19 Mar 2019 10:21:15 -0700 (PDT) Final-Recipient: rfc822; SGVFR-INSTRUCTORS@sgvfr.lan Original-Recipient: rfc822;email@example.com Action: failed Status: 5.1.1 Remote-MTA: dns; sgvfr.lan Diagnostic-Code: smtp; 550 5.1.1 <SGVFR-INSTRUCTORS@sgvfr.lan>: Recipient address rejected: User unknown in virtual mailbox table test.eml Subject: test From: Dennis <firstname.lastname@example.org> Date: 3/19/2019, 10:21 To: email@example.com test on Tbird using IMAP to firstname.lastname@example.org
Sending from Tbird too SGVFR-MEMBERS@sgvfr.com (this address works on CLI)
I really hope I have misconfigured something and you can suggest I try something different.
[root@sparky html]# db accounts show email@example.com firstname.lastname@example.org=pseudonym Access=public Account=SGVFR-INSTRUCTORS@sgvfr.lan Description=ALL-SGVFR-INSTRUCTORS [root@sparky html]# [root@sparky html]# db accounts show email@example.com firstname.lastname@example.org=pseudonym Access=public Account=SGVFR-MEMBERS@sgvfr.lan Description=ALL-SGVFR-MEMBERS [root@sparky html]# the groups on the UCS server contain the email address's of the members.
Any thoughts or suggestions on what I can try??
The messages totally disapeared. But the setup wasn’t working anymore
Mar 20 09:04:23 cloud postfix/proxymap: warning: 127.0.0.1:14444 is unavailable. unsupported dictionary type: 127.0.0.1 │ Mar 20 09:04:23 cloud postfix/cleanup: warning: proxy:127.0.0.1:14444 lookup error for "email@example.com" │ Mar 20 09:04:23 cloud postfix/cleanup: warning: 8F1DE340EBF: virtual_alias_maps map lookup problem for firstname.lastname@example.org -- deferring delivery
As we tested it from the CLI, I have to see if I can reproduce it!
This is wrong: the table specification should be something like
proxy:tcp:127.0.0.1:14444, or I misunderstand the manual
Testing again, works right now.
Same behaviour :
Mar 20 17:44:00 cloud systemd: Started postfix-get-group server service (127.0.0.1:50538). Mar 20 17:48:02 cloud systemd: Started postfix-get-group server service (127.0.0.1:50572). Mar 20 17:48:03 cloud systemd: Started postfix-get-group server service (127.0.0.1:50574). Mar 20 17:54:06 cloud systemd: Started postfix-get-group server service (127.0.0.1:50582). Mar 20 17:54:06 cloud systemd: Started postfix-get-group server service (127.0.0.1:50584). Mar 20 18:01:17 cloud systemd: Started postfix-get-group server service (127.0.0.1:50652). Mar 20 18:01:17 cloud systemd: Started postfix-get-group server service (127.0.0.1:50654). Mar 20 18:09:31 cloud systemd: Started postfix-get-group server service (127.0.0.1:50698). Mar 20 18:09:31 cloud systemd: Started postfix-get-group server service (127.0.0.1:50700). Mar 20 18:13:17 cloud systemd: Started postfix-get-group server service (127.0.0.1:50714). Mar 20 18:19:52 cloud systemd: Started postfix-get-group server service (127.0.0.1:50760). Mar 20 18:19:52 cloud systemd: Started postfix-get-group server service (127.0.0.1:50762). Mar 20 18:26:56 cloud systemd: Started postfix-get-group server service (127.0.0.1:50790). Mar 20 18:58:13 cloud systemd: Started postfix-get-group server service (127.0.0.1:50928). Mar 20 18:58:13 cloud systemd: Started postfix-get-group server service (127.0.0.1:50930). Mar 20 18:59:46 cloud systemd: Started postfix-get-group server service (127.0.0.1:50938). Mar 20 19:22:51 cloud systemd: Started postfix-get-group server service (127.0.0.1:51008). Mar 20 19:22:51 cloud systemd: Started postfix-get-group server service (127.0.0.1:51010).
@amygos and I ran some tests with
proxy: prefix, adding it to the template code in
/etc/e-smith/templates/etc/postfix/main.cf/20virtual_domains and it seems to produce less log lines under stress conditions. A patch is coming for it!
I tried to reproduce, but the only issue I found is with “domain admins” group, which contains a space thus is not handled correctly. @Amygos is fixing the code.
Do you have a different installation to test?
I don’t, but I can create one easily enough.
Thanks for checking, perhaps it is just an issue with mine.
The last package released in
nethserver-testing contains the support for groups name with space (eg. “domain admins”) and the fix for reduce the lines in the logfile.
@pagaille, can you verify if the last package resolve your problem?
Yes I’ll report back.
Take care : it’s possible to create a group that has the same name as an existing user. Obviously it breaks things, the user cannot receive mails anymore. That case should be handled.
I have a question. What are the possible interactions between group names, aliases names and shared mailboxes names ?
Here is an example. I configured a shared mailbox ‘email@example.com’ that can be accessed by users belonging to the group ‘firstname.lastname@example.org’ (same name). I see potential problems especially with the ‘create alias’ checkbox in the shared mailbox configuration page. Don’t you ?
The general rule is: Defined aliases have higher priority over user and group names.
Check out the new cockpit Mail app to see how this feature integrates with existing objects!
Yep that’s what I’m discovering
Do you mean that we can test it ? Or do you refer to the screenshots ?
You can install it from the testing repository. As such, I suggest to prepare a testing environment!
Sure. Txs, can’t wait !