Re: issue with sieve forwarding after upgrade to 0.5.1

[Helmut K. C. Tessarek]

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.
*/

Re: issue with sieve forwarding after upgrade to 0.5.1

[B. Reino]

Hello,

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

(if you need help with that ask again.. I'm on the train now so I can't write 
much comfortably..)

Cheers.

On April 3, 2018 10:25:22 PM GMT+02:00, Christos Chatzaras 
 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
>[private/dovecot-lmtp] said: 451 4.2.0
>mailto:ch...@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
>mailto:ch...@mydomain.com>>: Sendmail program
>returned error (temporary failure).
>
>Any idea what is wrong?
>
>Kind regards,
>Christos Chatzaras

Use of separate storage for mail delivery

[SAAHIL IFTEKHAR]

Hi

I am facing one issue which is mostly about concepts. I have to be clear on
that to move forward. I have tried finding solutions about it but couldn't
find anything which talks about it.


We have a setup which includes postfix and dovecot. We are using lmtp and
delivery of mail is happening through dovecot. We want that delivery of
mail should happen in a separate node. I was able to achieve it through
lmtp by providing ip address and using port 24.

But now I have been asked to just try to deliver to a separate storage
medium and not node. That means it will have an ip address but no dovecot
or other software running. This is in relation to incorporation of storage
area network (SAN) later on.

Is it possible? I thought there must be some way as many running mail
systems are using message store and SAN. All i can find that was close was
mailbox sharing and email archiving.

Please help me about this as I have already spent 3 days to it with no
luck. I just want the right direction to move forward on this.


Regards

Re: issue with sieve forwarding after upgrade to 0.5.1

[Stephan Bosch]

Op 4/3/2018 om 10:34 PM schreef Christos Chatzaras:
> Here are some logs:
>
> Apr  3 23:25:35 server1 dovecot: lmtp(ch...@coderz.gr
> )<47735>: program
> `/usr/sbin/sendmail' terminated with non-zero exit code 75
> Apr  3 23:25:35 server1 dovecot: lmtp(ch...@coderz.gr
> )<47735>: Error:
> sieve: msgid= >: failed
> to redirect message to  >: 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 > > 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
>> [private/dovecot-lmtp] said: 451 4.2.0
>> mailto:ch...@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
>> mailto:ch...@mydomain.com>>: Sendmail program
>> returned error (temporary failure).
>>
>> Any idea what is wrong?
>>
>> Kind regards,
>> Christos Chatzaras
>

Re: 2.3.1 Replication is throwing scary errors

[Reuben Farrelly]

Hi,


--

Message: 2
Date: Mon, 2 Apr 2018 22:06:07 +0200
From: Michael Grimm 
To: Dovecot Mailing List 
Subject: 2.3.1 Replication is throwing scary errors
Message-ID: <29998016-d62f-4348-93d1-613b13da9...@ellael.org>
Content-Type: text/plain;   charset=utf-8

Hi

[This is Dovecot 2.3.1 at FreeBSD STABLE-11.1 running in two jails at distinct 
servers.]

I did upgrade from 2.2.35 to 2.3.1 today, and I do become pounded by error 
messages at server1 (and vice versa at server2) as follows:

| Apr  2 17:12:18  server1.lan dovecot: doveadm: Error: 
dsync(server2.lan): I/O has stalled, \
no activity for 600 seconds (last sent=mail_change, last 
recv=mail_change (EOL))
| Apr  2 17:12:18  server1.lan dovecot: doveadm: Error: 
Timeout during state=sync_mails \
(send=changes recv=mail_requests)
[?]
| Apr  2 18:59:03  server1.lan dovecot: doveadm: Error: 
dsync(server2.lan): I/O has stalled, \
no activity for 600 seconds (last sent=mail, last recv=mail 
(EOL))
| Apr  2 18:59:03  server1.lan dovecot: doveadm: Error: 
Timeout during state=sync_mails \
(send=mails recv=recv_last_common)

I cannot see in my personal account any missing replications, *but* I haven't 
tested this thoroughly enough. I do have customers being serviced at these 
productive servers, *thus* I'm back to 2.2.35 until I do understand or have 
learned what is going on.

Any ideas/feedback?

FYI: I haven't seen such errors before. Replication has been working for years 
now, without any glitches at all.

Regards,
Michael


It's not just you.  This issue hit me recently, and it was impacting 
replication noticeably.  I am following git master-2.3 .


Here's a last known reasonably good point in the tree where things 
worked quite well:


EGIT_REPO_URI="https://github.com/dovecot/core.git";
EGIT_BRANCH="master-2.3"
EGIT_COMMIT="d9a1a7cbec19f4c6a47add47688351f8c3a0e372"

So something after that (which could have gone into 2.3.1) has caused this.

There is also a second issue of a long standing race with replication 
occurring somewhere whereby if a mail comes in, is written to disk, is 
replicated and then deleted in short succession, it will reappear again 
to the MUA.  I suspect the mail is being replicated back from the 
remote.  A few people have reported it over the years but it's not 
reliable or consistent, so it has never been fixed.


And lastly there has been an ongoing but seemingly minor issue relating 
to locking timing out after 30s particularly on the remote host that is 
being replicated to.  I rarely see the problem on my local disk where 
almost all of the mail comes in, it's almost always occurring on the 
replicate/remote system.
For me it seems very unlikely that on an unloaded/idle VPS there are 
legitimate problems obtaining a lock in under 30s.  This is with the 
default locking configuration.  This problem started happening a lot 
more after the breakage in (1) above.


These replication issues are similar, and could possibly be related.

My system is Gentoo Linux keeping up with the latest kernels, and on an 
EXT4 FS.  I am using TCPS based replication.  My remote replicate is 
also on Gentoo Linux with EXT4 but on a Linode VPS (around 250ms latency 
away).


I know in a later post you've said that you don't think it has anything 
to do with dovecot-2.3.1, so I'd be interested to know what really is 
the cause in that case.


Reuben

Re: issue with sieve forwarding after upgrade to 0.5.1

[Christos Chatzaras]

Here are some logs:

Apr  3 23:25:35 server1 dovecot: 
lmtp(ch...@coderz.gr)<47735>: program 
`/usr/sbin/sendmail' terminated with non-zero exit code 75
Apr  3 23:25:35 server1 dovecot: 
lmtp(ch...@coderz.gr)<47735>: Error: sieve: 
msgid=: failed to redirect 
message to : 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.




