Re: Authentication segfault with Dovecot 2.3.13
It would appear that nodelay causes the crash here. We are tracking this bug as
DOV-4280 internally.
Aki
> On 07/01/2021 01:05 Josef 'Jeff' Sipek wrote:
>
>
> On Wed, Jan 06, 2021 at 14:07:06 -0500, Josef 'Jeff' Sipek wrote:
> > Ok, just a quick update. I managed to reproduce it. I'll try to figure out
> > where things went wrong.
>
> Two more questions:
>
> (1) Why are you using a UNION in your SQL statement?
>
> (2) Does the crash still happen if you remove the nodelay parts of the SQL
> statements?
>
> Thanks,
>
> Jeff.
>
> >
> > Thanks,
> >
> > Jeff.
> >
> > On Wed, Jan 06, 2021 at 18:22:03 +0100, Harald Leithner wrote:
> > > Hi
> > >
> > > Am 06.01.2021 um 18:08 schrieb Josef 'Jeff' Sipek:
> > > > On Wed, Jan 06, 2021 at 17:13:05 +0100, Harald Leithner wrote:
> > > >> Hi,
> > > >>
> > > >
> > > >
> > > >> and the user part with "user@redacted".
> > > >
> > > > I assume you did this for additional privacy, and not because you think
> > > > that
> > > > auth_debug_passwords=no should hide usernames as well.
> > >
> > > yes
> > >
> > > >
> > > >> The user uses APOP for authentication, but other users login
> > > >> successfully with APOP.
> > > >
> > > > Do you only use APOP? Or are other authentication schemes affected as
> > > > well?
> > >
> > > No
> > >
> > > >
> > > > Can you share your config? (`doveconf -n` will be a good start, any
> > > > .ext
> > > > files may be useful as well)
> > >
> > > yes here is the dovecot -n
> > >
> > > [root@mail:~]$ doveconf -n
> > > # 2.3.13 (89f716dc2): /etc/dovecot/dovecot.conf
> > > # OS: Linux 5.9.16-100.fc32.x86_64 x86_64 Generic release 32 (Generic)
> > > # Hostname:
> > > auth_cache_negative_ttl = 10 secs
> > > auth_cache_size = 64 k
> > > auth_cache_ttl = 30 secs
> > > auth_mechanisms = CRAM-MD5 DIGEST-MD5 APOP LOGIN PLAIN
> > > auth_username_chars =
> > > abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@%
> > > auth_username_translation =
> > > %@AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuVvWwXxYyZz
> > > auth_worker_max_count = 150
> > > disable_plaintext_auth = no
> > > imap_capability = IMAP4 IMAP4rev1 ACL RIGHTS=texk NAMESPACE CHILDREN
> > > SORT QUOTA THREAD=ORDEREDSUBJECT UNSELECT IDLE
> > > login_greeting =
> > > login_log_format_elements = user=<%u> %r %m %c %k
> > > mail_max_userip_connections = 100
> > > passdb {
> > >args = /etc/dovecot/sql.conf
> > >driver = sql
> > > }
> > > protocols = imap pop3
> > > service anvil {
> > >unix_listener anvil-auth-penalty {
> > > mode = 00
> > >}
> > > }
> > > service auth {
> > >unix_listener /var/spool/postfix/private/auth {
> > > group = postfix
> > > mode = 0660
> > > user = postfix
> > >}
> > > }
> > > service imap-login {
> > >client_limit = 300
> > >inet_listener imap {
> > > address = xx.xx.xx.xx
> > > port = 143
> > >}
> > >inet_listener imaps {
> > > address = xx.xx.xx.xx
> > > port = 993
> > >}
> > >process_limit = 15
> > >process_min_avail = 1
> > >service_count = 0
> > >vsz_limit = 512 M
> > > }
> > > service pop3-login {
> > >client_limit = 300
> > >inet_listener pop3 {
> > > address = xx.xx.xx.xx
> > > port = 110
> > >}
> > >inet_listener pop3s {
> > > address = xx.xx.xx.xx
> > > port = 995
> > >}
> > >process_limit = 15
> > >process_min_avail = 1
> > >service_count = 0
> > >vsz_limit = 512 M
> > > }
> > > service stats {
> > >client_limit = 1
> > > }
> > > shutdown_clients = no
> > > ssl_alt_cert = > > ssl_alt_key = # hidden, use -P to show it
> > > ssl_cert = > > ssl_cipher_list =
> > > ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA
> > > ssl_dh = # hidden, use -P to show it
> > > ssl_key = # hidden, use -P to show it
> > > ssl_options = no_compression
> > > ssl_prefer_server_ciphers = yes
> > > userdb {
> > >args = static uid=5000 gid=5000 home=/dev/null
> > >driver = static
> > > }
> > > version_ignore = yes
> > > [root@mail:~]$
> > >
> > >
> > > >
> > > > Thanks,
> > > >
> > > > Jeff.
> > >
> > > thx
> > >
> > > Harald
> > >
> > > >
> > > >> Here is a stacktrace and a log dump:
> > > >>
> > > >> Jan 6 16:29:44 mail kernel: auth[2208397]: segfault at ec ip
> > > >> 7f67fc147174 sp 7ffeed993150 error 4 in
> > > >> libdovecot.so.0.0.0[7f67fc06e000+fc000]
> > > >> Jan 6 16:29:44 mail kernel: Code: 1f 80 00 00 00 00 41 54 e8 79 fd ff
> > > >> ff 31 f6 49 89 c4 48 89 c7 31 c0 e8 ca f8 ff ff 4c 89 e0 41 5c c3 0f 1f
> > > >> 40 00 53 48 89 fb 87 ec 00 00 00 04 75 43 48 83 3d 7b aa 0a 00 00
> > > >> 0f 85 50 15 f4
> > > >> Jan 6
Re: test-file-cache.c needs #ifdef HAVE_RLIMIT_AS
Can you try adding this to the file? #define RLIMIT_AS RLIMIT_DATA Aki > On 06/01/2021 22:47 Rupert Gallagher wrote: > > > OpenBSD > > > Original Message > On Jan 6, 2021, 21:37, Aki Tuomi < aki.tu...@open-xchange.com> wrote: > > Which distro/OS is this? > Aki
Re: problem building on centos 8 (8.3 kernel)
> On 07/01/2021 03:57 st...@keptprivate.com wrote:
>
>
> Hi,
>
> I'm converting from qmailtoaster/vpopmail build.
> When I try to build dovecot-2.3.13-2.src.rpm for centos 8.3 the first thing I
> run into is this:
>
> + sed -i 's|/etc/ssl|/etc/pki/dovecot|' doc/mkcert.sh
> doc/example-config/conf.d/10-ssl.conf
> + '[' -e buildinfo.commit ']'
> ++ head -1 buildinfo.commit
> + COMMIT=89f716dc2ec7362864a368d32533184b55fb7831
> ++ /bin/sh /home/build/rpmbuild/SOURCES/lsb_release -is
> /bin/sh: /home/build/rpmbuild/SOURCES/lsb_release: No such file or directory
> + ID=
> error: Bad exit status from /var/tmp/rpm-tmp.WFaLYQ (%build)
>
>
> RPM build errors:
> Macro expanded in comment on line 455: %{_libdir}/dovecot/settings
>
> Bad exit status from /var/tmp/rpm-tmp.WFaLYQ (%build)
>
> I can get past this with an edit to the dovecot.spec file (removing
> sourcedir):
>
> if [ -e "buildinfo.commit" ]; then
>COMMIT=`head -1 buildinfo.commit`
>ID=`/bin/sh
> %{_sourcedir}/lsb_release
> -is`
>RELEASE=`/bin/sh
> %{_sourcedir}/lsb_release
> -rs`
>CODENAME=`/bin/sh
> %{_sourcedir}/lsb_release
> -cs`
>ARCH=`arch`
> fi
>
> The RPM builds but it fails to run with this message in the logs:
>
> Jan 6 20:52:11 beta1 systemd[1]: Starting Dovecot IMAP/POP3 email server...
> Jan 6 20:52:11 beta1 systemd[1]: Started Dovecot IMAP/POP3 email server.
> Jan 6 20:52:11 beta1 dovecot[356909]: /usr/sbin/dovecot: error while loading
> shared libraries: libdovecot.so.0: cannot open shared object
> file: No such file or directory
> Jan 6 20:52:11 beta1 systemd[1]: dovecot.service: Main process exited,
> code=exited, status=127/n/a
> Jan 6 20:52:11 beta1 systemd[1]: dovecot.service: Failed with result
> 'exit-code'.
>
> Any ideas what I have going wrong?
>
> Also, a side question, when I build the rpm it's not running the extensive
> tests that the old qmailtoaster source rpm used to run. I've
> looked through the spec file and I don't really see where to turn that back
> on.
>
> Sorry if any of this is stupid, but I'm new to building directly from the
> dovecot repo.
>
> Steve
I think the file is installed under /usr/lib64/, so check
ldd /usr/lib64/libdovecot.so.0
Is there some reason you are building the rpms yourself?
Aki
Re: systemd-homed
> On 07/01/2021 02:47 Yilin Wei wrote: > > > Hi, > > I’ve been looking into a problem with a local dovecot setup with > ~systemd-homed~ and uses PAM authentication. To give a brief overview, > ~systemd-homed~ mounts the users home directory upon particular > authencation calls (which is configurable through ~/etc/pam.d~). > > Dovecot currently supports PAM authentication perfectly fine — the > problem comes when a system has systemd-homed. This is because the > session is created and deleted immediately afterwards [1]. > > This is a problem because if the server isn’t busy, systemd-homed can > run it’s cleanup which causes the home directory to be unavailable once > again [2]. > > To support this properly, ideally the whole of the imap/pop3/lda session needs > to happen before the deletion of the session. > > Does the imap session happen within a ~verify_plain~ [3] call? If not, > are there any other authentication backends which currently need to keep > a live token? > > Yilin > > [1] > https://github.com/dovecot/core/blob/266e54b7b8c34c9a58dd60a2e53c5ca7d1deae19/src/auth/passdb-pam.c#L219 > [2] https://dovecot.org/pipermail/dovecot/2019-April/115559.html > [3] > https://github.com/dovecot/core/blob/266e54b7b8c34c9a58dd60a2e53c5ca7d1deae19/src/auth/passdb.h#L44 Hi! IMAP session happens after authentication has taken place. For this to work correctly in this case, there would need to be a mail plugin that would actually open the pam session and then close it. Aki
Re: multiple mailstores
> On 07/01/2021 01:51 Alexander Rivanykov wrote: > > > Hi, > > I need to merge mail data from two companies to one - i could attach the > second storage via NFS which has the sdbox mailbox format while the other one > is maildir. > Is it possible to have two mail locations with different mailbox formats > (maildir and sdbox) on one dovecot instance? > > Regardless of whether this is possible or not - what is the procedure to > switch from maildir to sdbox? > > I've actually as mail_location set: > mail_location = maildir:/srv/vmail/%d/%n/maildir > > And for the shared namespace: > location = > maildir:/srv/vmail/%%d/%%n/maildir:INDEX=~/maildir/shared/%%u:CONTROL=~/maildir/shared/%%u > > How would they look like for sdbox? > > mail_location most likely: > mail_location = sdbox:/srv/vmail/%d/%n/sdbox > > But how would the location look like for the shared namespace? > > thx, > Alex You can have per-user mailstore format. sdbox shared location looks like location = sdbox:/srv/vmail/%%d/%%n/sdbox:INDEXPVT=~/sdbox/shared/%%u Aki
Re: Dovecot + sis problem
Ok, thanks.
But :)
What is strange for me is disk usage.
du -s -h /var/mail/attachments/8b/67/
16M /var/mail/attachments/8b/67/
check indes
ls -i /var/mail/attachments/8b/67/
662975
8b67b29a73b74ecf48e17e789051602cec13aa78cc01c06c8eee1ca4be7c8e07f700cdc9e9ca0381fa3541bdd4e26289de1d7eee763233dfaa0a200a264e5258-28571b018ff2f45f0c70035f3f08
662974
8b67b29a73b74ecf48e17e789051602cec13aa78cc01c06c8eee1ca4be7c8e07f700cdc9e9ca0381fa3541bdd4e26289de1d7eee763233dfaa0a200a264e5258-50315d3a8ef2f45f0a70035f3f08
662973
8b67b29a73b74ecf48e17e789051602cec13aa78cc01c06c8eee1ca4be7c8e07f700cdc9e9ca0381fa3541bdd4e26289de1d7eee763233dfaa0a200a264e5258-586cdb378ef2f45f0770035f3f08
ls -i /var/mail/attachments/8b/67/hashes/
662974
8b67b29a73b74ecf48e17e789051602cec13aa78cc01c06c8eee1ca4be7c8e07f700cdc9e9ca0381fa3541bdd4e26289de1d7eee763233dfaa0a200a264e5258
Is this correct?
As I read about hard link - links should point to the same inode, each link.
So how to get real disk usage for the folder with attachments?
śr., 6 sty 2021 o 10:43 Patrick Cernko napisał(a):
> Hi Michal,
>
> On 06.01.21 00:18, Michał Kiljański wrote:
> > Hi,
> > My setup is:
> > mail_attachment_dir = /var/mail/attachments
> > mail_attachment_hash = %{sha512}
> > mail_attachment_min_size = 64k
> > mail_attachment_fs = sis posix
> >
> > Something works - but I expected that is one instance of file, and this
> > file is linked to messages. But here in folder I have got this:
> >
> > sudo ls -la /var/mail/attachments/8b/67/
> >
> > -rw-rw-rw- 3 buser dovecot 5425280 Jan 5 23:13
> >
> 8b67b29a73b74ecf48e17e789051602cec13aa78cc01c06c8eee1ca4be7c8e07f700cdc9e9ca0381fa3541bdd4e26289de1d7eee763233dfaa0a200a264e5258-0258913a92f2f45f0d70035f3f08
> > -rw-rw-rw- 1 cuser dovecot 5425280 Jan 5 23:13
> >
> 8b67b29a73b74ecf48e17e789051602cec13aa78cc01c06c8eee1ca4be7c8e07f700cdc9e9ca0381fa3541bdd4e26289de1d7eee763233dfaa0a200a264e5258-28571b018ff2f45f0c70035f3f08
> > -rw-rw-rw- 3 buser dovecot 5425280 Jan 5 23:13
> >
> 8b67b29a73b74ecf48e17e789051602cec13aa78cc01c06c8eee1ca4be7c8e07f700cdc9e9ca0381fa3541bdd4e26289de1d7eee763233dfaa0a200a264e5258-50315d3a8ef2f45f0a70035f3f08
> > -rw-rw-rw- 1 auser dovecot 5425280 Jan 5 23:13
> >
> 8b67b29a73b74ecf48e17e789051602cec13aa78cc01c06c8eee1ca4be7c8e07f700cdc9e9ca0381fa3541bdd4e26289de1d7eee763233dfaa0a200a264e5258-586cdb378ef2f45f0770035f3f08
> > drwxrwsrwx 2 buser dovecot4096 Jan 5 23:13 hashes
> >
> > sudo ls -la /var/mail/attachments/8b/67/hashes/
> >
> > -rw-rw-rw- 3 buser dovecot 5425280 Jan 5 23:13
> >
> 8b67b29a73b74ecf48e17e789051602cec13aa78cc01c06c8eee1ca4be7c8e07f700cdc9e9ca0381fa3541bdd4e26289de1d7eee763233dfaa0a200a264e5258
> >
> >
> > What is wrog? How to setup SIS to get one instance of file?
>
> SIS uses hard links. In your example the attachment in 8b/67/hashes/ is
> referenced in 2 other files (aka attached in 2 mails) in the 8b/67/
> directory. So the data is stored only once on disk but referenced in 3
> directory entries. You can see the refcount in column 3 of ls -l.
>
> Best,
> --
> Patrick Cernko +49 681 9325 5815
> Joint Administration: Information Services and Technology
> Max-Planck-Institute für Informatik & Softwaresysteme
>
>
systemd-homed
Hi, I’ve been looking into a problem with a local dovecot setup with ~systemd-homed~ and uses PAM authentication. To give a brief overview, ~systemd-homed~ mounts the users home directory upon particular authencation calls (which is configurable through ~/etc/pam.d~). Dovecot currently supports PAM authentication perfectly fine — the problem comes when a system has systemd-homed. This is because the session is created and deleted immediately afterwards [1]. This is a problem because if the server isn’t busy, systemd-homed can run it’s cleanup which causes the home directory to be unavailable once again [2]. To support this properly, ideally the whole of the imap/pop3/lda session needs to happen before the deletion of the session. Does the imap session happen within a ~verify_plain~ [3] call? If not, are there any other authentication backends which currently need to keep a live token? Yilin [1] https://github.com/dovecot/core/blob/266e54b7b8c34c9a58dd60a2e53c5ca7d1deae19/src/auth/passdb-pam.c#L219 [2] https://dovecot.org/pipermail/dovecot/2019-April/115559.html [3] https://github.com/dovecot/core/blob/266e54b7b8c34c9a58dd60a2e53c5ca7d1deae19/src/auth/passdb.h#L44
problem building on centos 8 (8.3 kernel)
Hi,
I'm converting from qmailtoaster/vpopmail build.
When I try to build dovecot-2.3.13-2.src.rpm for centos 8.3 the first thing I
run into is this:
+ sed -i 's|/etc/ssl|/etc/pki/dovecot|' doc/mkcert.sh
doc/example-config/conf.d/10-ssl.conf
+ '[' -e buildinfo.commit ']'
++ head -1 buildinfo.commit
+ COMMIT=89f716dc2ec7362864a368d32533184b55fb7831
++ /bin/sh /home/build/rpmbuild/SOURCES/lsb_release -is
/bin/sh: /home/build/rpmbuild/SOURCES/lsb_release: No such file or directory
+ ID=
error: Bad exit status from /var/tmp/rpm-tmp.WFaLYQ (%build)
RPM build errors:
Macro expanded in comment on line 455: %{_libdir}/dovecot/settings
Bad exit status from /var/tmp/rpm-tmp.WFaLYQ (%build)
I can get past this with an edit to the dovecot.spec file (removing sourcedir):
if [ -e "buildinfo.commit" ]; then
COMMIT=`head -1 buildinfo.commit`
ID=`/bin/sh
%{_sourcedir}/lsb_release
-is`
RELEASE=`/bin/sh
%{_sourcedir}/lsb_release
-rs`
CODENAME=`/bin/sh
%{_sourcedir}/lsb_release
-cs`
ARCH=`arch`
fi
The RPM builds but it fails to run with this message in the logs:
Jan 6 20:52:11 beta1 systemd[1]: Starting Dovecot IMAP/POP3 email server...
Jan 6 20:52:11 beta1 systemd[1]: Started Dovecot IMAP/POP3 email server.
Jan 6 20:52:11 beta1 dovecot[356909]: /usr/sbin/dovecot: error while loading
shared libraries: libdovecot.so.0: cannot open shared object
file: No such file or directory
Jan 6 20:52:11 beta1 systemd[1]: dovecot.service: Main process exited,
code=exited, status=127/n/a
Jan 6 20:52:11 beta1 systemd[1]: dovecot.service: Failed with result
'exit-code'.
Any ideas what I have going wrong?
Also, a side question, when I build the rpm it's not running the extensive
tests that the old qmailtoaster source rpm used to run. I've
looked through the spec file and I don't really see where to turn that back on.
Sorry if any of this is stupid, but I'm new to building directly from the
dovecot repo.
Steve
multiple mailstores
Hi, I need to merge mail data from two companies to one - i could attach the second storage via NFS which has the sdbox mailbox format while the other one is maildir. Is it possible to have two mail locations with different mailbox formats (maildir and sdbox) on one dovecot instance? Regardless of whether this is possible or not - what is the procedure to switch from maildir to sdbox? I've actually as mail_location set: mail_location = maildir:/srv/vmail/%d/%n/maildir And for the shared namespace: location = maildir:/srv/vmail/%%d/%%n/maildir:INDEX=~/maildir/shared/%%u:CONTROL=~/maildir/shared/%%u How would they look like for sdbox? mail_location most likely: mail_location = sdbox:/srv/vmail/%d/%n/sdbox But how would the location look like for the shared namespace? thx, Alex
Re: Authentication segfault with Dovecot 2.3.13
On Wed, Jan 06, 2021 at 14:07:06 -0500, Josef 'Jeff' Sipek wrote:
> Ok, just a quick update. I managed to reproduce it. I'll try to figure out
> where things went wrong.
Two more questions:
(1) Why are you using a UNION in your SQL statement?
(2) Does the crash still happen if you remove the nodelay parts of the SQL
statements?
Thanks,
Jeff.
>
> Thanks,
>
> Jeff.
>
> On Wed, Jan 06, 2021 at 18:22:03 +0100, Harald Leithner wrote:
> > Hi
> >
> > Am 06.01.2021 um 18:08 schrieb Josef 'Jeff' Sipek:
> > > On Wed, Jan 06, 2021 at 17:13:05 +0100, Harald Leithner wrote:
> > >> Hi,
> > >>
> > >
> > >
> > >> and the user part with "user@redacted".
> > >
> > > I assume you did this for additional privacy, and not because you think
> > > that
> > > auth_debug_passwords=no should hide usernames as well.
> >
> > yes
> >
> > >
> > >> The user uses APOP for authentication, but other users login
> > >> successfully with APOP.
> > >
> > > Do you only use APOP? Or are other authentication schemes affected as
> > > well?
> >
> > No
> >
> > >
> > > Can you share your config? (`doveconf -n` will be a good start, any .ext
> > > files may be useful as well)
> >
> > yes here is the dovecot -n
> >
> > [root@mail:~]$ doveconf -n
> > # 2.3.13 (89f716dc2): /etc/dovecot/dovecot.conf
> > # OS: Linux 5.9.16-100.fc32.x86_64 x86_64 Generic release 32 (Generic)
> > # Hostname:
> > auth_cache_negative_ttl = 10 secs
> > auth_cache_size = 64 k
> > auth_cache_ttl = 30 secs
> > auth_mechanisms = CRAM-MD5 DIGEST-MD5 APOP LOGIN PLAIN
> > auth_username_chars =
> > abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@%
> > auth_username_translation =
> > %@AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuVvWwXxYyZz
> > auth_worker_max_count = 150
> > disable_plaintext_auth = no
> > imap_capability = IMAP4 IMAP4rev1 ACL RIGHTS=texk NAMESPACE CHILDREN
> > SORT QUOTA THREAD=ORDEREDSUBJECT UNSELECT IDLE
> > login_greeting =
> > login_log_format_elements = user=<%u> %r %m %c %k
> > mail_max_userip_connections = 100
> > passdb {
> >args = /etc/dovecot/sql.conf
> >driver = sql
> > }
> > protocols = imap pop3
> > service anvil {
> >unix_listener anvil-auth-penalty {
> > mode = 00
> >}
> > }
> > service auth {
> >unix_listener /var/spool/postfix/private/auth {
> > group = postfix
> > mode = 0660
> > user = postfix
> >}
> > }
> > service imap-login {
> >client_limit = 300
> >inet_listener imap {
> > address = xx.xx.xx.xx
> > port = 143
> >}
> >inet_listener imaps {
> > address = xx.xx.xx.xx
> > port = 993
> >}
> >process_limit = 15
> >process_min_avail = 1
> >service_count = 0
> >vsz_limit = 512 M
> > }
> > service pop3-login {
> >client_limit = 300
> >inet_listener pop3 {
> > address = xx.xx.xx.xx
> > port = 110
> >}
> >inet_listener pop3s {
> > address = xx.xx.xx.xx
> > port = 995
> >}
> >process_limit = 15
> >process_min_avail = 1
> >service_count = 0
> >vsz_limit = 512 M
> > }
> > service stats {
> >client_limit = 1
> > }
> > shutdown_clients = no
> > ssl_alt_cert = > ssl_alt_key = # hidden, use -P to show it
> > ssl_cert = > ssl_cipher_list =
> > ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA
> > ssl_dh = # hidden, use -P to show it
> > ssl_key = # hidden, use -P to show it
> > ssl_options = no_compression
> > ssl_prefer_server_ciphers = yes
> > userdb {
> >args = static uid=5000 gid=5000 home=/dev/null
> >driver = static
> > }
> > version_ignore = yes
> > [root@mail:~]$
> >
> >
> > >
> > > Thanks,
> > >
> > > Jeff.
> >
> > thx
> >
> > Harald
> >
> > >
> > >> Here is a stacktrace and a log dump:
> > >>
> > >> Jan 6 16:29:44 mail kernel: auth[2208397]: segfault at ec ip
> > >> 7f67fc147174 sp 7ffeed993150 error 4 in
> > >> libdovecot.so.0.0.0[7f67fc06e000+fc000]
> > >> Jan 6 16:29:44 mail kernel: Code: 1f 80 00 00 00 00 41 54 e8 79 fd ff
> > >> ff 31 f6 49 89 c4 48 89 c7 31 c0 e8 ca f8 ff ff 4c 89 e0 41 5c c3 0f 1f
> > >> 40 00 53 48 89 fb 87 ec 00 00 00 04 75 43 48 83 3d 7b aa 0a 00 00
> > >> 0f 85 50 15 f4
> > >> Jan 6 16:29:44 mail systemd[1]: Started Process Core Dump (PID
> > >> 2208677/UID 0).
> > >> Jan 6 16:29:44 mail systemd-coredump[2208678]: Process 2208397 (auth)
> > >> of user 489 dumped core.#012#012Stack trace of thread 2208397:#012#0
> > >> 0x7f67fc147174 event_create_passthrough (libdovecot.so.0 +
> > >> 0x116174)#012#1 0x555678812d6e auth_request_finished_event (auth +
> > >> 0x1bd6e)#012#2 0x5556788159ae auth_request_log_finished (auth +
> > >> 0x1e9ae)#012#3
Re: test-file-cache.c needs #ifdef HAVE_RLIMIT_AS
OpenBSD Original Message On Jan 6, 2021, 21:37, Aki Tuomi < aki.tu...@open-xchange.com> wrote: Which distro/OS is this? Aki
Re: test-file-cache.c needs #ifdef HAVE_RLIMIT_AS
> On 06/01/2021 21:34 Rupert Gallagher wrote: > > > test-file-cache.c:259:24: error: use of undeclared identifier 'RLIMIT_AS' > test_assert(getrlimit(RLIMIT_AS, _cur) == 0); > ^ > test-file-cache.c:267:24: error: use of undeclared identifier 'RLIMIT_AS' > test_assert(setrlimit(RLIMIT_AS, _new) == 0); > ^ > test-file-cache.c:270:24: error: use of undeclared identifier 'RLIMIT_AS' > test_assert(setrlimit(RLIMIT_AS, _cur) == 0); > ^ > test-file-cache.c:276:24: error: use of undeclared identifier 'RLIMIT_AS' > test_assert(setrlimit(RLIMIT_AS, _new) == 0); > ^ > test-file-cache.c:279:24: error: use of undeclared identifier 'RLIMIT_AS' > test_assert(setrlimit(RLIMIT_AS, _cur) == 0); > ^ Which distro/OS is this? Aki
test-file-cache.c needs #ifdef HAVE_RLIMIT_AS
test-file-cache.c:259:24: error: use of undeclared identifier 'RLIMIT_AS' test_assert(getrlimit(RLIMIT_AS, _cur) == 0); ^ test-file-cache.c:267:24: error: use of undeclared identifier 'RLIMIT_AS' test_assert(setrlimit(RLIMIT_AS, _new) == 0); ^ test-file-cache.c:270:24: error: use of undeclared identifier 'RLIMIT_AS' test_assert(setrlimit(RLIMIT_AS, _cur) == 0); ^ test-file-cache.c:276:24: error: use of undeclared identifier 'RLIMIT_AS' test_assert(setrlimit(RLIMIT_AS, _new) == 0); ^ test-file-cache.c:279:24: error: use of undeclared identifier 'RLIMIT_AS' test_assert(setrlimit(RLIMIT_AS, _cur) == 0); ^
Re: Authentication segfault with Dovecot 2.3.13
Ok, just a quick update. I managed to reproduce it. I'll try to figure out
where things went wrong.
Thanks,
Jeff.
On Wed, Jan 06, 2021 at 18:22:03 +0100, Harald Leithner wrote:
> Hi
>
> Am 06.01.2021 um 18:08 schrieb Josef 'Jeff' Sipek:
> > On Wed, Jan 06, 2021 at 17:13:05 +0100, Harald Leithner wrote:
> >> Hi,
> >>
> >
> >
> >> and the user part with "user@redacted".
> >
> > I assume you did this for additional privacy, and not because you think that
> > auth_debug_passwords=no should hide usernames as well.
>
> yes
>
> >
> >> The user uses APOP for authentication, but other users login
> >> successfully with APOP.
> >
> > Do you only use APOP? Or are other authentication schemes affected as well?
>
> No
>
> >
> > Can you share your config? (`doveconf -n` will be a good start, any .ext
> > files may be useful as well)
>
> yes here is the dovecot -n
>
> [root@mail:~]$ doveconf -n
> # 2.3.13 (89f716dc2): /etc/dovecot/dovecot.conf
> # OS: Linux 5.9.16-100.fc32.x86_64 x86_64 Generic release 32 (Generic)
> # Hostname:
> auth_cache_negative_ttl = 10 secs
> auth_cache_size = 64 k
> auth_cache_ttl = 30 secs
> auth_mechanisms = CRAM-MD5 DIGEST-MD5 APOP LOGIN PLAIN
> auth_username_chars =
> abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@%
> auth_username_translation =
> %@AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuVvWwXxYyZz
> auth_worker_max_count = 150
> disable_plaintext_auth = no
> imap_capability = IMAP4 IMAP4rev1 ACL RIGHTS=texk NAMESPACE CHILDREN
> SORT QUOTA THREAD=ORDEREDSUBJECT UNSELECT IDLE
> login_greeting =
> login_log_format_elements = user=<%u> %r %m %c %k
> mail_max_userip_connections = 100
> passdb {
>args = /etc/dovecot/sql.conf
>driver = sql
> }
> protocols = imap pop3
> service anvil {
>unix_listener anvil-auth-penalty {
> mode = 00
>}
> }
> service auth {
>unix_listener /var/spool/postfix/private/auth {
> group = postfix
> mode = 0660
> user = postfix
>}
> }
> service imap-login {
>client_limit = 300
>inet_listener imap {
> address = xx.xx.xx.xx
> port = 143
>}
>inet_listener imaps {
> address = xx.xx.xx.xx
> port = 993
>}
>process_limit = 15
>process_min_avail = 1
>service_count = 0
>vsz_limit = 512 M
> }
> service pop3-login {
>client_limit = 300
>inet_listener pop3 {
> address = xx.xx.xx.xx
> port = 110
>}
>inet_listener pop3s {
> address = xx.xx.xx.xx
> port = 995
>}
>process_limit = 15
>process_min_avail = 1
>service_count = 0
>vsz_limit = 512 M
> }
> service stats {
>client_limit = 1
> }
> shutdown_clients = no
> ssl_alt_cert = ssl_alt_key = # hidden, use -P to show it
> ssl_cert = ssl_cipher_list =
> ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA
> ssl_dh = # hidden, use -P to show it
> ssl_key = # hidden, use -P to show it
> ssl_options = no_compression
> ssl_prefer_server_ciphers = yes
> userdb {
>args = static uid=5000 gid=5000 home=/dev/null
>driver = static
> }
> version_ignore = yes
> [root@mail:~]$
>
>
> >
> > Thanks,
> >
> > Jeff.
>
> thx
>
> Harald
>
> >
> >> Here is a stacktrace and a log dump:
> >>
> >> Jan 6 16:29:44 mail kernel: auth[2208397]: segfault at ec ip
> >> 7f67fc147174 sp 7ffeed993150 error 4 in
> >> libdovecot.so.0.0.0[7f67fc06e000+fc000]
> >> Jan 6 16:29:44 mail kernel: Code: 1f 80 00 00 00 00 41 54 e8 79 fd ff
> >> ff 31 f6 49 89 c4 48 89 c7 31 c0 e8 ca f8 ff ff 4c 89 e0 41 5c c3 0f 1f
> >> 40 00 53 48 89 fb 87 ec 00 00 00 04 75 43 48 83 3d 7b aa 0a 00 00
> >> 0f 85 50 15 f4
> >> Jan 6 16:29:44 mail systemd[1]: Started Process Core Dump (PID
> >> 2208677/UID 0).
> >> Jan 6 16:29:44 mail systemd-coredump[2208678]: Process 2208397 (auth)
> >> of user 489 dumped core.#012#012Stack trace of thread 2208397:#012#0
> >> 0x7f67fc147174 event_create_passthrough (libdovecot.so.0 +
> >> 0x116174)#012#1 0x555678812d6e auth_request_finished_event (auth +
> >> 0x1bd6e)#012#2 0x5556788159ae auth_request_log_finished (auth +
> >> 0x1e9ae)#012#3 0x555678816ee0 n/a (auth + 0x1fee0)#012#4
> >> 0x555678826dc1 passdb_handle_credentials (auth + 0x2fdc1)#012#5
> >> 0x555678816c7e n/a (auth + 0x1fc7e)#012#6 0x555678824f27 n/a
> >> (auth + 0x2df27)#012#7 0x55567881b02d
> >> auth_request_handler_auth_begin (auth + 0x2402d)#012#8
> >> 0x55567880dfaf n/a (auth + 0x16faf)#012#9 0x7f67fc143a79
> >> io_loop_call_io (libdovecot.so.0 + 0x112a79)#012#10 0x7f67fc144ae2
> >> io_loop_handler_run_internal (libdovecot.so.0 + 0x113ae2)#012#11
> >> 0x7f67fc143b21 io_loop_handler_run
Re: Pigeonhole v0.5.13 released
Il 04/01/21 13:02, Aki Tuomi ha scritto: We are pleased to release pigeonhole 0.5.13. You can download it from locations below: https://pigeonhole.dovecot.org/releases/2.3/dovecot-2.3-pigeonhole-0.5.13.tar.gz https://pigeonhole.dovecot.org/releases/2.3/dovecot-2.3-pigeonhole-0.5.13.tar.gz.sig Binary packages in https://repo.dovecot.org/ Docker images in https://hub.docker.com/r/dovecot/dovecot Hi, why after 2.3.10 release dovecot-pigeonhole, but also dovecot-coi, SRC RPM packages are no more available in the SRPMS repo directory? I need to rebuild from source for some systems. Thanks -- Alessio Cecchi Postmaster @ http://www.qboxmail.it https://www.linkedin.com/in/alessice
Re: Authentication segfault with Dovecot 2.3.13
Hi
Am 06.01.2021 um 18:08 schrieb Josef 'Jeff' Sipek:
On Wed, Jan 06, 2021 at 17:13:05 +0100, Harald Leithner wrote:
Hi,
and the user part with "user@redacted".
I assume you did this for additional privacy, and not because you think that
auth_debug_passwords=no should hide usernames as well.
yes
The user uses APOP for authentication, but other users login
successfully with APOP.
Do you only use APOP? Or are other authentication schemes affected as well?
No
Can you share your config? (`doveconf -n` will be a good start, any .ext
files may be useful as well)
yes here is the dovecot -n
[root@mail:~]$ doveconf -n
# 2.3.13 (89f716dc2): /etc/dovecot/dovecot.conf
# OS: Linux 5.9.16-100.fc32.x86_64 x86_64 Generic release 32 (Generic)
# Hostname:
auth_cache_negative_ttl = 10 secs
auth_cache_size = 64 k
auth_cache_ttl = 30 secs
auth_mechanisms = CRAM-MD5 DIGEST-MD5 APOP LOGIN PLAIN
auth_username_chars =
abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234567890.-_@%
auth_username_translation =
%@AaBbCcDdEeFfGgHhIiJjKkLlMmNnOoPpQqRrSsTtUuVvWwXxYyZz
auth_worker_max_count = 150
disable_plaintext_auth = no
imap_capability = IMAP4 IMAP4rev1 ACL RIGHTS=texk NAMESPACE CHILDREN
SORT QUOTA THREAD=ORDEREDSUBJECT UNSELECT IDLE
login_greeting =
login_log_format_elements = user=<%u> %r %m %c %k
mail_max_userip_connections = 100
passdb {
args = /etc/dovecot/sql.conf
driver = sql
}
protocols = imap pop3
service anvil {
unix_listener anvil-auth-penalty {
mode = 00
}
}
service auth {
unix_listener /var/spool/postfix/private/auth {
group = postfix
mode = 0660
user = postfix
}
}
service imap-login {
client_limit = 300
inet_listener imap {
address = xx.xx.xx.xx
port = 143
}
inet_listener imaps {
address = xx.xx.xx.xx
port = 993
}
process_limit = 15
process_min_avail = 1
service_count = 0
vsz_limit = 512 M
}
service pop3-login {
client_limit = 300
inet_listener pop3 {
address = xx.xx.xx.xx
port = 110
}
inet_listener pop3s {
address = xx.xx.xx.xx
port = 995
}
process_limit = 15
process_min_avail = 1
service_count = 0
vsz_limit = 512 M
}
service stats {
client_limit = 1
}
shutdown_clients = no
ssl_alt_cert = ssl_cipher_list =
ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA:AES256-SHA
ssl_dh = # hidden, use -P to show it
ssl_key = # hidden, use -P to show it
ssl_options = no_compression
ssl_prefer_server_ciphers = yes
userdb {
args = static uid=5000 gid=5000 home=/dev/null
driver = static
}
version_ignore = yes
[root@mail:~]$
Thanks,
Jeff.
thx
Harald
Here is a stacktrace and a log dump:
Jan 6 16:29:44 mail kernel: auth[2208397]: segfault at ec ip
7f67fc147174 sp 7ffeed993150 error 4 in
libdovecot.so.0.0.0[7f67fc06e000+fc000]
Jan 6 16:29:44 mail kernel: Code: 1f 80 00 00 00 00 41 54 e8 79 fd ff
ff 31 f6 49 89 c4 48 89 c7 31 c0 e8 ca f8 ff ff 4c 89 e0 41 5c c3 0f 1f
40 00 53 48 89 fb 87 ec 00 00 00 04 75 43 48 83 3d 7b aa 0a 00 00
0f 85 50 15 f4
Jan 6 16:29:44 mail systemd[1]: Started Process Core Dump (PID
2208677/UID 0).
Jan 6 16:29:44 mail systemd-coredump[2208678]: Process 2208397 (auth)
of user 489 dumped core.#012#012Stack trace of thread 2208397:#012#0
0x7f67fc147174 event_create_passthrough (libdovecot.so.0 +
0x116174)#012#1 0x555678812d6e auth_request_finished_event (auth +
0x1bd6e)#012#2 0x5556788159ae auth_request_log_finished (auth +
0x1e9ae)#012#3 0x555678816ee0 n/a (auth + 0x1fee0)#012#4
0x555678826dc1 passdb_handle_credentials (auth + 0x2fdc1)#012#5
0x555678816c7e n/a (auth + 0x1fc7e)#012#6 0x555678824f27 n/a
(auth + 0x2df27)#012#7 0x55567881b02d
auth_request_handler_auth_begin (auth + 0x2402d)#012#8
0x55567880dfaf n/a (auth + 0x16faf)#012#9 0x7f67fc143a79
io_loop_call_io (libdovecot.so.0 + 0x112a79)#012#10 0x7f67fc144ae2
io_loop_handler_run_internal (libdovecot.so.0 + 0x113ae2)#012#11
0x7f67fc143b21 io_loop_handler_run (libdovecot.so.0 +
0x112b21)#012#12 0x7f67fc143ce0 io_loop_run (libdovecot.so.0 +
0x112ce0)#012#13 0x7f67fc0b96f3 master_service_run (libdovecot.so.0
+ 0x886f3)#012#14 0x55567880c2db main (auth + 0x152db)#012#15
0x7f67fbc9d042 __libc_start_main (libc.so.6 + 0x27042)#012#16
0x55567880c48e _start (auth + 0x1548e)
Jan 6 16:29:44 mail dovecot[2208071]: auth: Debug: client in:
AUTH#011134#011PLAIN#011service=imap#011session=tgog/jy4erm5j7ZO#011lip=lan-ip#011rip=client-ip#011lport=143#011rport=47482
Jan 6 16:29:44 mail dovecot[2208071]: auth: Debug: client passdb out:
CONT#011134
Jan 6 16:29:44 mail dovecot[2208071]: auth: Debug: client in: CONT
Jan 6 16:29:44
Re: Authentication segfault with Dovecot 2.3.13
Hi, small correction, the devices that tries to login and triggers the segfault uses an old password and can't login and segfaults the auth process. On 2.2 the login wasn't successful too but didn't segfault. Harald Am 06.01.2021 um 18:01 schrieb John Stoffel: "Harald" == Harald Leithner writes: Harald> we have a problem upgrading Dovecot from 2.2 to 2.3.13 on one Harald> server it seems one user triggers a segfault while trying to Harald> authenticate. Can you get the user to change their password to not have quite some special characters maybe? Or maybe ask them if they have any special characters? There was a bug recently with passwords as I recall. In this case, it's probably a dovecot bug, but it's fixable for now if the user changes their password. I think. Harald> The user works fine with 2.2.36.4, our last update try mid-late 2020 was Harald> aborted because of this reason. Harald> While debugging the problem we noticed that the "auth_debug_passwords = Harald> no" option doesn't work at least in our logfiles are the passwords Harald> logged. We replaced the password in the log with Harald> "THIS_SHOULD_NOT_GET_LOGGED" and the user part with "user@redacted". Harald> The user uses APOP for authentication, but other users login Harald> successfully with APOP. Harald> Here is a stacktrace and a log dump: Harald> Jan 6 16:29:44 mail kernel: auth[2208397]: segfault at ec ip Harald> 7f67fc147174 sp 7ffeed993150 error 4 in Harald> libdovecot.so.0.0.0[7f67fc06e000+fc000] Harald> Jan 6 16:29:44 mail kernel: Code: 1f 80 00 00 00 00 41 54 e8 79 fd ff Harald> ff 31 f6 49 89 c4 48 89 c7 31 c0 e8 ca f8 ff ff 4c 89 e0 41 5c c3 0f 1f Harald> 40 00 53 48 89 fb 87 ec 00 00 00 04 75 43 48 83 3d 7b aa 0a 00 00 Harald> 0f 85 50 15 f4 Harald> Jan 6 16:29:44 mail systemd[1]: Started Process Core Dump (PID Harald> 2208677/UID 0). Harald> Jan 6 16:29:44 mail systemd-coredump[2208678]: Process 2208397 (auth) Harald> of user 489 dumped core.#012#012Stack trace of thread 2208397:#012#0 Harald> 0x7f67fc147174 event_create_passthrough (libdovecot.so.0 + Harald> 0x116174)#012#1 0x555678812d6e auth_request_finished_event (auth + Harald> 0x1bd6e)#012#2 0x5556788159ae auth_request_log_finished (auth + Harald> 0x1e9ae)#012#3 0x555678816ee0 n/a (auth + 0x1fee0)#012#4 Harald> 0x555678826dc1 passdb_handle_credentials (auth + 0x2fdc1)#012#5 Harald> 0x555678816c7e n/a (auth + 0x1fc7e)#012#6 0x555678824f27 n/a Harald> (auth + 0x2df27)#012#7 0x55567881b02d Harald> auth_request_handler_auth_begin (auth + 0x2402d)#012#8 Harald> 0x55567880dfaf n/a (auth + 0x16faf)#012#9 0x7f67fc143a79 Harald> io_loop_call_io (libdovecot.so.0 + 0x112a79)#012#10 0x7f67fc144ae2 Harald> io_loop_handler_run_internal (libdovecot.so.0 + 0x113ae2)#012#11 Harald> 0x7f67fc143b21 io_loop_handler_run (libdovecot.so.0 + Harald> 0x112b21)#012#12 0x7f67fc143ce0 io_loop_run (libdovecot.so.0 + Harald> 0x112ce0)#012#13 0x7f67fc0b96f3 master_service_run (libdovecot.so.0 Harald> + 0x886f3)#012#14 0x55567880c2db main (auth + 0x152db)#012#15 Harald> 0x7f67fbc9d042 __libc_start_main (libc.so.6 + 0x27042)#012#16 Harald> 0x55567880c48e _start (auth + 0x1548e) Harald> Jan 6 16:29:44 mail dovecot[2208071]: auth: Debug: client in: Harald> AUTH#011134#011PLAIN#011service=imap#011session=tgog/jy4erm5j7ZO#011lip=lan-ip#011rip=client-ip#011lport=143#011rport=47482 Harald> Jan 6 16:29:44 mail dovecot[2208071]: auth: Debug: client passdb out: Harald> CONT#011134 Harald> Jan 6 16:29:44 mail dovecot[2208071]: auth: Debug: client in: CONT Harald> Jan 6 16:29:44 mail dovecot[2208071]: auth: Debug: Harald> sql(user@redacted,client-ip,): Performing passdb lookup Harald> Jan 6 16:29:44 mail dovecot[2208071]: auth: Debug: Harald> sql(user@redacted,client-ip,): cache expired Harald> Jan 6 16:29:44 mail dovecot[2208071]: auth-worker(2208404): Debug: conn Harald> unix:auth-worker (pid=2208397,uid=489): auth-worker<229>: Handling PASSV Harald> request Harald> Jan 6 16:29:44 mail dovecot[2208071]: auth-worker(2208404): Debug: conn Harald> unix:auth-worker (pid=2208397,uid=489): auth-worker<229>: Harald> sql(user@redacted,client-ip,): Performing passdb lookup Harald> Jan 6 16:29:44 mail dovecot[2208071]: auth-worker(2208404): Debug: conn Harald> unix:auth-worker (pid=2208397,uid=489): auth-worker<229>: Harald> sql(user@redacted,client-ip,): query: SELECT passwd as Harald> password, '127.0.0.1' as host, userid as destuser, passwd AS pass, 'Y' Harald> AS nologin, 'Y' AS nodelay, 'Y' AS proxy FROM dbmail_users WHERE Harald> userid='user@redacted' UNION (SELECT password as password, '127.0.0.1' Harald> as host, username as destuser, password AS pass, 'Y' AS nologin, 'Y' AS Harald> nodelay, 'Y' AS proxy FROM sasl_fake_auth WHERE Harald> username='user@redacted') limit 1; Harald> Jan 6 16:29:44 mail dovecot[2208071]: auth-worker(2208404): conn Harald> unix:auth-worker (pid=2208397,uid=489):
Re: Authentication segfault with Dovecot 2.3.13
On Wed, Jan 06, 2021 at 17:13:05 +0100, Harald Leithner wrote: > Hi, > > we have a problem upgrading Dovecot from 2.2 to 2.3.13 on one server it > seems one user triggers a segfault while trying to authenticate. > > The user works fine with 2.2.36.4, our last update try mid-late 2020 was > aborted because of this reason. > > While debugging the problem we noticed that the "auth_debug_passwords = > no" option doesn't work at least in our logfiles are the passwords > logged. We replaced the password in the log with > "THIS_SHOULD_NOT_GET_LOGGED" It should. It looks like on of the places in the code (specifically the "cache hit" message) has password hiding code that's buggy/incomplete. > and the user part with "user@redacted". I assume you did this for additional privacy, and not because you think that auth_debug_passwords=no should hide usernames as well. > The user uses APOP for authentication, but other users login > successfully with APOP. Do you only use APOP? Or are other authentication schemes affected as well? Can you share your config? (`doveconf -n` will be a good start, any .ext files may be useful as well) Thanks, Jeff. > Here is a stacktrace and a log dump: > > Jan 6 16:29:44 mail kernel: auth[2208397]: segfault at ec ip > 7f67fc147174 sp 7ffeed993150 error 4 in > libdovecot.so.0.0.0[7f67fc06e000+fc000] > Jan 6 16:29:44 mail kernel: Code: 1f 80 00 00 00 00 41 54 e8 79 fd ff > ff 31 f6 49 89 c4 48 89 c7 31 c0 e8 ca f8 ff ff 4c 89 e0 41 5c c3 0f 1f > 40 00 53 48 89 fb 87 ec 00 00 00 04 75 43 48 83 3d 7b aa 0a 00 00 > 0f 85 50 15 f4 > Jan 6 16:29:44 mail systemd[1]: Started Process Core Dump (PID > 2208677/UID 0). > Jan 6 16:29:44 mail systemd-coredump[2208678]: Process 2208397 (auth) > of user 489 dumped core.#012#012Stack trace of thread 2208397:#012#0 > 0x7f67fc147174 event_create_passthrough (libdovecot.so.0 + > 0x116174)#012#1 0x555678812d6e auth_request_finished_event (auth + > 0x1bd6e)#012#2 0x5556788159ae auth_request_log_finished (auth + > 0x1e9ae)#012#3 0x555678816ee0 n/a (auth + 0x1fee0)#012#4 > 0x555678826dc1 passdb_handle_credentials (auth + 0x2fdc1)#012#5 > 0x555678816c7e n/a (auth + 0x1fc7e)#012#6 0x555678824f27 n/a > (auth + 0x2df27)#012#7 0x55567881b02d > auth_request_handler_auth_begin (auth + 0x2402d)#012#8 > 0x55567880dfaf n/a (auth + 0x16faf)#012#9 0x7f67fc143a79 > io_loop_call_io (libdovecot.so.0 + 0x112a79)#012#10 0x7f67fc144ae2 > io_loop_handler_run_internal (libdovecot.so.0 + 0x113ae2)#012#11 > 0x7f67fc143b21 io_loop_handler_run (libdovecot.so.0 + > 0x112b21)#012#12 0x7f67fc143ce0 io_loop_run (libdovecot.so.0 + > 0x112ce0)#012#13 0x7f67fc0b96f3 master_service_run (libdovecot.so.0 > + 0x886f3)#012#14 0x55567880c2db main (auth + 0x152db)#012#15 > 0x7f67fbc9d042 __libc_start_main (libc.so.6 + 0x27042)#012#16 > 0x55567880c48e _start (auth + 0x1548e) > > Jan 6 16:29:44 mail dovecot[2208071]: auth: Debug: client in: > AUTH#011134#011PLAIN#011service=imap#011session=tgog/jy4erm5j7ZO#011lip=lan-ip#011rip=client-ip#011lport=143#011rport=47482 > Jan 6 16:29:44 mail dovecot[2208071]: auth: Debug: client passdb out: > CONT#011134 > Jan 6 16:29:44 mail dovecot[2208071]: auth: Debug: client in: CONT > Jan 6 16:29:44 mail dovecot[2208071]: auth: Debug: > sql(user@redacted,client-ip,): Performing passdb lookup > Jan 6 16:29:44 mail dovecot[2208071]: auth: Debug: > sql(user@redacted,client-ip,): cache expired > Jan 6 16:29:44 mail dovecot[2208071]: auth-worker(2208404): Debug: conn > unix:auth-worker (pid=2208397,uid=489): auth-worker<229>: Handling PASSV > request > Jan 6 16:29:44 mail dovecot[2208071]: auth-worker(2208404): Debug: conn > unix:auth-worker (pid=2208397,uid=489): auth-worker<229>: > sql(user@redacted,client-ip,): Performing passdb lookup > Jan 6 16:29:44 mail dovecot[2208071]: auth-worker(2208404): Debug: conn > unix:auth-worker (pid=2208397,uid=489): auth-worker<229>: > sql(user@redacted,client-ip,): query: SELECT passwd as > password, '127.0.0.1' as host, userid as destuser, passwd AS pass, 'Y' > AS nologin, 'Y' AS nodelay, 'Y' AS proxy FROM dbmail_users WHERE > userid='user@redacted' UNION (SELECT password as password, '127.0.0.1' > as host, username as destuser, password AS pass, 'Y' AS nologin, 'Y' AS > nodelay, 'Y' AS proxy FROM sasl_fake_auth WHERE > username='user@redacted') limit 1; > Jan 6 16:29:44 mail dovecot[2208071]: auth-worker(2208404): conn > unix:auth-worker (pid=2208397,uid=489): auth-worker<229>: > sql(user@redacted,client-ip,): Password mismatch > Jan 6 16:29:44 mail dovecot[2208071]: auth-worker(2208404): Debug: conn > unix:auth-worker (pid=2208397,uid=489): auth-worker<229>: > sql(user@redacted,client-ip,): Finished passdb lookup > Jan 6 16:29:44 mail dovecot[2208071]: auth-worker(2208404): Debug: conn > unix:auth-worker (pid=2208397,uid=489): auth-worker<229>: Finished > Jan 6 16:29:44
Re: Authentication segfault with Dovecot 2.3.13
> "Harald" == Harald Leithner writes: Harald> we have a problem upgrading Dovecot from 2.2 to 2.3.13 on one Harald> server it seems one user triggers a segfault while trying to Harald> authenticate. Can you get the user to change their password to not have quite some special characters maybe? Or maybe ask them if they have any special characters? There was a bug recently with passwords as I recall. In this case, it's probably a dovecot bug, but it's fixable for now if the user changes their password. I think. Harald> The user works fine with 2.2.36.4, our last update try mid-late 2020 was Harald> aborted because of this reason. Harald> While debugging the problem we noticed that the "auth_debug_passwords = Harald> no" option doesn't work at least in our logfiles are the passwords Harald> logged. We replaced the password in the log with Harald> "THIS_SHOULD_NOT_GET_LOGGED" and the user part with "user@redacted". Harald> The user uses APOP for authentication, but other users login Harald> successfully with APOP. Harald> Here is a stacktrace and a log dump: Harald> Jan 6 16:29:44 mail kernel: auth[2208397]: segfault at ec ip Harald> 7f67fc147174 sp 7ffeed993150 error 4 in Harald> libdovecot.so.0.0.0[7f67fc06e000+fc000] Harald> Jan 6 16:29:44 mail kernel: Code: 1f 80 00 00 00 00 41 54 e8 79 fd ff Harald> ff 31 f6 49 89 c4 48 89 c7 31 c0 e8 ca f8 ff ff 4c 89 e0 41 5c c3 0f 1f Harald> 40 00 53 48 89 fb 87 ec 00 00 00 04 75 43 48 83 3d 7b aa 0a 00 00 Harald> 0f 85 50 15 f4 Harald> Jan 6 16:29:44 mail systemd[1]: Started Process Core Dump (PID Harald> 2208677/UID 0). Harald> Jan 6 16:29:44 mail systemd-coredump[2208678]: Process 2208397 (auth) Harald> of user 489 dumped core.#012#012Stack trace of thread 2208397:#012#0 Harald> 0x7f67fc147174 event_create_passthrough (libdovecot.so.0 + Harald> 0x116174)#012#1 0x555678812d6e auth_request_finished_event (auth + Harald> 0x1bd6e)#012#2 0x5556788159ae auth_request_log_finished (auth + Harald> 0x1e9ae)#012#3 0x555678816ee0 n/a (auth + 0x1fee0)#012#4 Harald> 0x555678826dc1 passdb_handle_credentials (auth + 0x2fdc1)#012#5 Harald> 0x555678816c7e n/a (auth + 0x1fc7e)#012#6 0x555678824f27 n/a Harald> (auth + 0x2df27)#012#7 0x55567881b02d Harald> auth_request_handler_auth_begin (auth + 0x2402d)#012#8 Harald> 0x55567880dfaf n/a (auth + 0x16faf)#012#9 0x7f67fc143a79 Harald> io_loop_call_io (libdovecot.so.0 + 0x112a79)#012#10 0x7f67fc144ae2 Harald> io_loop_handler_run_internal (libdovecot.so.0 + 0x113ae2)#012#11 Harald> 0x7f67fc143b21 io_loop_handler_run (libdovecot.so.0 + Harald> 0x112b21)#012#12 0x7f67fc143ce0 io_loop_run (libdovecot.so.0 + Harald> 0x112ce0)#012#13 0x7f67fc0b96f3 master_service_run (libdovecot.so.0 Harald> + 0x886f3)#012#14 0x55567880c2db main (auth + 0x152db)#012#15 Harald> 0x7f67fbc9d042 __libc_start_main (libc.so.6 + 0x27042)#012#16 Harald> 0x55567880c48e _start (auth + 0x1548e) Harald> Jan 6 16:29:44 mail dovecot[2208071]: auth: Debug: client in: Harald> AUTH#011134#011PLAIN#011service=imap#011session=tgog/jy4erm5j7ZO#011lip=lan-ip#011rip=client-ip#011lport=143#011rport=47482 Harald> Jan 6 16:29:44 mail dovecot[2208071]: auth: Debug: client passdb out: Harald> CONT#011134 Harald> Jan 6 16:29:44 mail dovecot[2208071]: auth: Debug: client in: CONT Harald> Jan 6 16:29:44 mail dovecot[2208071]: auth: Debug: Harald> sql(user@redacted,client-ip,): Performing passdb lookup Harald> Jan 6 16:29:44 mail dovecot[2208071]: auth: Debug: Harald> sql(user@redacted,client-ip,): cache expired Harald> Jan 6 16:29:44 mail dovecot[2208071]: auth-worker(2208404): Debug: conn Harald> unix:auth-worker (pid=2208397,uid=489): auth-worker<229>: Handling PASSV Harald> request Harald> Jan 6 16:29:44 mail dovecot[2208071]: auth-worker(2208404): Debug: conn Harald> unix:auth-worker (pid=2208397,uid=489): auth-worker<229>: Harald> sql(user@redacted,client-ip,): Performing passdb lookup Harald> Jan 6 16:29:44 mail dovecot[2208071]: auth-worker(2208404): Debug: conn Harald> unix:auth-worker (pid=2208397,uid=489): auth-worker<229>: Harald> sql(user@redacted,client-ip,): query: SELECT passwd as Harald> password, '127.0.0.1' as host, userid as destuser, passwd AS pass, 'Y' Harald> AS nologin, 'Y' AS nodelay, 'Y' AS proxy FROM dbmail_users WHERE Harald> userid='user@redacted' UNION (SELECT password as password, '127.0.0.1' Harald> as host, username as destuser, password AS pass, 'Y' AS nologin, 'Y' AS Harald> nodelay, 'Y' AS proxy FROM sasl_fake_auth WHERE Harald> username='user@redacted') limit 1; Harald> Jan 6 16:29:44 mail dovecot[2208071]: auth-worker(2208404): conn Harald> unix:auth-worker (pid=2208397,uid=489): auth-worker<229>: Harald> sql(user@redacted,client-ip,): Password mismatch Harald> Jan 6 16:29:44 mail dovecot[2208071]: auth-worker(2208404): Debug: conn Harald> unix:auth-worker (pid=2208397,uid=489):
Re: doveadm backup only working once?
No, I'm suggesting you use any other mail format than mbox, like maildir, sdbox or mdbox. sdbox or maildir is pretty safe bet. Aki > On 06/01/2021 16:53 Engelbert Torremans wrote: > > > OK. So you are suggesting that moving to mdbox could solve my problem? > > I could migrate/reconfigure my "server2" to mdbox while keeping my > "production/server1" running on mbox and backup everything from > server1->server2 and switch over once everything proves to be working OK. > > Engelbert > > Op 6-1-2021 om 15:40 schreef Aki Tuomi: > > Hi! > > > > dsync has limited support to work with mbox format, which is mainly to get > > away from it. > > > > Aki > > > >> On 06/01/2021 16:37 Christian Kivalo wrote: > >> > >> > >> On January 6, 2021 2:14:32 PM GMT+01:00, Engelbert Torremans > >> wrote: > >>> All, > >>> > >>> Maybe a relevant piece of additional information that could help in > >>> figurring out what is going wrong here that I forgot to add in my > >>> previous posting. > >>> > >>> After the succesfull first backup execution using: > >>> #doveadm -D -v backup -R -f -u synctest tcp:192.168.3.1:12345 > >>> > >>> as described in detail below the /var/mail/synctest inbox file contains > >>> > >>> this (using mail -f /var/mail/synctest): > >>> > >>> root@mail:/var/mail# mail -f synctest > >>> Mail version 8.1.2 01/15/2001. Type ? for help. > >>> "synctest": 2 messages 2 unread > U 1 torrem...@mail.to Mon Jan 04 17:56 29/1016 Testmail 1 > >>> U 2 torrem...@mail.to Mon Jan 04 17:56 28/982 Testmail 2 > >>> > >>> After the 2nd backup command (same command) it contains: > >>> > >>> root@server2:/var/mail# mail -f synctest > >>> Mail version 8.1.2 01/15/2001. Type ? for help. > >>> "synctest": 1 message > 1 MAILER-DAEMON@ser Wed Jan 06 14:05 13/534 DON'T DELETE THIS > >>> MESSAGE -- FOLDER INTERNAL DATA > >>> > >>> Looks like for some reason the inbox file is reset/recreated? Anybody > >>> any idea what could cause this behaviour? Running the doveadm backup > >>> command a 3rd of 4th time does not change the /var/mail/synctest file > >>> anymore. Also the date/time of the file is not updated anymore > >> I can't help with your specific problem but you should not use mbox > >> anymore, especially with replication. > >>> Thanks, > >>> > >>> Engelbert > >>> > >>> Op 4-1-2021 om 18:25 schreef Engelbert Torremans: > All, > > For the past 2 weeks I have been trying to get dovecot mail backup > working between 2 debian 10 machines. > > Both machines are running the same OS (Debian 10) and configuration > wise they are similar (except of course ip addresses, hostnames etc). > > My "main" machine is called "server" and the 2nd machine is > >>> "server2". > See below for the dovecot -n output on server2. > > I created a testuser called synctest on both server1 and server2 and > have sent a couple (2) email messages to synctest@server. > > Those testmessages are now present in /var/mail/synctest mbox file on > server1. > > When trying to create a backup from server->server2 for user synctest > I use this command: > > #doveadm -D -v backup -R -f -u synctest tcp:192.168.3.1:12345 > (using something similar from server1 -> server2 like this: #doveadm > -D -v backup -f -u synctest tcp:192.168.3.2:12345 has the same > >>> results > btw) > > The first attempte appears to be working OK but the the 2nd attempt > (nothing was changed on server1 before the 2nd attempt) fails with > soemthing like: Error: Couldn't delete mailbox INBOX: Permission > >>> denied > Before I can get a succesfull backup again I need to do this (on > >>> server2): > #rm /var/mail/synctest > #rm -r ~syncuser/mail/index/INBOX > #doveadm mailbox delete -u synctest INBOX > (if I don't do the rm /var/mail/synctest before the doveadm mailbox > delete command I will also get a: > Error: Can't delete mailbox INBOX: Permission denied > > Anybody any idea what is happening here? Should I enable replicator > and/or aggregator? > > Output of 1st and 2nd dovadm backup attempt is below: > > root@server2:/home/synctest/mail# doveadm -D -v backup -R -f -u > synctest tcp:192.168.3.1:12345 > Debug: Loading modules from directory: > >>> /usr/lib/dovecot/modules/doveadm > Debug: Skipping module doveadm_acl_plugin, because dlopen() failed: > /usr/lib/dovecot/modules/doveadm/lib10_doveadm_acl_plugin.so: > undefined symbol: acl_user_module (this is usually intentional, so > just ignore this message) > Debug: Skipping module doveadm_expire_plugin, because dlopen() > >>> failed: > /usr/lib/dovecot/modules/doveadm/lib10_doveadm_expire_plugin.so: > undefined symbol: expire_set_deinit (this is usually intentional, so > just ignore this message) > Debug: Skipping module
Re: doveadm backup only working once?
I experienced some corruption with mdbox that I had to move away from it to Maildir. Anyway, that's just me, On Wed, 6 Jan 2021 at 17:54, Engelbert Torremans wrote: > OK. So you are suggesting that moving to mdbox could solve my problem? > > I could migrate/reconfigure my "server2" to mdbox while keeping my > "production/server1" running on mbox and backup everything from > server1->server2 and switch over once everything proves to be working OK. > > Engelbert > > Op 6-1-2021 om 15:40 schreef Aki Tuomi: > > Hi! > > > > dsync has limited support to work with mbox format, which is mainly to > get away from it. > > > > Aki > > > >> On 06/01/2021 16:37 Christian Kivalo wrote: > >> > >> > >> On January 6, 2021 2:14:32 PM GMT+01:00, Engelbert Torremans < > engelb...@torremans.com> wrote: > >>> All, > >>> > >>> Maybe a relevant piece of additional information that could help in > >>> figurring out what is going wrong here that I forgot to add in my > >>> previous posting. > >>> > >>> After the succesfull first backup execution using: > >>> #doveadm -D -v backup -R -f -u synctest tcp:192.168.3.1:12345 > >>> > >>> as described in detail below the /var/mail/synctest inbox file contains > >>> > >>> this (using mail -f /var/mail/synctest): > >>> > >>> root@mail:/var/mail# mail -f synctest > >>> Mail version 8.1.2 01/15/2001. Type ? for help. > >>> "synctest": 2 messages 2 unread > U 1 torrem...@mail.to Mon Jan 04 17:56 29/1016 Testmail 1 > >>> U 2 torrem...@mail.to Mon Jan 04 17:56 28/982 Testmail 2 > >>> > >>> After the 2nd backup command (same command) it contains: > >>> > >>> root@server2:/var/mail# mail -f synctest > >>> Mail version 8.1.2 01/15/2001. Type ? for help. > >>> "synctest": 1 message > 1 MAILER-DAEMON@ser Wed Jan 06 14:05 13/534 DON'T DELETE > THIS > >>> MESSAGE -- FOLDER INTERNAL DATA > >>> > >>> Looks like for some reason the inbox file is reset/recreated? Anybody > >>> any idea what could cause this behaviour? Running the doveadm backup > >>> command a 3rd of 4th time does not change the /var/mail/synctest file > >>> anymore. Also the date/time of the file is not updated anymore > >> I can't help with your specific problem but you should not use mbox > anymore, especially with replication. > >>> Thanks, > >>> > >>> Engelbert > >>> > >>> Op 4-1-2021 om 18:25 schreef Engelbert Torremans: > All, > > For the past 2 weeks I have been trying to get dovecot mail backup > working between 2 debian 10 machines. > > Both machines are running the same OS (Debian 10) and configuration > wise they are similar (except of course ip addresses, hostnames etc). > > My "main" machine is called "server" and the 2nd machine is > >>> "server2". > See below for the dovecot -n output on server2. > > I created a testuser called synctest on both server1 and server2 and > have sent a couple (2) email messages to synctest@server. > > Those testmessages are now present in /var/mail/synctest mbox file on > server1. > > When trying to create a backup from server->server2 for user synctest > I use this command: > > #doveadm -D -v backup -R -f -u synctest tcp:192.168.3.1:12345 > (using something similar from server1 -> server2 like this: #doveadm > -D -v backup -f -u synctest tcp:192.168.3.2:12345 has the same > >>> results > btw) > > The first attempte appears to be working OK but the the 2nd attempt > (nothing was changed on server1 before the 2nd attempt) fails with > soemthing like: Error: Couldn't delete mailbox INBOX: Permission > >>> denied > Before I can get a succesfull backup again I need to do this (on > >>> server2): > #rm /var/mail/synctest > #rm -r ~syncuser/mail/index/INBOX > #doveadm mailbox delete -u synctest INBOX > (if I don't do the rm /var/mail/synctest before the doveadm mailbox > delete command I will also get a: > Error: Can't delete mailbox INBOX: Permission denied > > Anybody any idea what is happening here? Should I enable replicator > and/or aggregator? > > Output of 1st and 2nd dovadm backup attempt is below: > > root@server2:/home/synctest/mail# doveadm -D -v backup -R -f -u > synctest tcp:192.168.3.1:12345 > Debug: Loading modules from directory: > >>> /usr/lib/dovecot/modules/doveadm > Debug: Skipping module doveadm_acl_plugin, because dlopen() failed: > /usr/lib/dovecot/modules/doveadm/lib10_doveadm_acl_plugin.so: > undefined symbol: acl_user_module (this is usually intentional, so > just ignore this message) > Debug: Skipping module doveadm_expire_plugin, because dlopen() > >>> failed: > /usr/lib/dovecot/modules/doveadm/lib10_doveadm_expire_plugin.so: > undefined symbol: expire_set_deinit (this is usually intentional, so > just ignore this message) > Debug: Skipping module doveadm_quota_plugin,
Authentication segfault with Dovecot 2.3.13
Hi, we have a problem upgrading Dovecot from 2.2 to 2.3.13 on one server it seems one user triggers a segfault while trying to authenticate. The user works fine with 2.2.36.4, our last update try mid-late 2020 was aborted because of this reason. While debugging the problem we noticed that the "auth_debug_passwords = no" option doesn't work at least in our logfiles are the passwords logged. We replaced the password in the log with "THIS_SHOULD_NOT_GET_LOGGED" and the user part with "user@redacted". The user uses APOP for authentication, but other users login successfully with APOP. Here is a stacktrace and a log dump: Jan 6 16:29:44 mail kernel: auth[2208397]: segfault at ec ip 7f67fc147174 sp 7ffeed993150 error 4 in libdovecot.so.0.0.0[7f67fc06e000+fc000] Jan 6 16:29:44 mail kernel: Code: 1f 80 00 00 00 00 41 54 e8 79 fd ff ff 31 f6 49 89 c4 48 89 c7 31 c0 e8 ca f8 ff ff 4c 89 e0 41 5c c3 0f 1f 40 00 53 48 89 fb 87 ec 00 00 00 04 75 43 48 83 3d 7b aa 0a 00 00 0f 85 50 15 f4 Jan 6 16:29:44 mail systemd[1]: Started Process Core Dump (PID 2208677/UID 0). Jan 6 16:29:44 mail systemd-coredump[2208678]: Process 2208397 (auth) of user 489 dumped core.#012#012Stack trace of thread 2208397:#012#0 0x7f67fc147174 event_create_passthrough (libdovecot.so.0 + 0x116174)#012#1 0x555678812d6e auth_request_finished_event (auth + 0x1bd6e)#012#2 0x5556788159ae auth_request_log_finished (auth + 0x1e9ae)#012#3 0x555678816ee0 n/a (auth + 0x1fee0)#012#4 0x555678826dc1 passdb_handle_credentials (auth + 0x2fdc1)#012#5 0x555678816c7e n/a (auth + 0x1fc7e)#012#6 0x555678824f27 n/a (auth + 0x2df27)#012#7 0x55567881b02d auth_request_handler_auth_begin (auth + 0x2402d)#012#8 0x55567880dfaf n/a (auth + 0x16faf)#012#9 0x7f67fc143a79 io_loop_call_io (libdovecot.so.0 + 0x112a79)#012#10 0x7f67fc144ae2 io_loop_handler_run_internal (libdovecot.so.0 + 0x113ae2)#012#11 0x7f67fc143b21 io_loop_handler_run (libdovecot.so.0 + 0x112b21)#012#12 0x7f67fc143ce0 io_loop_run (libdovecot.so.0 + 0x112ce0)#012#13 0x7f67fc0b96f3 master_service_run (libdovecot.so.0 + 0x886f3)#012#14 0x55567880c2db main (auth + 0x152db)#012#15 0x7f67fbc9d042 __libc_start_main (libc.so.6 + 0x27042)#012#16 0x55567880c48e _start (auth + 0x1548e) Jan 6 16:29:44 mail dovecot[2208071]: auth: Debug: client in: AUTH#011134#011PLAIN#011service=imap#011session=tgog/jy4erm5j7ZO#011lip=lan-ip#011rip=client-ip#011lport=143#011rport=47482 Jan 6 16:29:44 mail dovecot[2208071]: auth: Debug: client passdb out: CONT#011134 Jan 6 16:29:44 mail dovecot[2208071]: auth: Debug: client in: CONT Jan 6 16:29:44 mail dovecot[2208071]: auth: Debug: sql(user@redacted,client-ip,): Performing passdb lookup Jan 6 16:29:44 mail dovecot[2208071]: auth: Debug: sql(user@redacted,client-ip,): cache expired Jan 6 16:29:44 mail dovecot[2208071]: auth-worker(2208404): Debug: conn unix:auth-worker (pid=2208397,uid=489): auth-worker<229>: Handling PASSV request Jan 6 16:29:44 mail dovecot[2208071]: auth-worker(2208404): Debug: conn unix:auth-worker (pid=2208397,uid=489): auth-worker<229>: sql(user@redacted,client-ip,): Performing passdb lookup Jan 6 16:29:44 mail dovecot[2208071]: auth-worker(2208404): Debug: conn unix:auth-worker (pid=2208397,uid=489): auth-worker<229>: sql(user@redacted,client-ip,): query: SELECT passwd as password, '127.0.0.1' as host, userid as destuser, passwd AS pass, 'Y' AS nologin, 'Y' AS nodelay, 'Y' AS proxy FROM dbmail_users WHERE userid='user@redacted' UNION (SELECT password as password, '127.0.0.1' as host, username as destuser, password AS pass, 'Y' AS nologin, 'Y' AS nodelay, 'Y' AS proxy FROM sasl_fake_auth WHERE username='user@redacted') limit 1; Jan 6 16:29:44 mail dovecot[2208071]: auth-worker(2208404): conn unix:auth-worker (pid=2208397,uid=489): auth-worker<229>: sql(user@redacted,client-ip,): Password mismatch Jan 6 16:29:44 mail dovecot[2208071]: auth-worker(2208404): Debug: conn unix:auth-worker (pid=2208397,uid=489): auth-worker<229>: sql(user@redacted,client-ip,): Finished passdb lookup Jan 6 16:29:44 mail dovecot[2208071]: auth-worker(2208404): Debug: conn unix:auth-worker (pid=2208397,uid=489): auth-worker<229>: Finished Jan 6 16:29:44 mail dovecot[2208071]: auth: Debug: sql(user@redacted,client-ip,): Finished passdb lookup Jan 6 16:29:44 mail dovecot[2208071]: auth: Debug: auth(user@redacted,client-ip,): Auth request finished Jan 6 16:29:44 mail dovecot[2208071]: auth: Debug: client in: AUTH#011443#011APOP#011service=pop3#011secured=tls#011session=n58h/jy4a0i5j7ZO#011lip=lan-ip#011rip=client-ip#011lport=995#011rport=18539#011local_name=mail#011resp= Jan 6 16:29:44 mail dovecot[2208071]: auth: Debug: sql(user@redacted,client-ip,): Performing passdb lookup Jan 6 16:29:44 mail dovecot[2208071]: auth: Debug: sql(user@redacted,client-ip,): cache hit:
Re: Pigeonhole v0.5.13 build fails on OS X 10.11.6
Error seen - sorry for this!! > On 6 Jan 2021, at 14:24, Steve Akerman wrote: > > Hi, > > Dovecot 2.3.13 builds successfully on this old OS X, but pigeonhole > v0.5.13fails as below: > > gcc -DHAVE_CONFIG_H -I. -I../.. -I/usr/local/include/dovecot-I../.. > -I../../src/lib-managesieve -fPIE -DPIE -std=gnu99 -g -O2 -Wall -W > -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts > -Wformat=2 -Wbad-function-cast -Wno-duplicate-decl-specifier > -Wstrict-aliasing=2 -fstack-protector-strong -U_FORTIFY_SOURCE > -D_FORTIFY_SOURCE=2 -I../.. -MT managesieve_login-client.o -MD -MP -MF > .deps/managesieve_login-client.Tpo -c -o managesieve_login-client.o `test -f > 'client.c' || echo './'`client.c > In file included from client.c:23: > ./managesieve-proxy.h:8:15: warning: declaration of 'enum > login_proxy_failure_type' will not be visible outside of this function > [-Wvisibility] > enum login_proxy_failure_type type, >^ > client.c:518:3: error: field designator 'proxy_failed' does not refer to any > field in type 'struct client_vfuncs' > .proxy_failed = managesieve_proxy_failed, > ^ > 1 warning and 1 error generated. > make: *** [managesieve_login-client.o] Error 1 > > > This appears to be related to the change from manage sieve_proxy_ error to > manage sieve_proxy_failed. > > Pigeonhole v0.5.11 builds without problem on the same machine. > > The warning appears to be related to the lack of a declaration, but I am no > expert. The error I have no idea!!! > > Is this related to my old compiler, or is there an issue here? > > Can anyone propose a workaround, as I would like to use Dovecot 2.3.13, but > will get version mismatch errors if I do not upgrade pigeonhole. > > Thanks in advance
Re: doveadm backup only working once?
OK. So you are suggesting that moving to mdbox could solve my problem? I could migrate/reconfigure my "server2" to mdbox while keeping my "production/server1" running on mbox and backup everything from server1->server2 and switch over once everything proves to be working OK. Engelbert Op 6-1-2021 om 15:40 schreef Aki Tuomi: Hi! dsync has limited support to work with mbox format, which is mainly to get away from it. Aki On 06/01/2021 16:37 Christian Kivalo wrote: On January 6, 2021 2:14:32 PM GMT+01:00, Engelbert Torremans wrote: All, Maybe a relevant piece of additional information that could help in figurring out what is going wrong here that I forgot to add in my previous posting. After the succesfull first backup execution using: #doveadm -D -v backup -R -f -u synctest tcp:192.168.3.1:12345 as described in detail below the /var/mail/synctest inbox file contains this (using mail -f /var/mail/synctest): root@mail:/var/mail# mail -f synctest Mail version 8.1.2 01/15/2001. Type ? for help. "synctest": 2 messages 2 unread U 1 torrem...@mail.to Mon Jan 04 17:56 29/1016 Testmail 1 U 2 torrem...@mail.to Mon Jan 04 17:56 28/982 Testmail 2 After the 2nd backup command (same command) it contains: root@server2:/var/mail# mail -f synctest Mail version 8.1.2 01/15/2001. Type ? for help. "synctest": 1 message 1 MAILER-DAEMON@ser Wed Jan 06 14:05 13/534 DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA Looks like for some reason the inbox file is reset/recreated? Anybody any idea what could cause this behaviour? Running the doveadm backup command a 3rd of 4th time does not change the /var/mail/synctest file anymore. Also the date/time of the file is not updated anymore I can't help with your specific problem but you should not use mbox anymore, especially with replication. Thanks, Engelbert Op 4-1-2021 om 18:25 schreef Engelbert Torremans: All, For the past 2 weeks I have been trying to get dovecot mail backup working between 2 debian 10 machines. Both machines are running the same OS (Debian 10) and configuration wise they are similar (except of course ip addresses, hostnames etc). My "main" machine is called "server" and the 2nd machine is "server2". See below for the dovecot -n output on server2. I created a testuser called synctest on both server1 and server2 and have sent a couple (2) email messages to synctest@server. Those testmessages are now present in /var/mail/synctest mbox file on server1. When trying to create a backup from server->server2 for user synctest I use this command: #doveadm -D -v backup -R -f -u synctest tcp:192.168.3.1:12345 (using something similar from server1 -> server2 like this: #doveadm -D -v backup -f -u synctest tcp:192.168.3.2:12345 has the same results btw) The first attempte appears to be working OK but the the 2nd attempt (nothing was changed on server1 before the 2nd attempt) fails with soemthing like: Error: Couldn't delete mailbox INBOX: Permission denied Before I can get a succesfull backup again I need to do this (on server2): #rm /var/mail/synctest #rm -r ~syncuser/mail/index/INBOX #doveadm mailbox delete -u synctest INBOX (if I don't do the rm /var/mail/synctest before the doveadm mailbox delete command I will also get a: Error: Can't delete mailbox INBOX: Permission denied Anybody any idea what is happening here? Should I enable replicator and/or aggregator? Output of 1st and 2nd dovadm backup attempt is below: root@server2:/home/synctest/mail# doveadm -D -v backup -R -f -u synctest tcp:192.168.3.1:12345 Debug: Loading modules from directory: /usr/lib/dovecot/modules/doveadm Debug: Skipping module doveadm_acl_plugin, because dlopen() failed: /usr/lib/dovecot/modules/doveadm/lib10_doveadm_acl_plugin.so: undefined symbol: acl_user_module (this is usually intentional, so just ignore this message) Debug: Skipping module doveadm_expire_plugin, because dlopen() failed: /usr/lib/dovecot/modules/doveadm/lib10_doveadm_expire_plugin.so: undefined symbol: expire_set_deinit (this is usually intentional, so just ignore this message) Debug: Skipping module doveadm_quota_plugin, because dlopen() failed: /usr/lib/dovecot/modules/doveadm/lib10_doveadm_quota_plugin.so: undefined symbol: quota_user_module (this is usually intentional, so just ignore this message) Debug: Module loaded: /usr/lib/dovecot/modules/doveadm/lib10_doveadm_sieve_plugin.so Debug: Skipping module doveadm_fts_lucene_plugin, because dlopen() failed: /usr/lib/dovecot/modules/doveadm/lib20_doveadm_fts_lucene_plugin.so: undefined symbol: lucene_index_iter_deinit (this is usually intentional, so just ignore this message) Debug: Skipping module doveadm_fts_plugin, because dlopen() failed: /usr/lib/dovecot/modules/doveadm/lib20_doveadm_fts_plugin.so: undefined symbol: fts_user_get_language_list (this is usually intentional, so just ignore this message) Debug: Skipping module doveadm_mail_crypt_plugin, because dlopen() failed:
Re: doveadm backup only working once?
Hi! dsync has limited support to work with mbox format, which is mainly to get away from it. Aki > On 06/01/2021 16:37 Christian Kivalo wrote: > > > On January 6, 2021 2:14:32 PM GMT+01:00, Engelbert Torremans > wrote: > >All, > > > >Maybe a relevant piece of additional information that could help in > >figurring out what is going wrong here that I forgot to add in my > >previous posting. > > > >After the succesfull first backup execution using: > >#doveadm -D -v backup -R -f -u synctest tcp:192.168.3.1:12345 > > > >as described in detail below the /var/mail/synctest inbox file contains > > > >this (using mail -f /var/mail/synctest): > > > >root@mail:/var/mail# mail -f synctest > >Mail version 8.1.2 01/15/2001. Type ? for help. > >"synctest": 2 messages 2 unread > > >U 1 torrem...@mail.to Mon Jan 04 17:56 29/1016 Testmail 1 > > U 2 torrem...@mail.to Mon Jan 04 17:56 28/982 Testmail 2 > > > >After the 2nd backup command (same command) it contains: > > > >root@server2:/var/mail# mail -f synctest > >Mail version 8.1.2 01/15/2001. Type ? for help. > >"synctest": 1 message > >> 1 MAILER-DAEMON@ser Wed Jan 06 14:05 13/534 DON'T DELETE THIS > >MESSAGE -- FOLDER INTERNAL DATA > > > >Looks like for some reason the inbox file is reset/recreated? Anybody > >any idea what could cause this behaviour? Running the doveadm backup > >command a 3rd of 4th time does not change the /var/mail/synctest file > >anymore. Also the date/time of the file is not updated anymore > I can't help with your specific problem but you should not use mbox anymore, > especially with replication. > > > >Thanks, > > > >Engelbert > > > >Op 4-1-2021 om 18:25 schreef Engelbert Torremans: > >> > >> All, > >> > >> For the past 2 weeks I have been trying to get dovecot mail backup > >> working between 2 debian 10 machines. > >> > >> Both machines are running the same OS (Debian 10) and configuration > >> wise they are similar (except of course ip addresses, hostnames etc). > >> > >> My "main" machine is called "server" and the 2nd machine is > >"server2". > >> > >> See below for the dovecot -n output on server2. > >> > >> I created a testuser called synctest on both server1 and server2 and > >> have sent a couple (2) email messages to synctest@server. > >> > >> Those testmessages are now present in /var/mail/synctest mbox file on > > > >> server1. > >> > >> When trying to create a backup from server->server2 for user synctest > > > >> I use this command: > >> > >> #doveadm -D -v backup -R -f -u synctest tcp:192.168.3.1:12345 > >> (using something similar from server1 -> server2 like this: #doveadm > >> -D -v backup -f -u synctest tcp:192.168.3.2:12345 has the same > >results > >> btw) > >> > >> The first attempte appears to be working OK but the the 2nd attempt > >> (nothing was changed on server1 before the 2nd attempt) fails with > >> soemthing like: Error: Couldn't delete mailbox INBOX: Permission > >denied > >> > >> Before I can get a succesfull backup again I need to do this (on > >server2): > >> > >> #rm /var/mail/synctest > >> #rm -r ~syncuser/mail/index/INBOX > >> #doveadm mailbox delete -u synctest INBOX > >> (if I don't do the rm /var/mail/synctest before the doveadm mailbox > >> delete command I will also get a: > >> Error: Can't delete mailbox INBOX: Permission denied > >> > >> Anybody any idea what is happening here? Should I enable replicator > >> and/or aggregator? > >> > >> Output of 1st and 2nd dovadm backup attempt is below: > >> > >> root@server2:/home/synctest/mail# doveadm -D -v backup -R -f -u > >> synctest tcp:192.168.3.1:12345 > >> Debug: Loading modules from directory: > >/usr/lib/dovecot/modules/doveadm > >> Debug: Skipping module doveadm_acl_plugin, because dlopen() failed: > >> /usr/lib/dovecot/modules/doveadm/lib10_doveadm_acl_plugin.so: > >> undefined symbol: acl_user_module (this is usually intentional, so > >> just ignore this message) > >> Debug: Skipping module doveadm_expire_plugin, because dlopen() > >failed: > >> /usr/lib/dovecot/modules/doveadm/lib10_doveadm_expire_plugin.so: > >> undefined symbol: expire_set_deinit (this is usually intentional, so > >> just ignore this message) > >> Debug: Skipping module doveadm_quota_plugin, because dlopen() failed: > > > >> /usr/lib/dovecot/modules/doveadm/lib10_doveadm_quota_plugin.so: > >> undefined symbol: quota_user_module (this is usually intentional, so > >> just ignore this message) > >> Debug: Module loaded: > >> /usr/lib/dovecot/modules/doveadm/lib10_doveadm_sieve_plugin.so > >> Debug: Skipping module doveadm_fts_lucene_plugin, because dlopen() > >> failed: > >> /usr/lib/dovecot/modules/doveadm/lib20_doveadm_fts_lucene_plugin.so: > >> undefined symbol: lucene_index_iter_deinit (this is usually > >> intentional, so just ignore this message) > >> Debug: Skipping module doveadm_fts_plugin, because dlopen() failed: > >> /usr/lib/dovecot/modules/doveadm/lib20_doveadm_fts_plugin.so: > >> undefined symbol:
Re: doveadm backup only working once?
On January 6, 2021 2:14:32 PM GMT+01:00, Engelbert Torremans wrote: >All, > >Maybe a relevant piece of additional information that could help in >figurring out what is going wrong here that I forgot to add in my >previous posting. > >After the succesfull first backup execution using: >#doveadm -D -v backup -R -f -u synctest tcp:192.168.3.1:12345 > >as described in detail below the /var/mail/synctest inbox file contains > >this (using mail -f /var/mail/synctest): > >root@mail:/var/mail# mail -f synctest >Mail version 8.1.2 01/15/2001. Type ? for help. >"synctest": 2 messages 2 unread > >U 1 torrem...@mail.to Mon Jan 04 17:56 29/1016 Testmail 1 > U 2 torrem...@mail.to Mon Jan 04 17:56 28/982 Testmail 2 > >After the 2nd backup command (same command) it contains: > >root@server2:/var/mail# mail -f synctest >Mail version 8.1.2 01/15/2001. Type ? for help. >"synctest": 1 message >> 1 MAILER-DAEMON@ser Wed Jan 06 14:05 13/534 DON'T DELETE THIS >MESSAGE -- FOLDER INTERNAL DATA > >Looks like for some reason the inbox file is reset/recreated? Anybody >any idea what could cause this behaviour? Running the doveadm backup >command a 3rd of 4th time does not change the /var/mail/synctest file >anymore. Also the date/time of the file is not updated anymore I can't help with your specific problem but you should not use mbox anymore, especially with replication. > >Thanks, > >Engelbert > >Op 4-1-2021 om 18:25 schreef Engelbert Torremans: >> >> All, >> >> For the past 2 weeks I have been trying to get dovecot mail backup >> working between 2 debian 10 machines. >> >> Both machines are running the same OS (Debian 10) and configuration >> wise they are similar (except of course ip addresses, hostnames etc). >> >> My "main" machine is called "server" and the 2nd machine is >"server2". >> >> See below for the dovecot -n output on server2. >> >> I created a testuser called synctest on both server1 and server2 and >> have sent a couple (2) email messages to synctest@server. >> >> Those testmessages are now present in /var/mail/synctest mbox file on > >> server1. >> >> When trying to create a backup from server->server2 for user synctest > >> I use this command: >> >> #doveadm -D -v backup -R -f -u synctest tcp:192.168.3.1:12345 >> (using something similar from server1 -> server2 like this: #doveadm >> -D -v backup -f -u synctest tcp:192.168.3.2:12345 has the same >results >> btw) >> >> The first attempte appears to be working OK but the the 2nd attempt >> (nothing was changed on server1 before the 2nd attempt) fails with >> soemthing like: Error: Couldn't delete mailbox INBOX: Permission >denied >> >> Before I can get a succesfull backup again I need to do this (on >server2): >> >> #rm /var/mail/synctest >> #rm -r ~syncuser/mail/index/INBOX >> #doveadm mailbox delete -u synctest INBOX >> (if I don't do the rm /var/mail/synctest before the doveadm mailbox >> delete command I will also get a: >> Error: Can't delete mailbox INBOX: Permission denied >> >> Anybody any idea what is happening here? Should I enable replicator >> and/or aggregator? >> >> Output of 1st and 2nd dovadm backup attempt is below: >> >> root@server2:/home/synctest/mail# doveadm -D -v backup -R -f -u >> synctest tcp:192.168.3.1:12345 >> Debug: Loading modules from directory: >/usr/lib/dovecot/modules/doveadm >> Debug: Skipping module doveadm_acl_plugin, because dlopen() failed: >> /usr/lib/dovecot/modules/doveadm/lib10_doveadm_acl_plugin.so: >> undefined symbol: acl_user_module (this is usually intentional, so >> just ignore this message) >> Debug: Skipping module doveadm_expire_plugin, because dlopen() >failed: >> /usr/lib/dovecot/modules/doveadm/lib10_doveadm_expire_plugin.so: >> undefined symbol: expire_set_deinit (this is usually intentional, so >> just ignore this message) >> Debug: Skipping module doveadm_quota_plugin, because dlopen() failed: > >> /usr/lib/dovecot/modules/doveadm/lib10_doveadm_quota_plugin.so: >> undefined symbol: quota_user_module (this is usually intentional, so >> just ignore this message) >> Debug: Module loaded: >> /usr/lib/dovecot/modules/doveadm/lib10_doveadm_sieve_plugin.so >> Debug: Skipping module doveadm_fts_lucene_plugin, because dlopen() >> failed: >> /usr/lib/dovecot/modules/doveadm/lib20_doveadm_fts_lucene_plugin.so: >> undefined symbol: lucene_index_iter_deinit (this is usually >> intentional, so just ignore this message) >> Debug: Skipping module doveadm_fts_plugin, because dlopen() failed: >> /usr/lib/dovecot/modules/doveadm/lib20_doveadm_fts_plugin.so: >> undefined symbol: fts_user_get_language_list (this is usually >> intentional, so just ignore this message) >> Debug: Skipping module doveadm_mail_crypt_plugin, because dlopen() >> failed: >> /usr/lib/dovecot/modules/doveadm/libdoveadm_mail_crypt_plugin.so: >> undefined symbol: mail_crypt_box_get_pvt_digests (this is usually >> intentional, so just ignore this message) >> doveadm(synctest)<13039><>: Debug:
Re: Dovecot v2.3.13 released
> On 06/01/2021 15:37 Juri Haberland wrote: > > > On 04/01/2021 13:02, Aki Tuomi wrote: > > We are pleased to release v2.3.13. Please find it from locations below: > > > > https://dovecot.org/releases/2.3/dovecot-2.3.13.tar.gz > > https://dovecot.org/releases/2.3/dovecot-2.3.13.tar.gz.sig > > Binary packages in https://repo.dovecot.org/ > > Docker images in https://hub.docker.com/r/dovecot/dovecot > > While trying to rebuild packages for Ubuntu Bionic (18.04) for i386 I > noticed that the size and checksum for > dovecot_2.3.13-2+ubuntu18.04.debian.tar.xz was wrong as reported in the > dovecot-Ubuntu_18.04.dsc file as well as the checksum for > dovecot-pigeonhole_2.3.13-2+ubuntu18.04.debian.tar.xz as reported in the > dovecot-pigeonhole-Ubuntu_18.04.dsc file, so I had to manually change > the *.dsc files. > > I had the same problem with the last release 2.3.11.3 so it seems there > is something wrong in your release process of Ubuntu packages. > > > Cheers, > Juri Thanks, we'll take a look. Aki
Re: Dovecot v2.3.13 released
On 04/01/2021 13:02, Aki Tuomi wrote: > We are pleased to release v2.3.13. Please find it from locations below: > > https://dovecot.org/releases/2.3/dovecot-2.3.13.tar.gz > https://dovecot.org/releases/2.3/dovecot-2.3.13.tar.gz.sig > Binary packages in https://repo.dovecot.org/ > Docker images in https://hub.docker.com/r/dovecot/dovecot While trying to rebuild packages for Ubuntu Bionic (18.04) for i386 I noticed that the size and checksum for dovecot_2.3.13-2+ubuntu18.04.debian.tar.xz was wrong as reported in the dovecot-Ubuntu_18.04.dsc file as well as the checksum for dovecot-pigeonhole_2.3.13-2+ubuntu18.04.debian.tar.xz as reported in the dovecot-pigeonhole-Ubuntu_18.04.dsc file, so I had to manually change the *.dsc files. I had the same problem with the last release 2.3.11.3 so it seems there is something wrong in your release process of Ubuntu packages. Cheers, Juri
Ubuntu packages
Hi! Since Ubuntu 20.04 LTS is nowadays available, we have dropped 16.04 support from 2.3.13 as per policy of supporting two latest releases of operating system. Dovecot 2.3.11.3 is latest version we provide packages for 16.04. Please find Ubuntu 20.04 packages at https://repo.dovecot.org/ Kind regards, Aki Tuomi Open-Xchange oy signature.asc Description: OpenPGP digital signature
Re: doveadm backup only working once?
All, Maybe a relevant piece of additional information that could help in figurring out what is going wrong here that I forgot to add in my previous posting. After the succesfull first backup execution using: #doveadm -D -v backup -R -f -u synctest tcp:192.168.3.1:12345 as described in detail below the /var/mail/synctest inbox file contains this (using mail -f /var/mail/synctest): root@mail:/var/mail# mail -f synctest Mail version 8.1.2 01/15/2001. Type ? for help. "synctest": 2 messages 2 unread >U 1 torrem...@mail.to Mon Jan 04 17:56 29/1016 Testmail 1 U 2 torrem...@mail.to Mon Jan 04 17:56 28/982 Testmail 2 After the 2nd backup command (same command) it contains: root@server2:/var/mail# mail -f synctest Mail version 8.1.2 01/15/2001. Type ? for help. "synctest": 1 message > 1 MAILER-DAEMON@ser Wed Jan 06 14:05 13/534 DON'T DELETE THIS MESSAGE -- FOLDER INTERNAL DATA Looks like for some reason the inbox file is reset/recreated? Anybody any idea what could cause this behaviour? Running the doveadm backup command a 3rd of 4th time does not change the /var/mail/synctest file anymore. Also the date/time of the file is not updated anymore Thanks, Engelbert Op 4-1-2021 om 18:25 schreef Engelbert Torremans: All, For the past 2 weeks I have been trying to get dovecot mail backup working between 2 debian 10 machines. Both machines are running the same OS (Debian 10) and configuration wise they are similar (except of course ip addresses, hostnames etc). My "main" machine is called "server" and the 2nd machine is "server2". See below for the dovecot -n output on server2. I created a testuser called synctest on both server1 and server2 and have sent a couple (2) email messages to synctest@server. Those testmessages are now present in /var/mail/synctest mbox file on server1. When trying to create a backup from server->server2 for user synctest I use this command: #doveadm -D -v backup -R -f -u synctest tcp:192.168.3.1:12345 (using something similar from server1 -> server2 like this: #doveadm -D -v backup -f -u synctest tcp:192.168.3.2:12345 has the same results btw) The first attempte appears to be working OK but the the 2nd attempt (nothing was changed on server1 before the 2nd attempt) fails with soemthing like: Error: Couldn't delete mailbox INBOX: Permission denied Before I can get a succesfull backup again I need to do this (on server2): #rm /var/mail/synctest #rm -r ~syncuser/mail/index/INBOX #doveadm mailbox delete -u synctest INBOX (if I don't do the rm /var/mail/synctest before the doveadm mailbox delete command I will also get a: Error: Can't delete mailbox INBOX: Permission denied Anybody any idea what is happening here? Should I enable replicator and/or aggregator? Output of 1st and 2nd dovadm backup attempt is below: root@server2:/home/synctest/mail# doveadm -D -v backup -R -f -u synctest tcp:192.168.3.1:12345 Debug: Loading modules from directory: /usr/lib/dovecot/modules/doveadm Debug: Skipping module doveadm_acl_plugin, because dlopen() failed: /usr/lib/dovecot/modules/doveadm/lib10_doveadm_acl_plugin.so: undefined symbol: acl_user_module (this is usually intentional, so just ignore this message) Debug: Skipping module doveadm_expire_plugin, because dlopen() failed: /usr/lib/dovecot/modules/doveadm/lib10_doveadm_expire_plugin.so: undefined symbol: expire_set_deinit (this is usually intentional, so just ignore this message) Debug: Skipping module doveadm_quota_plugin, because dlopen() failed: /usr/lib/dovecot/modules/doveadm/lib10_doveadm_quota_plugin.so: undefined symbol: quota_user_module (this is usually intentional, so just ignore this message) Debug: Module loaded: /usr/lib/dovecot/modules/doveadm/lib10_doveadm_sieve_plugin.so Debug: Skipping module doveadm_fts_lucene_plugin, because dlopen() failed: /usr/lib/dovecot/modules/doveadm/lib20_doveadm_fts_lucene_plugin.so: undefined symbol: lucene_index_iter_deinit (this is usually intentional, so just ignore this message) Debug: Skipping module doveadm_fts_plugin, because dlopen() failed: /usr/lib/dovecot/modules/doveadm/lib20_doveadm_fts_plugin.so: undefined symbol: fts_user_get_language_list (this is usually intentional, so just ignore this message) Debug: Skipping module doveadm_mail_crypt_plugin, because dlopen() failed: /usr/lib/dovecot/modules/doveadm/libdoveadm_mail_crypt_plugin.so: undefined symbol: mail_crypt_box_get_pvt_digests (this is usually intentional, so just ignore this message) doveadm(synctest)<13039><>: Debug: auth USER input: synctest system_groups_user=synctest uid=1006 gid=100 home=/home/synctest doveadm(synctest): Debug: remote(192.168.3.1:12345): auth USER input: synctest system_groups_user=synctest uid=1006 gid=100 home=/home/synctest doveadm(synctest): Debug: remote(192.168.3.1:12345): Effective uid=1006, gid=100, home=/home/synctest doveadm(synctest): Debug: remote(192.168.3.1:12345): Namespace inbox: type=private,
[Dovecot-news] Ubuntu packages
Hi! Since Ubuntu 20.04 LTS is nowadays available, we have dropped 16.04 support from 2.3.13 as per policy of supporting two latest releases of operating system. Dovecot 2.3.11.3 is latest version we provide packages for 16.04. Please find Ubuntu 20.04 packages at https://repo.dovecot.org/ Kind regards, Aki Tuomi Open-Xchange oy signature.asc Description: OpenPGP digital signature ___ Dovecot-news mailing list Dovecot-news@dovecot.org https://dovecot.org/mailman/listinfo/dovecot-news
Pigeonhole v0.5.13 build fails on OS X 10.11.6
Hi, Dovecot 2.3.13 builds successfully on this old OS X, but pigeonhole v0.5.13fails as below: gcc -DHAVE_CONFIG_H -I. -I../.. -I/usr/local/include/dovecot-I../.. -I../../src/lib-managesieve -fPIE -DPIE -std=gnu99 -g -O2 -Wall -W -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith -Wchar-subscripts -Wformat=2 -Wbad-function-cast -Wno-duplicate-decl-specifier -Wstrict-aliasing=2 -fstack-protector-strong -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -I../.. -MT managesieve_login-client.o -MD -MP -MF .deps/managesieve_login-client.Tpo -c -o managesieve_login-client.o `test -f 'client.c' || echo './'`client.c In file included from client.c:23: ./managesieve-proxy.h:8:15: warning: declaration of 'enum login_proxy_failure_type' will not be visible outside of this function [-Wvisibility] enum login_proxy_failure_type type, ^ client.c:518:3: error: field designator 'proxy_failed' does not refer to any field in type 'struct client_vfuncs' .proxy_failed = managesieve_proxy_failed, ^ 1 warning and 1 error generated. make: *** [managesieve_login-client.o] Error 1 This appears to be related to the change from manage sieve_proxy_ error to manage sieve_proxy_failed. Pigeonhole v0.5.11 builds without problem on the same machine. The warning appears to be related to the lack of a declaration, but I am no expert. The error I have no idea!!! Is this related to my old compiler, or is there an issue here? Can anyone propose a workaround, as I would like to use Dovecot 2.3.13, but will get version mismatch errors if I do not upgrade pigeonhole. Thanks in advance
AW: Dovecot v2.3.13 released
Hey there, do you know anything new here, whether the update is also build for 16.04? Yours sincerely Pascal Rudolf -Ursprüngliche Nachricht- Von: dovecot Im Auftrag von Juri Haberland Gesendet: Mittwoch, 6. Januar 2021 00:13 An: dovecot@dovecot.org Betreff: Re: Dovecot v2.3.13 released On 04/01/2021 13:02, Aki Tuomi wrote: > We are pleased to release v2.3.13. Please find it from locations below: > Binary packages in https://repo.dovecot.org/ Hi Aki, is it on purpose that there is no build for Ubuntu Xenial 16.04 or is it just an oversight? Kind regards, Juri
Re: Imapsieve FLAG cause executes a pipe call twice
On 2021-01-06 12:57, Stephan Bosch wrote: On 24/12/2020 15:06, DocMAX wrote: Dez 24 15:05:32 server dovecot[222484]: imap(docmax)<224089>: Debug: sieve: action pipe: running program: rspam-ham Dez 24 15:05:36 server dovecot[222484]: imap(docmax)<224089>: Debug: sieve: action pipe: running program: rspam-spam I expected to have only ONE pipe when i change flag (in Thunderbird). Instead i get multiple calls. Why is that and how can i fix it? I don't think this is just one event causing several conflicting actions to be performed. I'd say Thunderbird is doing this. You should obtain a rawlog for the IMAP session to see what Thunderbird is doing. is Thunderbird running with trust spamassassin headers ?, if so turn it off :=) scenario i think happen above that users says its spam, but Thunderbird reload msg again and set it to not spam, based on spamassassin headers sorry only a guess
Re: Imapsieve FLAG cause executes a pipe call twice
On 24/12/2020 15:06, DocMAX wrote: Dez 24 15:05:24 server dovecot[222484]: imap(docmax)<224089>: Debug: sieve: action pipe: running program: rspam-spam Dez 24 15:05:24 server dovecot[222484]: imap(docmax)<224089>: Debug: sieve: action pipe: running program: rspam-ham Dez 24 15:05:27 server dovecot[222484]: imap(docmax)<224089>: Debug: sieve: action pipe: running program: rspam-spam Dez 24 15:05:27 server dovecot[222484]: imap(docmax)<224089>: Debug: sieve: action pipe: running program: rspam-spam Dez 24 15:05:32 server dovecot[222484]: imap(docmax)<224089>: Debug: sieve: action pipe: running program: rspam-spam Dez 24 15:05:32 server dovecot[222484]: imap(docmax)<224089>: Debug: sieve: action pipe: running program: rspam-ham Dez 24 15:05:36 server dovecot[222484]: imap(docmax)<224089>: Debug: sieve: action pipe: running program: rspam-spam Dez 24 15:05:36 server dovecot[222484]: imap(docmax)<224089>: Debug: sieve: action pipe: running program: rspam-spam I espected to have only ONE pipe when i change flag (in Thunderbird). Instead i get multiple calls. Why is that and how can i fix it? I don't think this is just one event causing several conflicting actions to be performed. I'd say Thunderbird is doing this. You should obtain a rawlog for the IMAP session to see what Thunderbird is doing. Regards, Stephan.
Re: Dovecot + sis problem
Hi Michal,
On 06.01.21 00:18, Michał Kiljański wrote:
Hi,
My setup is:
mail_attachment_dir = /var/mail/attachments
mail_attachment_hash = %{sha512}
mail_attachment_min_size = 64k
mail_attachment_fs = sis posix
Something works - but I expected that is one instance of file, and this
file is linked to messages. But here in folder I have got this:
sudo ls -la /var/mail/attachments/8b/67/
-rw-rw-rw- 3 buser dovecot 5425280 Jan 5 23:13
8b67b29a73b74ecf48e17e789051602cec13aa78cc01c06c8eee1ca4be7c8e07f700cdc9e9ca0381fa3541bdd4e26289de1d7eee763233dfaa0a200a264e5258-0258913a92f2f45f0d70035f3f08
-rw-rw-rw- 1 cuser dovecot 5425280 Jan 5 23:13
8b67b29a73b74ecf48e17e789051602cec13aa78cc01c06c8eee1ca4be7c8e07f700cdc9e9ca0381fa3541bdd4e26289de1d7eee763233dfaa0a200a264e5258-28571b018ff2f45f0c70035f3f08
-rw-rw-rw- 3 buser dovecot 5425280 Jan 5 23:13
8b67b29a73b74ecf48e17e789051602cec13aa78cc01c06c8eee1ca4be7c8e07f700cdc9e9ca0381fa3541bdd4e26289de1d7eee763233dfaa0a200a264e5258-50315d3a8ef2f45f0a70035f3f08
-rw-rw-rw- 1 auser dovecot 5425280 Jan 5 23:13
8b67b29a73b74ecf48e17e789051602cec13aa78cc01c06c8eee1ca4be7c8e07f700cdc9e9ca0381fa3541bdd4e26289de1d7eee763233dfaa0a200a264e5258-586cdb378ef2f45f0770035f3f08
drwxrwsrwx 2 buser dovecot 4096 Jan 5 23:13 hashes
sudo ls -la /var/mail/attachments/8b/67/hashes/
-rw-rw-rw- 3 buser dovecot 5425280 Jan 5 23:13
8b67b29a73b74ecf48e17e789051602cec13aa78cc01c06c8eee1ca4be7c8e07f700cdc9e9ca0381fa3541bdd4e26289de1d7eee763233dfaa0a200a264e5258
What is wrog? How to setup SIS to get one instance of file?
SIS uses hard links. In your example the attachment in 8b/67/hashes/ is
referenced in 2 other files (aka attached in 2 mails) in the 8b/67/
directory. So the data is stored only once on disk but referenced in 3
directory entries. You can see the refcount in column 3 of ls -l.
Best,
--
Patrick Cernko +49 681 9325 5815
Joint Administration: Information Services and Technology
Max-Planck-Institute für Informatik & Softwaresysteme
smime.p7s
Description: S/MIME Cryptographic Signature
