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

Hello @Amygos

I’m having an issue now, I thought I had this working before but after clearing out alias’s and trying again only 2 of the 16 test emails actually delivered.


[root@sparky vmail]# db accounts set members@ pseudonym Access public Account SGVFR-MEMBERS@sgvfr.lan Description ALL-SGVFR-MEMBERS
[root@sparky vmail]# db accounts set instructors@ pseudonym Access public Account SGVFR-INSTRUCTORS@sgvfr.lan Description ALL-SGVFR-INSTRUCTORS
[root@sparky vmail]# signal-event nethserver-mail-server-update
[root@sparky vmail]# sss_cache --groups

(unsure if I have to execute sss_cache or not)

[root@sparky test]# db accounts show instructors@
instructors@=pseudonym
    Access=public
    Account=SGVFR-INSTRUCTORS@sgvfr.lan
    Description=ALL-SGVFR-INSTRUCTORS
[root@sparky test]# db accounts show members@
members@=pseudonym
    Access=public
    Account=SGVFR-MEMBERS@sgvfr.lan
    Description=ALL-SGVFR-MEMBERS
[root@sparky test]#
[root@sparky vmail]# mail -s "Test 1 instructors@sgvfr.lan - CLI" instructors@sgvfr.lan < instructors-body
[root@sparky vmail]# mail -s "Test 2 instructors@sgvfr.com - CLI" instructors@sgvfr.com < instructors-body
[root@sparky vmail]# mail -s "Test 3 SGVFR-INSTRUCTORS@sgvfr.lan - CLI" SGVFR-INSTRUCTORS@sgvfr.lan < instructors-body
[root@sparky vmail]# mail -s "Test 4 SGVFR-INSTRUCTORS@sgvfr.com - CLI" SGVFR-INSTRUCTORS@sgvfr.com < instructors-body
[root@sparky vmail]# mail -s "Test 5 members@sgvfr.lan - CLI" members@sgvfr.lan < members-body
[root@sparky vmail]# mail -s "Test 6 members@sgvfr.com - CLI" members@sgvfr.com < members-body
[root@sparky vmail]# mail -s "Test 7 SGVFR-MEMBERS@sgvfr.lan - CLI" SGVFR-MEMBERS@sgvfr.lan < members-body
[root@sparky vmail]# mail -s "Test 8 SGVFR-MEMBERS@sgvfr.com - CLI" SGVFR-MEMBERS@sgvfr.com < members-body

from the CLI, test 4 and test 8 are delivered.

which I expected, partially…

I expected tests 3 and 7 to be delivered as it matched the alias creation…

I tried every variation because trying the same address’ in SOGo, or RoundCube fail on every attempt.

Soooo… I recreated the alias

[root@sparky test]# db accounts set members@sgvfr.com pseudonym Access public Account SGVFR-MEMBERS@sgvfr.lan Description ALL-SGVFR-MEMBERS
[root@sparky test]# db accounts set instructors@sgvfr.com pseudonym Access public Account SGVFR-INSTRUCTORS@sgvfr.lan Description ALL-SGVFR-INSTRUCTORS
[root@sparky test]# signal-event nethserver-mail-server-update
[root@sparky test]# sss_cache --groups

again, only tests 4 and 8 were delivered from the CLI, none were delivered when sending from SOGo or RoundCube

would it be safe to assume there is still more coding to do and currently only mail from the CLI will work? Or, is the more likely answer me not understanding something?

Thanks!

It could be necessary only if group members change

Can you attach (gist, pastebin) relevant maillog lines about success and failure?

What are you thinking about? Please make an example!

Consider that the existing configuration cannot be altered and running systems must have zero impact from this change!

Currently for most of my groups I configured an alias (same name as the group) containing each and every member of the group (error prone solution). I guess that’s how most sysadmins did it until now.

The upgrade should probably delete or warn about those aliases that correspond to an existing group. And it should be possible to mail to the Groups that were configured before the upgrade.

1 Like

@davidep