> On 3 Apr 2018, at 23:25, Christos Chatzaras  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 
> [private/dovecot-lmtp] said: 451 4.2.0 
> mailto:ch...@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  >: Sendmail program returned error (temporary 
> failure).
> 
> Any idea what is wrong?
> 
> Kind regards,
> Christos Chatzaras

issue with sieve forwarding after upgrade to 0.5.1

[Christos Chatzaras]

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 [private/dovecot-lmtp] 
said: 451 4.2.0 mailto:ch...@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 mailto:ch...@mydomain.com>>: Sendmail program returned error (temporary 
failure).

Any idea what is wrong?

Kind regards,
Christos Chatzaras

Re: 2.3.1 Replication is throwing scary errors

[Michael Grimm]

Michael Grimm  wrote:

> [This is Dovecot 2.3.1 at FreeBSD STABLE-11.1 running in two jails at 
> distinct servers.]
> 
> I did upgrade from 2.2.35 to 2.3.1 today, and I do become pounded by error 
> messages at server1 (and vice versa at server2) as follows:
> 
>   | Apr  2 17:12:18  server1.lan dovecot: doveadm: Error: 
> dsync(server2.lan): I/O has stalled, \
>   no activity for 600 seconds (last sent=mail_change, last 
> recv=mail_change (EOL))
>   | Apr  2 17:12:18  server1.lan dovecot: doveadm: Error: 
> Timeout during state=sync_mails \
>   (send=changes recv=mail_requests)
[snip]
> FYI: I haven't seen such errors before. Replication has been working for 
> years now, without any glitches at all.

That statement of mine has been incorrect:

