1

Our Mailsystem includes a Postfix, openLDAP and Cyrus. All run smoothly till last week. When I created a new Mailbox for a user who before had only an Alias with an forwarding external Mailadress. To this new Mailbox the Emails aren't delivered. Sending is ok.

First I thought about some caching problem, but it persists.

The Mails stuck in the Mailqueue of Postfix. In the logs I found this difference regarding a Mail which gets delivered and one to this user:

root@server:/# grep 80D41241356 /var/log/mail.log
Apr 25 11:39:11 server postfix/smtpd[12439]: 80D41241356: client=kes.domain.de[IP]
Apr 25 11:39:11 server postfix/cleanup[12442]: 80D41241356: message-id=<3808909c-c8fa-7d93-b2e4-a225ffa7a48b@domain.de>
Apr 25 11:39:11 server postfix/qmgr[12406]: 80D41241356: from=admin@domain.de, size=997, nrcpt=1 (queue active)
Apr 25 11:39:11 server postfix/pipe[12445]: 80D41241356: to=admin@domain.de, orig_to=admin@domain.de, relay=cyrus, delay=0.1, delays=0/0.02/0/0.08, dsn=2.0.0, status=sent (delivered via cyrus service)
Apr 25 11:39:11 server postfix/qmgr[12406]: 80D41241356: removed

this Mail remains in the Queue:

root@server:/# grep 706AB240FC4 /var/log/mail.log
Apr 25 11:38:45 server postfix/smtpd[12439]: 706AB240FC4: client=kes.domain.de[IP]
Apr 25 11:38:45 server postfix/cleanup[12442]: 706AB240FC4: message-id=ff5eecc9-73a3-e605-1567-21c9814f3f4b@domain.de
Apr 25 11:38:45 server postfix/qmgr[12406]: 706AB240FC4: from=, size=1006, nrcpt=1 (queue active)

I switched on the debuglevel and get:

Apr 29 11:30:36 server postfix/local[15680]: deliver_dotforward[3]: set user_attr: mvogt
Apr 29 11:30:36 server postfix/local[15680]: set_eugid: euid 3146 egid 2017

then it hangs in the queue. Thie following Mail is sent to another user, which has almost the same permissions and it is delivered in the cyrus Mailbox correctly. Here is the Logfile extract.

Apr 29 11:28:57 server postfix/local[15680]: deliver_dotforward[3]: set user_attr: atest
Apr 29 11:28:57 server postfix/local[15680]: set_eugid: euid 3005 egid 2017
Apr 29 11:28:57 server postfix/local[15680]: set_eugid: euid 110 egid 116
Apr 29 11:28:57 server postfix/local[15680]: deliver_dotforward: path /home/atest/.forward expand_status 0 look_status -1
Apr 29 11:28:57 server postfix/local[15680]: deliver_mailbox[3]: local atest recip atest@server.domain.de exten deliver atest@server.domain.de exp_from

I would be very happy if anyone can give me a hint what means set_eugid in this context. Looking in /etc/groups and /etc/passwd

postfix:x:116:

postfix:x:110:116:

maybe this is also the totally wrong conclusion and there is something else missing. If there is important information missing I can add them, just dont want to put all the configurations, because the Server is working ok.

Thanks in advance!

Sylvia Gelman
  • 11
  • 3
  • How was the forwarding done previously? Has that been undone? How did you go from queue ID 80D41241356 to 706AB240FC4? – wurtel Apr 29 '19 at 14:49
  • The Queue IDs are two different Mails, one went through for a user with the same permissions in the filesystem to compare the logs – Sylvia Gelman Apr 29 '19 at 15:27
  • The forwarding was done with ldapdirectory entry in aliases. This worked fine before. Yes it is undone. – Sylvia Gelman Apr 29 '19 at 15:28
  • @wurtel Any Idea how I could debug better? Which logs I could use additionally to putting -v in /etc/postfix/master.cf #grep " -v" /etc/postfix/master.cf pickup unix n - - 60 1 pickup -v qmgr unix n - n 300 1 qmgr -vv local unix - n n - - local -vv lmtp unix - - - - - lmtp -vv cyrus unix - n n - - pipe -vv – Sylvia Gelman Apr 30 '19 at 12:48
  • Sorry, no. My expertise lies with exim. I am wondering about "706AB240FC4: from=," that the from= is empty; with a null sender that should at least be "from=<>". The "set_eugid" is postfix switching effective UID and GID to first the user's ID (to read his .forward file) and then back again. – wurtel Apr 30 '19 at 13:47
  • arrgh, no the from is not empty, was dealing a lot with the quote format here, it swallowed all between <>, will correct that. Thanks anyway! – Sylvia Gelman Apr 30 '19 at 15:08

0 Answers0