here is a snip of the logs for one successful from CLI, and the same address failing from SOGo.

if you need more, please let me know and I can private message you a link to the entire raw logs

WORKING from CLI

Mar 15 09:35:29 sparky postfix/pickup[4770]: 3BFBF30044F49: uid=0 from=<root>
Mar 15 09:35:29 sparky postfix/cleanup[7964]: 3BFBF30044F49: message-id=<20190315163529.3BFBF30044F49@sparky.sgvfr.com>
Mar 15 09:35:29 sparky opendkim[9465]: 3BFBF30044F49: no signing table match for 'root@sparky.sgvfr.com'
Mar 15 09:35:29 sparky postfix/qmgr[9586]: 3BFBF30044F49: from=<root@sparky.sgvfr.com>, size=551, nrcpt=2 (queue active)
Mar 15 09:35:29 sparky dovecot: lmtp(7975): Connect from local
Mar 15 09:35:29 sparky dovecot: lmtp(user2@sgvfr.com): WFmJH1HUi1wnHwAAK71Kiw: sieve: msgid=<20190315163529.3BFBF30044F49@sparky.sgvfr.com>: stored mail into mailbox 'INBOX'
Mar 15 09:35:29 sparky postfix/lmtp[7974]: 3BFBF30044F49: to=<user2@sgvfr.com>, orig_to=<SGVFR-INSTRUCTORS@sgvfr.com>, relay=sparky.sgvfr.com[/var/run/dovecot/lmtp], delay=0.73, delays=0.37/0.04/0.03/0.29, dsn=2.0.0, status=sent (250 2.0.0 <user2@sgvfr.com> WFmJH1HUi1wnHwAAK71Kiw Saved)
Mar 15 09:35:29 sparky dovecot: lmtp(user1@sgvfr.com): WFmJH1HUi1wnHwAAK71Kiw:2: sieve: msgid=<20190315163529.3BFBF30044F49@sparky.sgvfr.com>: stored mail into mailbox 'INBOX'
Mar 15 09:35:29 sparky dovecot: lmtp(7975): Disconnect from local: Successful quit
Mar 15 09:35:29 sparky postfix/lmtp[7974]: 3BFBF30044F49: to=<user1@sgvfr.com>, orig_to=<SGVFR-INSTRUCTORS@sgvfr.com>, relay=sparky.sgvfr.com[/var/run/dovecot/lmtp], delay=0.83, delays=0.37/0.04/0.03/0.38, dsn=2.0.0, status=sent (250 2.0.0 <user1@sgvfr.com> WFmJH1HUi1wnHwAAK71Kiw:2 Saved)
Mar 15 09:35:29 sparky postfix/qmgr[9586]: 3BFBF30044F49: removed
Mar 15 09:35:43 sparky rspamd[25743]: <c5dycn>; lua; neural.lua:808: check ANN tRFANNB58D781EF264551260
Mar 15 09:35:43 sparky rspamd[25743]: <c5dycn>; lua; neural.lua:820: no need to learn ANN tRFANNB58D781EF264551260 0 learn vectors (1000 required)


FAILED from SOGo

Mar 15 09:39:22 sparky postfix/smtpd[8419]: connect from localhost[127.0.0.1]
Mar 15 09:39:22 sparky rspamd[25742]: <dabdb4>; proxy; proxy_accept_socket: accepted milter connection from /var/run/rspamd/worker-proxy port 0
Mar 15 09:39:22 sparky postfix/smtpd[8419]: NOQUEUE: reject: RCPT from localhost[127.0.0.1]: 550 5.1.1 <SGVFR-INSTRUCTORS@sgvfr.com>: Recipient address rejected: User unknown in virtual mailbox table; from=<user1@sgvfr.com> to=<SGVFR-INSTRUCTORS@sgvfr.com> proto=ESMTP helo=<localhost>
Mar 15 09:39:22 sparky postfix/smtpd[8419]: disconnect from localhost[127.0.0.1]
Mar 15 09:39:22 sparky rspamd[25742]: <dabdb4>; milter; rspamd_milter_process_command: got connection from 127.0.0.1:37730
Mar 15 09:39:22 sparky rspamd[25742]: <dabdb4>; proxy; proxy_milter_finish_handler: finished milter connection
2 Likes