#) I did investigate a bit further, and I do see those errors at about 20 days 
spread over the last year. 
#) And what puzzles me even more is the fact that only server2 reports those 
errors, not a single line in server1's log files.
#) All those error messages above are paralleled by messages like:

   Apr  2 17:10:49  server2.lan dovecot: doveadm: Error: Couldn't 
lock /home/to/USER1/.dovecot-sync.lock: \
   fcntl(/home/to/USER1/.dovecot-sync.lock, write-lock, F_SETLKW) locking 
failed: Timed out after 30 seconds \
   (WRITE lock held by pid 51110)

#) I did upgrade both servers to 2.3.1 a couple of hours ago, and haven't seen 
a single error, yet.

I do have to admit that I do not understand what is going on at server2, and I 
am quite sure it has nothing to do with dovecot.
Sorry for the noise. 
It has nothing to do with dovecot 2.3.1

Regards,
Michael

Re: dovecot auth error: Illegal seek

[panetta]

Thanks Aki for the answer.

I did some tests and found a solution. I write down my experience It 
could be useful to someone.


First I putted  "passwd-file" passdb (only)  before "pam" passdb, as Aki 
suggested,

but "illegal seek error" persisted.

Then I putted both "passwd-file" passdb and "static" userdb before "pam" 
passdb and "passwd" userdb (used for local user),
but that generated a strange behavior because "static" driver overrides 
info also for local user.


Finally I putted both "passwd-file" passdb and "passwd-file" userdb 
before "pam" and "passwd"

and that works without errors.

My working dovecot config:

host-prompt# dovecot -n
# 2.1.7: /etc/dovecot/dovecot.conf
# OS: Linux 3.2.0-5-686-pae i686 Debian 7.11
auth_mechanisms = plain login
auth_username_format = %Ln
listen = *
log_timestamp = "%Y-%m-%d %H:%M:%S "
login_greeting = Server ready.
mail_full_filesystem_access = yes
mail_location = mbox:~/:INBOX=/var/mail/%u:INDEX=/var/index/%u
mail_privileged_group = mail
passdb {
  args = scheme=MD5-CRYPT username_format=%n /etc/dovecot/users
  driver = passwd-file
}
passdb {
  driver = pam
}
protocols = " imap"
service auth {
  unix_listener /var/spool/postfix/private/auth {
    group = postfix
    mode = 0660
    user = postfix
  }
  user = root
}
service imap-login {
  inet_listener imap {
    port = 0
  }
}
ssl_cert = to avoid writing uid,gid,home for each user, but in the end, with 
passwd-file and

override_fields i got the desired scenario.

Regards,
Claudio


Il 30/03/18 14:27, Aki Tuomi ha scritto:

On 30 March 2018 at 15:11 panetta  wrote:


Hi,

I recently configured dovecot to manage auth
for both local and virtual user.
When i login as a virtual user (claudio.panetta) I get the following
message:

dovecot: auth: Error:
passwd(claudio.panetta,160.97.62.1,): getpwnam()
failed: Illegal seek

but login is ok and sending/receiving email is ok,
how can, if possible, I suppress this error message?

In the following my dovecot config:

host-prompt# dovecot -n
# 2.1.7: /etc/dovecot/dovecot.conf
# OS: Linux 3.2.0-5-686-pae i686 Debian 7.11
auth_mechanisms = plain login
auth_username_format = %Ln
listen = *
log_timestamp = "%Y-%m-%d %H:%M:%S "
login_greeting = Server ready.
mail_full_filesystem_access = yes
mail_location = mbox:~/:INBOX=/var/mail/%u:INDEX=/var/index/%u
mail_privileged_group = mail
passdb {
    driver = pam
}
passdb {
    args = scheme=MD5-CRYPT username_format=%n /etc/dovecot/users
    driver = passwd-file
}
protocols = " imap"
service auth {
    unix_listener /var/spool/postfix/private/auth {
      group = postfix
      mode = 0660
      user = postfix
    }
    user = root
}
service imap-login {
    inet_listener imap {
      port = 0
    }
}
ssl_cert = 
Hi! Put the file based passdb before the pam one. Also not sure what you are 
trying to do with the static userdb. It looks like you wanted to use 
passwd-file?

Aki