Op 4/3/2018 om 10:34 PM schreef Christos Chatzaras:

Here are some logs:

Apr  3 23:25:35 server1 dovecot: lmtp(chris@coderz.gr <mailto:chris@coderz.gr>)<47735><AUI6Aj/jw1p3ugAAPz4RRA>: program `/usr/sbin/sendmail' terminated with non-zero exit code 75 Apr  3 23:25:35 server1 dovecot: lmtp(chris@coderz.gr <mailto:chris@coderz.gr>)<47735><AUI6Aj/jw1p3ugAAPz4RRA>: Error: sieve: msgid=<DE90EB45-9B58-4679-9BCE-E2698773519E@cretaforce.gr <mailto:DE90EB45-9B58-4679-9BCE-E2698773519E@cretaforce.gr>>: failed to redirect message to <chris@cretaforce.gr <mailto:chris@cretaforce.gr>>: Sendmail program returned error (temporary failure)

In my postfix main.cf I have this:

authorized_submit_users = root, filter

When I change it to:

authorized_submit_users = root, filter, myUserName

where myUserName is the username that owns the mailbox it works.

So I guess that something changed to dovecot between 2.2.35 and 2.3.1 and is not related to pigeonhole.

Yeah, this is likely due to the fact that sendmail is now invoked using the program-client (same as Sieve extprograms), which takes great care to drop any unwanted (seteuid) root privileges.

Regards,

Stephan.

...

On 3 Apr 2018, at 23:25, Christos Chatzaras <chris@cretaforce.gr <mailto:chris@cretaforce.gr>> wrote:

Hello,

After I upgrade dovecot 2.2.35 to 2.3.1 and pigeonhole 0.4.23  to 0.5.1 when I use sieve to forward a message to other address using "redirect :copy" I get this:

(host server1.myserver.com <http://server1.myserver.com/>[private/dovecot-lmtp] said: 451 4.2.0 <chris@mydomain.com <mailto:chris@mydomain.com>> Execution of Sieve filters was aborted due to temporary failure (in reply to end of DATA command))

And in sieve log I see: failed to redirect message to <chris@mydomain.com <mailto:chris@mydomain.com>>: Sendmail program returned error (temporary failure).

Any idea what is wrong?

Kind regards, Christos Chatzaras

On 2018-04-04 01:54, B. Reino wrote:

The new systemd service file has NoNewPrivileges set to true. You need to override that to false and then it should work again.

It seems that the NoNewPrivileges option messes with several things. PAM authentication stopped working as well besides the fact that CAP_AUDIT_WRITE is also missing in CapabilityBoundingSet.

I've opened a pull request https://github.com/dovecot/core/pull/71 Although I removed NoNewPrivileges altogether, since I didn't know what to write in the comment.

The only thing I could think of was something along the lines:

# If you want most things to stop working, set this to true

I thought this would be rather counterproductive, thus I removed it.

Maybe somebody else could enlighten me who came up with this default setting and why it was set to true in the first place.

Cheers, K. C.

-- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944

/* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */

On 2018-04-04 03:09, Aki Tuomi wrote:

We are thinking that we remove both this and CapabilityBoundingSet in next release, so feel free to remove them from the unit file.

Thanks for the info.

Cheers, K. C.

-- regards Helmut K. C. Tessarek KeyID 0x172380A011EF4944 Key fingerprint = 8A55 70C1 BD85 D34E ADBC 386C 1723 80A0 11EF 4944

/* Thou shalt not follow the NULL pointer for chaos and madness await thee at its end. */

On 2018-04-04 11:02, Christos Chatzaras wrote:

Thank you for your reply. I use FreeBSD so no changes on the OS before and after the dovecot/pigeonhole updates.

Oops. I guess I assume everyone uses Linux (and Debian at that.. :)

I don't know how dovecot is set-up with FreeBSD. The error you showed was similar (or the same, I don't know anymore) to the one I had when I upgraded to 2.3.1 on Debian, the root cause of which was the new restriction disallowing dovecot to get new privileges (which meant it could not run postdrop as root, despite being setuid).

.. but for FreeBSD, I'll have to pass.. :)

Good luck!