@davidep I see multiple occurrences of those messages in the logs :

Mar 19 08:23:39 cloud systemd: **Started postfix-get-group** server service (127.0.0.1:40556).
Mar 19 08:23:39 cloud systemd: **Started postfix-get-group** server service (127.0.0.1:40558).
Mar 19 08:34:57 cloud systemd: **Started postfix-get-group** server service (127.0.0.1:40594).
Mar 19 08:34:57 cloud systemd: **Started postfix-get-group** server service (127.0.0.1:40596).
Mar 19 08:40:06 cloud systemd: **Started postfix-get-group** server service (127.0.0.1:40604).
Mar 19 08:58:45 cloud systemd: **Started postfix-get-group** server service (127.0.0.1:40642).
Mar 19 09:06:2 cloud systemd: **Started postfix-get-group** server service (127.0.0.1:40658).
Mar 19 09:10:42 cloud systemd: **Started postfix-get-group** server service (127.0.0.1:40678).
Mar 19 09:10:42 cloud systemd: **Started postfix-get-group** server service (127.0.0.1:40680).
Mar 19 09:18:03 cloud systemd: **Started postfix-get-group** server service (127.0.0.1:40846).
Mar 19 09:18:03 cloud systemd: **Started postfix-get-group** server service (127.0.0.1:40848).
Mar 19 09:21:32 cloud systemd: **Started postfix-get-group** server service (127.0.0.1:40866).
Mar 19 09:24:38 cloud systemd: **Started postfix-get-group** server service (127.0.0.1:40888).
Mar 19 09:24:38 cloud systemd: **Started postfix-get-group** server service (127.0.0.1:40890).
Mar 19 09:27:48 cloud systemd: **Started postfix-get-group** server service (127.0.0.1:40898).
Mar 19 09:30:27 cloud systemd: **Started postfix-get-group** server service (127.0.0.1:40982).
Mar 19 09:30:27 cloud systemd: **Started postfix-get-group** server service (127.0.0.1:40984).
Mar 19 09:33:00 cloud systemd: **Started postfix-get-group** server service (127.0.0.1:41004).
Mar 19 09:33:00 cloud systemd: **Started postfix-get-group** server service (127.0.0.1:41006).
Mar 19 09:56:52 cloud systemd: **Started postfix-get-group** server service (127.0.0.1:41216).
Mar 19 09:56:52 cloud systemd: **Started postfix-get-group** server service (127.0.0.1:41218).
Mar 19 09:59:16 cloud systemd: **Started postfix-get-group** server service (127.0.0.1:41270).
Mar 19 10:07:57 cloud systemd: **Started postfix-get-group** server service (127.0.0.1:41484).
Mar 19 10:07:57 cloud systemd: **Started postfix-get-group** server service (127.0.0.1:41486).
Mar 19 10:13:44 cloud systemd: **Started postfix-get-group** server service (127.0.0.1:41580).
Mar 19 10:13:44 cloud systemd: **Started postfix-get-group** server service (127.0.0.1:41582).
Mar 19 10:14:02 cloud systemd: **Started postfix-get-group** server service (127.0.0.1:41584).
Mar 19 10:14:02 cloud systemd: **Started postfix-get-group** server service (127.0.0.1:41586).
Mar 19 10:20:02 cloud systemd: **Started postfix-get-group** server service (127.0.0.1:41730).
Mar 19 10:20:02 cloud systemd: **Started postfix-get-group** server service (127.0.0.1:41732).
Mar 19 10:24:06 cloud systemd: **Started postfix-get-group** server service (127.0.0.1:41806).
Mar 19 10:24:06 cloud systemd: **Started postfix-get-group** server service (127.0.0.1:41808).

I guess it’s something related to this case ?

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.