Sending an email to LDAP/AD group - Mail Alias is not a solution

It’s the normal behavior of systemd-socket activation. Whenever the script is launched a log line is dropped :roll_eyes:

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 tcp:127.0.0.1:14444 with proxy:tcp:127.0.0.1:14444. Then systemctl restart postfix. And see what happens :smile:

To rollback my change: signal-event nethserver-mail-server-update

2 Likes

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 sendmail-like command

We have to understand if the issue is specific to one of them or not.

1 Like

:wink: 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

@davidep

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 <instructors@sgvfr.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; dlloyd@sgvfr.com
Arrival-Date: Tue, 19 Mar 2019 10:21:15 -0700 (PDT)

Final-Recipient: rfc822; SGVFR-INSTRUCTORS@sgvfr.lan
Original-Recipient: rfc822;instructors@sgvfr.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 <dlloyd@sgvfr.com>
Date: 
3/19/2019, 10:21
To: 
instructors@sgvfr.com

test on Tbird using IMAP to instructors@sgvfr.com

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 instructors@sgvfr.com
instructors@sgvfr.com=pseudonym
    Access=public
    Account=SGVFR-INSTRUCTORS@sgvfr.lan
    Description=ALL-SGVFR-INSTRUCTORS
[root@sparky html]#

[root@sparky html]# db accounts show members@sgvfr.com
members@sgvfr.com=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??

Thanks!

The messages totally disapeared. But the setup wasn’t working anymore :scream::scream:

Mar 20 09:04:23 cloud postfix/proxymap[14184]: warning: 127.0.0.1:14444 is unavailable. unsupported dictionary type: 127.0.0.1                                                                   │
Mar 20 09:04:23 cloud postfix/cleanup[14189]: warning: proxy:127.0.0.1:14444 lookup error for "somealiastarget@gmail.com"                                                                                                                                   │
Mar 20 09:04:23 cloud postfix/cleanup[14189]: warning: 8F1DE340EBF: virtual_alias_maps map lookup problem for user/alias@mydomain.tld -- 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 :thinking:

MY BAD :hot_face::hot_face::hot_face::hot_face:

Testing again, works right now.

1 Like

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).

1 Like

@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?

1 Like

I don’t, but I can create one easily enough.

Thanks for checking, perhaps it is just an issue with mine.

2 Likes

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?

2 Likes

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 ‘com@domain.tld’ that can be accessed by users belonging to the group ‘com@domain.tld’ (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 :wink:

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 ! :slight_smile:

2 Likes