Re: limit sharing ability to certain users

[Simeon Ott]

Thanks Sami, thanks Aki

I just updated the packages on our testing server and now it works like 
expected.
There are some LDAP tests to come. Are there many productive server out there 
using this repository?

Simeon

> On 8 Aug 2018, at 09:41, Sami Ketola  wrote:
> 
> 
> http://repo.dovecot.org/ 
> 
> Sami
> 
> 
>> On 8 Aug 2018, at 10.27, Simeon Ott > > wrote:
>> 
>> Okay, this seems to be due to the fact that the option “use_globals_only" is 
>> supported only in v2.2.31+
>> We are on Debian jessie with dovecot v2.2.13 – even an upgrade to current 
>> stable stretch won’t help (dovecot v2.2.27). So we will wait until the 
>> packages find their way into the repository.
>> 
>> thanks anyway
>> 
>> 
>>> On 7 Aug 2018, at 13:00, Simeon Ott >> > wrote:
>>> but, did you read my last note anyway?
>>> IMPORTANT NOTE: anyway.. even with this options set (acl and 
>>> acl_globals_only) the user t...@onnet.ch  is still 
>>> able to share its own folders?!



smime.p7s
Description: S/MIME cryptographic signature

Re: Best practices for backing up small mailserver to remote location

[Adi Pircalabu]

On 09-08-2018 10:05, Kenneth Porter wrote:

On 8/7/2018 5:08 PM, Adi Pircalabu wrote:
- Since you're on dynamic IP at home, set up a VPN tunnel using the 
mailserver as server and HTPC as client. OpenVPN is ubiquitous and 
widely supported.

- rsync your mailboxes using the tunnel connection.
This way you can back up your entire server, not only the mailboxes.


Instead of openvpn, I use openssh. Use compression in the ssh tunnel,
not the rsync connection, as rsync compression tends to be buggy and
interrupts the download. I run sshd on a non-standard port to keep my
logs relatively free of script kiddy noise from people looking for an
ssh connection to crack. Run fail2ban to lock out the remaining script
kiddies. Use a client certificate to log in with ssh unprompted,
making it easy to download in a cron job.


There's more than one way to skin a cat :) Moving the ssh port and 
adding fail2ban in the mix is another option. Personally tend to use VPN 
tunnels for dynamic IP clients for various reasons, such as being able 
to lock clients out by revoking keys.


--
Adi Pircalabu

Re: Best practices for backing up small mailserver to remote location

[Kenneth Porter]

On 8/7/2018 5:08 PM, Adi Pircalabu wrote:
- Since you're on dynamic IP at home, set up a VPN tunnel using the 
mailserver as server and HTPC as client. OpenVPN is ubiquitous and 
widely supported.

- rsync your mailboxes using the tunnel connection.
This way you can back up your entire server, not only the mailboxes.


Instead of openvpn, I use openssh. Use compression in the ssh tunnel, 
not the rsync connection, as rsync compression tends to be buggy and 
interrupts the download. I run sshd on a non-standard port to keep my 
logs relatively free of script kiddy noise from people looking for an 
ssh connection to crack. Run fail2ban to lock out the remaining script 
kiddies. Use a client certificate to log in with ssh unprompted, making 
it easy to download in a cron job.


Here's an example of scripting the download. Uncomment the DRYRUN line 
for testing, then comment for production. Add more rsync commands to 
back up different partitions. The --one-file-system prevents rsync from 
trying to back up /dev, /proc, and /sys. The --delete option will remove 
local files that were deleted on the remote server. Use that set of 
options once you're happy that the backup is working right.


#!/bin/sh
#set -e
set -x
#DRYRUN=--dry-run
#RSYNC_OPTIONS="$DRYRUN --one-file-system -avH --delete"
RSYNC_OPTIONS="$DRYRUN --one-file-system -avH"
DEST=/home/rsync/Server1

# Allow one hour so we don't burn up our bandwidth allowance
# from a command error

time timeout 1h \
rsync -e 'ssh -C -p 1234' $RSYNC_OPTIONS example.com:/ ${DEST}/ \
--exclude tmp

# add more rsync commands here for other partitions

Re: Best practices for backing up small mailserver to remote location

[Joseph Tam]

On Wed, 8 Aug 2018, daniel_1...@protonmail.com wrote:


-   rsync


may not be the best option depending on the format of mailboxes.  If
you're using maildir or maildir+ that's fine, but what about mbox or
dbox ?


It depends on the situation.  I can't speak for dbox, but if the mbox
file is not updated, then it's no different than maildir.  (It might
actually be slightly faster as you don't read a lot of metadata for
boxes with many messages.  This is a consideration for Maildir if the
filesystem format handles metadata poorly.)

For mbox where most of the updates occur at the end of the file (i.e.
the latest messages), then you'll have to incur read I/O at the source
to calculate rolling checksums, but only the changed blocks will be
transferred.

The worst situation is a modification at the beginning of a large mbox
(e.g. delete first message), which will trigger a full copy.

So for mostly static mboxes, and moderately sized active mailboxes,
rsync will work fine, especially owing to its simplicity.

Joseph Tam 

Re: Set X-Original-To based an ORCPT?

[Stephan Bosch]

Op 07/08/2018 om 15:29 schreef Tom Sommer:

On 2018-08-07 13:07, Marco Giunta wrote:

Hi,
to get a 'Delivered-to' header based on ORCPT, I wrote a patch
(attached) to force Dovecot lmtp to advertise DSN after a LHLO command.
In this way, Postfix add an ORCPT to the RCTP command
(http://postfix.1071664.n5.nabble.com/pipe-flags-vs-lmtp-td11587.html#a11596). 



Be carefully: in this way DSN notification is broken, but they were
broken in any case at the time I wrote the patch (read the entire post
linked above).

The first patch is for Dovecot 2.2.x: after apply, you cannot disable
the DSN advertisement. The other is for Dovecot 2.3.0: you can
enable/disable the advertisement using the new bool parameter
'lmtp_lhlo_dsn'.


Interesting that support is actually built in, but simply not advertised.

https://github.com/dovecot/core/commit/38f624b427aa8b6fad3765e6efd97c85a7f97a09 



That is for Dovecot to Dovecot proxying. It only recognizes the ORCPT 
parameter. Servers advertising DSN have a responsibility to send the 
required DSN messages, which Dovecot LMTP currently omits and which is 
why it doesn't advertise DSN support.



Maybe there is a plan?


There is some talk on the subject. Main problem is that DSN is not 
documented for LTMP.


Regards,

Stephan.

Re: Message delivered twice caused by an LMTP error "Got unexpected reply" during upgrade to 2.3

[Stephan Bosch]

Hi,


Op 07/08/2018 om 09:35 schreef Gabriele Nencioni:

Hi all,
we are upgrading our dovecot platform from:

# dovecot --version
2.2.15.14 (39f57c379ded+)


Great! A mummy from ancient times.

That is going to make reproducing the circumstances here a bit difficult 
(difficult to get that compiled here anymore). I cannot reproduce 
anything like that so far with current versions.


Can you make a pcap log of the LMTP communication between the two 
Dovecot hosts? That may give me a clue on which side of the 
communication is causing the issue.


Regards,

Stephan.




to

# dovecot --version
2.3.2.1 (0719df592)

Our platform is debian based and it is configured as director and
backend proxy.

We have just upgrade only 4 servers (2 directors and 2 backends) and
when the lmtp traffic flow goes through an upgraded director and a
not-upgraded backend sometimes the following error has been arised:
Aug  6 14:31:28 monti-director07 dovecot: lmtp(13463): Error:
eMFVIKA/aFuXNAAAhXvSMA: Failed to send message to
 at 192.168.72.135:24: Got unexpected reply
(1/1 at 210 ms)
Aug  6 14:31:28 monti-director07 dovecot: lmtp(13463): Error:
eMFVIKA/aFuXNAAAhXvSMA: Failed to send message to
 at 192.168.72.135:24: Got unexpected reply
(1/1 at 210 ms)

where
172.20.44.7   (monti-director07) is a dovecot 2.3.2.1
192.168.72.135 (monti-backend07) is a dovecot 2.2.15.14


When that error occurs an email is delivered twice, as you can see from
the following logs.

On smtp server you can see the temp fail (by the upgraded director
172.20.44.7), retry and delivered (by a not-upgraded director 172.20.44.3):
20180806 14:31:28.772 core context="Temporary_Delivery_Failure",
_fromemail="te...@internalinboundcm.eu",
_toemail="te...@internalinboundcm.eu",
_tos="te...@internalinboundcm.eu", _size="80294", dip=172.20.44.7
dport=24 type=lmtp msg="4.4.0 Remote server not answering (bad reply)"
duration=5 mailfrom=6/6/0/0 rcptto=6/6/0/0 data=6/5/1/0 tls=0/0
20180806 14:32:28.032 core context="Message_Delivered",
_fromemail="te...@internalinboundcm.eu",
_toemail="te...@internalinboundcm.eu",
_tos="te...@internalinboundcm.eu", _size="80294", dip=172.20.44.3
dport=24 type=lmtp msg="2.0.0 
AS1CJtQ/aFsqMAAAj5cnUg Saved" duration=21457 mailfrom=3586/3586/0/0
rcptto=3586/3586/0/0 data=3586/3584/2/0 tls=0/0


and on backend server there are the related two delivered log entries:
Aug  6 14:31:28 monti-backend07 dovecot:
lmtp(te...@internalinboundcm.eu): copy from
: box=INBOX, uid=2727,
msgid=<005b01d42d80$2101fff0$6305ffd0$@internalinboundcm.eu>
Aug  6 14:31:28 monti-backend07 dovecot:
lmtp(te...@internalinboundcm.eu):
f0WZF5c/aFuPdgAAj5cnUg:
msgid=<005b01d42d80$2101fff0$6305ffd0$@internalinboundcm.eu>: saved mail
to INBOX
Aug  6 14:32:28 monti-backend07 dovecot:
lmtp(te...@internalinboundcm.eu): copy from
: box=INBOX, uid=2728,
msgid=<005b01d42d80$2101fff0$6305ffd0$@internalinboundcm.eu>
Aug  6 14:32:28 monti-backend07 dovecot:
lmtp(te...@internalinboundcm.eu):
AS1CJtQ/aFsqMAAAj5cnUg:
msgid=<005b01d42d80$2101fff0$6305ffd0$@internalinboundcm.eu>: saved mail
to INBOX


This is the strace output of dovecot lmtp director process (13463):
13463 1533558688.759362 read(8, "250 2.0.0 
f0WZF5c/aFuPdgAAj5cnUg Saved\r\n", 8012) = 71 <0.28>
13463 1533558688.759493 sendto(14, "<19>Aug  6 14:31:28 dovecot:
lmtp(13463): Error: eMFVIKA/aFuXNAAAhXvSMA: Failed to send message to
 at 192.168.72.135:24: Got unexpected reply
(1/1 at 210 ms)", 188, MSG_NOSIGNAL, NULL, 0) = 188 <0.37>

So it receives the "Saved" message from backend but it arises the "Got
unexpected reply" error anyway.


 From tcpdump we have noticed the QUIT response is missed on lmtp
trasaction after the "Saved" message from backend at DATA stage:
220 monti-backend07.it.dadainternal Dovecot ready.
LHLO monti-director07.it.dadainternal
250-monti-backend07.it.dadainternal
250-8BITMIME
250-ENHANCEDSTATUSCODES
250 PIPELINING
MAIL FROM:
RCPT TO:
DATA
...truncated message


.
250 2.0.0  f0WZF5c/aFuPdgAAj5cnUg Saved


While it should be something like this:

220 monti-backend07.it.dadainternal Dovecot ready.
LHLO monti-director07.it.dadainternal
250-monti-backend07.it.dadainternal
250-8BITMIME
250-ENHANCEDSTATUSCODES
250 PIPELINING
MAIL FROM:
RCPT TO:
DATA
...truncated message


.
250 2.0.0  f0WZF5c/aFuPdgAAj5cnUg Saved
QUIT
221 2.0.0 OK


It follows the both dovecot configurations:

# 2.3.2.1 (0719df592): /etc/dovecot/dovecot.conf
# OS: Linux 4.9.0-7-amd64 x86_64 Debian 9.5
auth_cache_negative_ttl = 0
auth_verbose = yes
auth_worker_max_count = 350
director_mail_servers = 192.168.72.129 192.168.72.130 192.168.72.131
192.168.72.132 192.168.72.133 192.168.72.134 192.168.72.135
192.168.72.136 192.168.72.137 192.168.72.138 192.168.72.139
192.168.72.140 192.168.72.141 192.168.72.142 192.168.72.143
192.168.72.144 192.168.72.145 192.168.72.146 192.168.72.147
192.168.72.148 192.168.72.149
director_servers = 172.20.44.1 172.20.44.2 172.20.44.3 172.20.44.4
172.20.44.5 172.20.44.6 172.20.44.7 172.20.44.8

Re: Set X-Original-To based an ORCPT?

[Tanstaafl]

I really wish  this was foxed. this is the only thing preventing me from
using LMTP...

On Tue Aug 07 2018 09:29:18 GMT-0400 (Eastern Standard Time), Tom Sommer
 wrote:
> On 2018-08-07 13:07, Marco Giunta wrote:
>> Hi,
>> to get a 'Delivered-to' header based on ORCPT, I wrote a patch
>> (attached) to force Dovecot lmtp to advertise DSN after a LHLO command.
>> In this way, Postfix add an ORCPT to the RCTP command
>> (http://postfix.1071664.n5.nabble.com/pipe-flags-vs-lmtp-td11587.html#a11596).
>>
>> Be carefully: in this way DSN notification is broken, but they were
>> broken in any case at the time I wrote the patch (read the entire post
>> linked above).
>>
>> The first patch is for Dovecot 2.2.x: after apply, you cannot disable
>> the DSN advertisement. The other is for Dovecot 2.3.0: you can
>> enable/disable the advertisement using the new bool parameter
>> 'lmtp_lhlo_dsn'.
> 
> Interesting that support is actually built in, but simply not 
> advertised.
> 
> https://github.com/dovecot/core/commit/38f624b427aa8b6fad3765e6efd97c85a7f97a09
> 
> Maybe there is a plan?
> 
> --
> Tom
> 

Re: dovecot Panic: file mail-index-sync-update.c: line 1013

[Aki Tuomi]

This has been fixed on later release. You are using very old version.


---Aki TuomiDovecot oy
 Original message From: Eugen I  Date: 
08/08/2018  15:12  (GMT+02:00) To: dovecot@dovecot.org Subject: dovecot Panic: 
file mail-index-sync-update.c: line 1013 
An email came to several users but one user didn't receive it and we got 'Mail 
delivery failed' message.

As I see from the log below, there were broken index file. 
Then dovecot repaired that index and we got the error:
Panic: file mail-index-sync-update.c: line 1013 (mail_index_sync_map): 
assertion failed: (map->hdr.indexid == index->indexid || 
map->hdr.indexid == 0)

It was one-time error and it has not reappeared yet.
At the moment the user receives emails successfully  (in .Queue.A_Sup.group_05 
as well).

It is supposed that Dovecot had to repair index file and put the email in 
mnt/mail//user05/Maildir/.Queue.A_Sup.group_05/ directory but it didn't.Is 
there something wrong with Dovecot?

Thanks.
---
Operating system: Linux Centos 7   3.10.0-862.3.2.el7.x86_64 #1 SMP Mon May 21 
23:36:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
rpm -qa |grep dovecot
dovecot-pigeonhole-2.2.10-8.el7.x86_64
dovecot-2.2.10-8.el7.x86_64

dovecot.log output
-
Aug 06 23:19:24 lda: Debug: Loading modules from directory: 
/usr/lib64/dovecotAug 06 23:19:24 lda: Debug: Module loaded: 
/usr/lib64/dovecot/lib90_sieve_plugin.so
Aug 06 23:19:24 lda(user05): Debug: Effective uid=10492, gid=10001, 
home=/mnt/mail/user05
Aug 06 23:19:24 lda(user05): Debug: Namespace inbox: type=private, prefix=, 
sep=, inbox=yes, hidden=no, list=yes, subscriptions=yes 
location=maildir:/mnt/mail//user05/Maildir:INBOX=/mnt/mail//user05/Maildir
Aug 06 23:19:24 lda(user05): Debug: maildir++: root=/mnt/mail//user05/Maildir, 
index=, indexpvt=, control=, inbox=/mnt/mail//user05/Maildir, alt=
Aug 06 23:19:24 lda(user05): Debug: userdb lookup skipped, username taken from 
USER environment
Aug 06 23:19:24 lda(user05): Debug: none: root=, index=, indexpvt=, control=, 
inbox=, alt=
Aug 06 23:19:24 lda(user05): Debug: Destination address: use...@imap.po.com 
(source: user@hostname)
Aug 06 23:19:24 lda(user05): Debug: sieve: Pigeonhole version 0.4.2 initializing
Aug 06 23:19:24 lda(user05): Debug: sieve: include: sieve_global_dir is not 
set; it is currently not possible to include `:global' scripts.
Aug 06 23:19:24 lda(user05): Debug: sieve: executed before user's personal 
Sieve script(1): /etc/dovecot/sieve/before/priority_colors.sieve
Aug 06 23:19:24 lda(user05): Debug: sieve: using the following location for 
user's Sieve script: /mnt/mail//user05/.dovecot.sieve;name=main script
Aug 06 23:19:24 lda(user05): Debug: sieve: executed after user's Sieve 
script(3): /etc/dovecot/sieve/after/spam.sieve
Aug 06 23:19:24 lda(user05): Debug: sieve: opening script 1 of 3 from 
/etc/dovecot/sieve/before/priority_colors.sieve
Aug 06 23:19:24 lda(user05): Debug: sieve: loading script 
/etc/dovecot/sieve/before/priority_colors.sieve
Aug 06 23:19:24 lda(user05): Debug: sieve: script binary 
/etc/dovecot/sieve/before/priority_colors.svbin successfully loaded
Aug 06 23:19:24 lda(user05): Debug: sieve: binary save: not saving binary 
/etc/dovecot/sieve/before/priority_colors.svbin, because it is already stored
Aug 06 23:19:24 lda(user05): Debug: sieve: executing script from 
/etc/dovecot/sieve/before/priority_colors.svbin
Aug 06 23:19:24 lda(user05): Debug: sieve: opening script 2 of 3 from 
/mnt/mail//user05/.dovecot.sieve;name=main script
Aug 06 23:19:24 lda(user05): Debug: sieve: loading script 
/mnt/mail//user05/.dovecot.sieve;name=main script
Aug 06 23:19:24 lda(user05): Debug: sieve: script binary 
/mnt/mail//user05/.dovecot.svbin successfully loaded
Aug 06 23:19:24 lda(user05): Debug: sieve: binary save: not saving binary 
/mnt/mail//user05/.dovecot.svbin, because it is already stored
Aug 06 23:19:24 lda(user05): Debug: sieve: executing script from 
/mnt/mail//user05/.dovecot.svbin
Aug 06 23:19:24 lda(user05): Error: Index file 
/mnt/mail//user05/Maildir/.Queue.A_Sup.group_05/dovecot.index: indexid changed: 
1533501509 -> 1464071305
Aug 06 23:19:24 lda(user05): Error: Corrupted transaction log file 
/mnt/mail//user05/Maildir/.Queue.A_Sup.group_05/dovecot.index.log seq 3: 
indexid changed: 1533501509 -> 1464071305 (sync_offset=168)
Aug 06 23:19:24 lda(user05): Error: Transaction log file 
/mnt/mail//user05/Maildir/.Queue.A_Sup.group_05/dovecot.index.log: marked 
corrupted
Aug 06 23:19:24 lda: Debug: Loading modules from directory: /usr/lib64/dovecot
Aug 06 23:19:24 lda(user05): Error: Corrupted index file 
/mnt/mail//user05/Maildir/.Queue.A_Sup.group_05/dovecot.index: messages_count 
too large (2915 > 85)
Aug 06 23:19:24 lda(user05): Warning: fscking index file 
/mnt/mail//user05/Maildir/.Queue.A_Sup.group_05/dovecot.index
Aug 06 23:19:24 lda(user05): Error: Corrupted index file 
/mnt/mail//user05/Maildir/.Queue.A_Sup.group_05/dovecot.index: messages_count 
too large (2915 > 85)

dovecot Panic: file mail-index-sync-update.c: line 1013

[Eugen I]

An email came to several users but one user didn't receive it and we got
'Mail delivery failed' message.

As I see from the log below, there were broken index file.
Then dovecot repaired that index and we got the error:
Panic: file mail-index-sync-update.c: line 1013 (mail_index_sync_map):
assertion failed: (map->hdr.indexid == index->indexid || map->hdr.indexid
== 0)

It was one-time error and it has not reappeared yet.
At the moment the user receives emails successfully  (in
.Queue.A_Sup.group_05 as well).

It is supposed that Dovecot had to repair index file and put the email in
mnt/mail//user05/Maildir/.Queue.A_Sup.group_05/ directory but it didn't.
Is there something wrong with Dovecot?

Thanks.

---
Operating system: Linux Centos 7   3.10.0-862.3.2.el7.x86_64 #1 SMP Mon May
21 23:36:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

rpm -qa |grep dovecot
dovecot-pigeonhole-2.2.10-8.el7.x86_64
dovecot-2.2.10-8.el7.x86_64

dovecot.log output
-
Aug 06 23:19:24 lda: Debug: Loading modules from directory:
/usr/lib64/dovecot
Aug 06 23:19:24 lda: Debug: Module loaded:
/usr/lib64/dovecot/lib90_sieve_plugin.so
Aug 06 23:19:24 lda(user05): Debug: Effective uid=10492, gid=10001,
home=/mnt/mail/user05
Aug 06 23:19:24 lda(user05): Debug: Namespace inbox: type=private, prefix=,
sep=, inbox=yes, hidden=no, list=yes, subscriptions=yes
location=maildir:/mnt/mail//user05/Maildir:INBOX=/mnt/mail//user05/Maildir
Aug 06 23:19:24 lda(user05): Debug: maildir++:
root=/mnt/mail//user05/Maildir, index=, indexpvt=, control=,
inbox=/mnt/mail//user05/Maildir, alt=
Aug 06 23:19:24 lda(user05): Debug: userdb lookup skipped, username taken
from USER environment
Aug 06 23:19:24 lda(user05): Debug: none: root=, index=, indexpvt=,
control=, inbox=, alt=
Aug 06 23:19:24 lda(user05): Debug: Destination address: use...@imap.po.com
(source: user@hostname)
Aug 06 23:19:24 lda(user05): Debug: sieve: Pigeonhole version 0.4.2
initializing
Aug 06 23:19:24 lda(user05): Debug: sieve: include: sieve_global_dir is not
set; it is currently not possible to include `:global' scripts.
Aug 06 23:19:24 lda(user05): Debug: sieve: executed before user's personal
Sieve script(1): /etc/dovecot/sieve/before/priority_colors.sieve
Aug 06 23:19:24 lda(user05): Debug: sieve: using the following location for
user's Sieve script: /mnt/mail//user05/.dovecot.sieve;name=main script
Aug 06 23:19:24 lda(user05): Debug: sieve: executed after user's Sieve
script(3): /etc/dovecot/sieve/after/spam.sieve
Aug 06 23:19:24 lda(user05): Debug: sieve: opening script 1 of 3 from
/etc/dovecot/sieve/before/priority_colors.sieve
Aug 06 23:19:24 lda(user05): Debug: sieve: loading script
/etc/dovecot/sieve/before/priority_colors.sieve
Aug 06 23:19:24 lda(user05): Debug: sieve: script binary
/etc/dovecot/sieve/before/priority_colors.svbin successfully loaded
Aug 06 23:19:24 lda(user05): Debug: sieve: binary save: not saving binary
/etc/dovecot/sieve/before/priority_colors.svbin, because it is already
stored
Aug 06 23:19:24 lda(user05): Debug: sieve: executing script from
/etc/dovecot/sieve/before/priority_colors.svbin
Aug 06 23:19:24 lda(user05): Debug: sieve: opening script 2 of 3 from
/mnt/mail//user05/.dovecot.sieve;name=main script
Aug 06 23:19:24 lda(user05): Debug: sieve: loading script
/mnt/mail//user05/.dovecot.sieve;name=main script
Aug 06 23:19:24 lda(user05): Debug: sieve: script binary
/mnt/mail//user05/.dovecot.svbin successfully loaded
Aug 06 23:19:24 lda(user05): Debug: sieve: binary save: not saving binary
/mnt/mail//user05/.dovecot.svbin, because it is already stored
Aug 06 23:19:24 lda(user05): Debug: sieve: executing script from
/mnt/mail//user05/.dovecot.svbin
Aug 06 23:19:24 lda(user05): Error: Index file
/mnt/mail//user05/Maildir/.Queue.A_Sup.group_05/dovecot.index: indexid
changed: 1533501509 -> 1464071305
Aug 06 23:19:24 lda(user05): Error: Corrupted transaction log file
/mnt/mail//user05/Maildir/.Queue.A_Sup.group_05/dovecot.index.log seq 3:
indexid changed: 1533501509 -> 1464071305 (sync_offset=168)
Aug 06 23:19:24 lda(user05): Error: Transaction log file
/mnt/mail//user05/Maildir/.Queue.A_Sup.group_05/dovecot.index.log: marked
corrupted
Aug 06 23:19:24 lda: Debug: Loading modules from directory:
/usr/lib64/dovecot
Aug 06 23:19:24 lda(user05): Error: Corrupted index file
/mnt/mail//user05/Maildir/.Queue.A_Sup.group_05/dovecot.index:
messages_count too large (2915 > 85)
Aug 06 23:19:24 lda(user05): Warning: fscking index file
/mnt/mail//user05/Maildir/.Queue.A_Sup.group_05/dovecot.index
Aug 06 23:19:24 lda(user05): Error: Corrupted index file
/mnt/mail//user05/Maildir/.Queue.A_Sup.group_05/dovecot.index:
messages_count too large (2915 > 85)
Aug 06 23:19:24 lda(user05): Warning: fscking index file
/mnt/mail//user05/Maildir/.Queue.A_Sup.group_05/dovecot.index
Aug 06 23:19:24 lda(user05): Error: Fixed index file
/mnt/mail//user05/Maildir/.Queue.A_Sup.group_05/dovecot.index: log_file_seq
670 -> 2
Aug 06 23:19:24 lda(user05): Error: Fixed index file

Re: Best practices for backing up small mailserver to remote location

[daniel_1983]

‐‐‐ Original Message ‐‐‐
On August 8, 2018 1:08 AM, Adi Pircalabu  wrote:

> -   rsync

may not be the best option depending on the format of mailboxes. If you're 
using maildir or maildir+ that's fine, but what about mbox or dbox ?

Re: Reproducible SIGSEGV when Dovecot 2.3 compiled against glibc-2.28

[Aki Tuomi]

On 08.08.2018 10:55, Reuben Farrelly wrote:
>
> On 8/08/2018 5:29 pm, Thore Bödecker wrote:
>> Hey,
>>
>> you mentioned that dovecot builds fine, but does "make check" also
>> complete successfully with a glibc-2.28 build on a glibc-2.28 system?
>>
>> We have been seeing segfaults during "make check" and it seems the
>> following
>> patch was able to make the testsuite run successfully.
> >
>> Just out of curiosity, could you try this patch and see if this fixes
>> the issues you're experiencing?
>>
>>
>> include-crypt-h.patch:
>> 8<
>> diff -up dovecot-2.3.0.1/src/auth/mycrypt.c.libxcrypt
>> dovecot-2.3.0.1/src/auth/mycrypt.c
>> --- dovecot-2.3.0.1/src/auth/mycrypt.c.libxcrypt   2018-02-28
>> 15:28:58.0 +0100
>> +++ dovecot-2.3.0.1/src/auth/mycrypt.c 2018-03-27 10:57:38.447769201
>> +0200
>> @@ -14,6 +14,7 @@
>>   #  define _XPG6 /* Some Solaris versions require this, some break
>> with this */
>>   #endif
>>   #include 
>> +#include 
>>
>>   #include "mycrypt.h"
>>
>> >8
>
> Ok, wellafter running 'make check' I also saw a failure due to a
> segfault.  It's the same crash Thore is seeing:
>
> /bin/sh ../../libtool  --tag=CC   --mode=link x86_64-pc-linux-gnu-gcc
> -std=gnu99 -O0 -g -pipe -march=native -mtune=native -ggdb
> -fstack-protector-strong -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2
> -mfunction-return=thunk -mindirect-branch=thunk -Wall -W
> -Wmissing-prototypes -Wmissing-declarations -Wpointer-arith
> -Wchar-subscripts -Wformat=2 -Wbad-function-cast -fno-builtin-strftime
> -Wstrict-aliasing=2   -module -avoid-version  -Wl,-O1 -Wl,--as-needed -o
> libauthdb_imap.la -rpath /usr/lib64/dovecot/auth
> libauthdb_imap_la-passdb-imap.lo ../lib-imap-client/libimap_client.la
> ../../src/lib-dovecot/libdovecot.la -export-dynamic -ldl
> libtool: link: x86_64-pc-linux-gnu-gcc -shared  -fPIC -DPIC
> .libs/libauthdb_imap_la-passdb-imap.o  -Wl,--whole-archive
> ../lib-imap-client/.libs/libimap_client.a -Wl,--no-whole-archive
> -Wl,-rpath
> -Wl,/home/portage/portage/net-mail/dovecot-_p20180807/work/dovecot-_p20180807/src/lib-dovecot/.libs
> -Wl,-rpath -Wl,/usr/lib64/dovecot -Wl,--as-needed
> ../../src/lib-dovecot/.libs/libdovecot.so -ldl  -O0 -g -march=native
> -mtune=native -ggdb -fstack-protector-strong -mfunction-return=thunk
> -mindirect-branch=thunk -Wl,-O1   -Wl,-soname -Wl,libauthdb_imap.so -o
> .libs/libauthdb_imap.so
> libtool: link: ( cd ".libs" && rm -f "libauthdb_imap.la" && ln -s
> "../libauthdb_imap.la" "libauthdb_imap.la" )
> make  check-local
> make[3]: Entering directory
> '/home/portage/portage/net-mail/dovecot-_p20180807/work/dovecot-_p20180807/src/auth'
> for bin in test-libpassword test-auth-cache test-auth; do \
>   if !  ./$bin; then exit 1; fi; \
> done
> /bin/sh: line 1: 31821 Segmentation fault  ./$bin
> make[3]: *** [Makefile:1924: check-local] Error 1
> make[3]: Leaving directory
> '/home/portage/portage/net-mail/dovecot-_p20180807/work/dovecot-_p20180807/src/auth'
> make[2]: *** [Makefile:1579: check-am] Error 2
>
>
> However by applying the patch to include crypt.h (as above) it not
> only fixed the make test but also has fixed the glibc runtime problem
> too.
>
> In other words - rebuild on glibc-2.28 just now and executed on
> glibc-2.28 based system resulted in a successful and usable auth binary.
>
> Thanks Thore!
>
> Reuben
>

I can also confirm that the patch fixes things, thank you!

Aki

Error: connect(ipc-proxy) failed: Permission denied

[MAREN ZUBIZARRETA]

Hello:

We have got 2 directors and three backend mailbox servers.
I get the following error " Error: connect(ipc-proxy) failed: Permission 
denied".

I have read the article 
https://www.dovecot.org/list/dovecot/2012-August/137349.html
and we have done as signaled in the two director servers with no success,

So, we have tried now to set it like this:
service ipc {
  unix_listener ipc {
user = dovecot # This is already the default in v2.3.1+
group =
mode = 0777
 }
}
that cause the socket to have full permissions:
srwxrwxrwx 1 dovecot root 0 ago  8 10:00 /var/run/dovecot/ipc

but even so,  I still get the same behaviour.

And when you try "doveadm director kick user" , nothing happens

Can anyone give me any hint.

Thanks a lot in advance

Maren Zubizarreta

Sistemen Analista / Analista de Sistemas
maren.zubizarr...@ehu.es
94 601 8389

IKT GERENTEORDETZA/VICEGERENCIA TIC
UPV/EHU
Barrio Sarriena,s/n | 48940 LEIOA
T.: +34 946012000 | F.: +34 946012200
www.ehu.es

[http://www.unibertsitate-hedakuntza.ehu.es/p268-content/es/contenidos/informacion/manual_id_corp/es_manual/images/logo-firma-corporativa.jpg]


ERNE! Baliteke mezu honen zatiren bat edo mezu osoa legez babestuta egotea. 
Mezuak badu bere hartzailea. Okerreko helbidera heldu bada (helbidea gaizki 
idatzi, transmisioak huts egin) eman abisu igorleari, korreo honi erantzunda. 
Kontuz! Mezua ez bada zuretzat, ez erabili, ez zabaldu beste inori, ez kopiatu 
eta ez baliatu.
¡ATENCIÓN! Este mensaje contiene información privilegiada o confidencial a la 
que sólo tiene derecho a acceder el destinatario. Si usted lo recibe por error 
le agradeceríamos que no hiciera uso de la información y que se pusiese en 
contacto con el remitente.
[http://www.unibertsitate-hedakuntza.ehu.es/p077-9030/es/contenidos/informacion/manual_id_corp/es_manual/images/recicla_firma_email_upv.gif]

E-mail hau inprimatu baino lehen egiaztatu inprimatzeko beharra.
Antes de imprimir este e-mail piense bien si es necesario hacerlo.

Re: Reproducible SIGSEGV when Dovecot 2.3 compiled against glibc-2.28

[Reuben Farrelly]

On 8/08/2018 5:29 pm, Thore Bödecker wrote:

Hey,

you mentioned that dovecot builds fine, but does "make check" also
complete successfully with a glibc-2.28 build on a glibc-2.28 system?

We have been seeing segfaults during "make check" and it seems the following
patch was able to make the testsuite run successfully.

>

Just out of curiosity, could you try this patch and see if this fixes
the issues you're experiencing?


include-crypt-h.patch:
8<
diff -up dovecot-2.3.0.1/src/auth/mycrypt.c.libxcrypt 
dovecot-2.3.0.1/src/auth/mycrypt.c
--- dovecot-2.3.0.1/src/auth/mycrypt.c.libxcrypt   2018-02-28 
15:28:58.0 +0100
+++ dovecot-2.3.0.1/src/auth/mycrypt.c 2018-03-27 10:57:38.447769201 +0200
@@ -14,6 +14,7 @@
  #  define _XPG6 /* Some Solaris versions require this, some break with this */
  #endif
  #include 
+#include 

  #include "mycrypt.h"

>8


Ok, wellafter running 'make check' I also saw a failure due to a 
segfault.  It's the same crash Thore is seeing:


/bin/sh ../../libtool  --tag=CC   --mode=link x86_64-pc-linux-gnu-gcc
-std=gnu99 -O0 -g -pipe -march=native -mtune=native -ggdb
-fstack-protector-strong -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2
-mfunction-return=thunk -mindirect-branch=thunk -Wall -W
-Wmissing-prototypes -Wmissing-declarations -Wpointer-arith
-Wchar-subscripts -Wformat=2 -Wbad-function-cast -fno-builtin-strftime
-Wstrict-aliasing=2   -module -avoid-version  -Wl,-O1 -Wl,--as-needed -o
libauthdb_imap.la -rpath /usr/lib64/dovecot/auth
libauthdb_imap_la-passdb-imap.lo ../lib-imap-client/libimap_client.la
../../src/lib-dovecot/libdovecot.la -export-dynamic -ldl
libtool: link: x86_64-pc-linux-gnu-gcc -shared  -fPIC -DPIC
.libs/libauthdb_imap_la-passdb-imap.o  -Wl,--whole-archive
../lib-imap-client/.libs/libimap_client.a -Wl,--no-whole-archive 
-Wl,-rpath 
-Wl,/home/portage/portage/net-mail/dovecot-_p20180807/work/dovecot-_p20180807/src/lib-dovecot/.libs

-Wl,-rpath -Wl,/usr/lib64/dovecot -Wl,--as-needed
../../src/lib-dovecot/.libs/libdovecot.so -ldl  -O0 -g -march=native
-mtune=native -ggdb -fstack-protector-strong -mfunction-return=thunk
-mindirect-branch=thunk -Wl,-O1   -Wl,-soname -Wl,libauthdb_imap.so -o
.libs/libauthdb_imap.so
libtool: link: ( cd ".libs" && rm -f "libauthdb_imap.la" && ln -s
"../libauthdb_imap.la" "libauthdb_imap.la" )
make  check-local
make[3]: Entering directory 
'/home/portage/portage/net-mail/dovecot-_p20180807/work/dovecot-_p20180807/src/auth'

for bin in test-libpassword test-auth-cache test-auth; do \
  if !  ./$bin; then exit 1; fi; \
done
/bin/sh: line 1: 31821 Segmentation fault  ./$bin
make[3]: *** [Makefile:1924: check-local] Error 1
make[3]: Leaving directory 
'/home/portage/portage/net-mail/dovecot-_p20180807/work/dovecot-_p20180807/src/auth'

make[2]: *** [Makefile:1579: check-am] Error 2


However by applying the patch to include crypt.h (as above) it not only 
fixed the make test but also has fixed the glibc runtime problem too.


In other words - rebuild on glibc-2.28 just now and executed on 
glibc-2.28 based system resulted in a successful and usable auth binary.


Thanks Thore!

Reuben

Re: limit sharing ability to certain users

[Sami Ketola]

http://repo.dovecot.org/ 

Sami


> On 8 Aug 2018, at 10.27, Simeon Ott  wrote:
> 
> Okay, this seems to be due to the fact that the option “use_globals_only" is 
> supported only in v2.2.31+
> We are on Debian jessie with dovecot v2.2.13 – even an upgrade to current 
> stable stretch won’t help (dovecot v2.2.27). So we will wait until the 
> packages find their way into the repository.
> 
> thanks anyway
> 
> 
>> On 7 Aug 2018, at 13:00, Simeon Ott > > wrote:
>> but, did you read my last note anyway?
>> IMPORTANT NOTE: anyway.. even with this options set (acl and 
>> acl_globals_only) the user t...@onnet.ch  is still 
>> able to share its own folders?!
>> 
>> root@buserver:/etc/dovecot# doveadm user t...@onnet.ch 
>> fieldvalue
>> uid  5000
>> gid  5000
>> home /var/spool/postfix/virtual/onnet.ch/test/ 
>> mail maildir:~/Maildir
>> quota_rule   *:bytes=1073741824
>> acl  vfile:/etc/dovecot/dovecot-acl
>> acl_globals_only yes
>> 
>> root@buserver:/etc/dovecot# telnet localhost 143
>> Trying ::1...
>> Connected to localhost.
>> Escape character is '^]'.
>> * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE 
>> AUTH=PLAIN AUTH=LOGIN] Dovecot ready.
>> . login t...@onnet.ch  *
>> . OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE 
>> SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT 
>> MULTIAPPEND URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS 
>> LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN 
>> CONTEXT=SEARCH LIST-STATUS SPECIAL-USE BINARY MOVE QUOTA ACL RIGHTS=texk] 
>> Logged in
>> . SETACL Inbox te...@onnet.ch  lrwstipekxa
>> . OK Setacl complete.
>> . GETACL Inbox
>> * ACL Inbox te...@onnet.ch  akxeilprwtscd 
>> t...@onnet.ch  lrwstipekxacd
>> . OK Getacl completed.
> 

Re: Reproducible SIGSEGV when Dovecot 2.3 compiled against glibc-2.28

[Thore Bödecker]

Hey,

you mentioned that dovecot builds fine, but does "make check" also
complete successfully with a glibc-2.28 build on a glibc-2.28 system?

We have been seeing segfaults during "make check" and it seems the following
patch was able to make the testsuite run successfully.

Just out of curiosity, could you try this patch and see if this fixes
the issues you're experiencing?


include-crypt-h.patch:
8<
diff -up dovecot-2.3.0.1/src/auth/mycrypt.c.libxcrypt 
dovecot-2.3.0.1/src/auth/mycrypt.c
--- dovecot-2.3.0.1/src/auth/mycrypt.c.libxcrypt   2018-02-28 
15:28:58.0 +0100
+++ dovecot-2.3.0.1/src/auth/mycrypt.c 2018-03-27 10:57:38.447769201 +0200
@@ -14,6 +14,7 @@
 #  define _XPG6 /* Some Solaris versions require this, some break with this */
 #endif
 #include 
+#include 

 #include "mycrypt.h"

>8


Cheers,
Thore

PS: Sorry Reuben for duplicate mail, forgot to Cc the list...

-- 
Thore Bödecker

GPG ID: 0xD622431AF8DB80F3
GPG FP: 0F96 559D 3556 24FC 2226  A864 D622 431A F8DB 80F3


signature.asc
Description: PGP signature

Re: limit sharing ability to certain users

[Simeon Ott]

Okay, this seems to be due to the fact that the option “use_globals_only" is 
supported only in v2.2.31+
We are on Debian jessie with dovecot v2.2.13 – even an upgrade to current 
stable stretch won’t help (dovecot v2.2.27). So we will wait until the packages 
find their way into the repository.

thanks anyway


> On 7 Aug 2018, at 13:00, Simeon Ott  wrote:
> but, did you read my last note anyway?
> IMPORTANT NOTE: anyway.. even with this options set (acl and 
> acl_globals_only) the user t...@onnet.ch  is still able 
> to share its own folders?!
> 
> root@buserver:/etc/dovecot# doveadm user t...@onnet.ch 
> field value
> uid   5000
> gid   5000
> home  /var/spool/postfix/virtual/onnet.ch/test/ 
> mail  maildir:~/Maildir
> quota_rule*:bytes=1073741824
> acl   vfile:/etc/dovecot/dovecot-acl
> acl_globals_only  yes
> 
> root@buserver:/etc/dovecot# telnet localhost 143
> Trying ::1...
> Connected to localhost.
> Escape character is '^]'.
> * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE 
> AUTH=PLAIN AUTH=LOGIN] Dovecot ready.
> . login t...@onnet.ch  *
> . OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE 
> SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS THREAD=ORDEREDSUBJECT 
> MULTIAPPEND URL-PARTIAL CATENATE UNSELECT CHILDREN NAMESPACE UIDPLUS 
> LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN 
> CONTEXT=SEARCH LIST-STATUS SPECIAL-USE BINARY MOVE QUOTA ACL RIGHTS=texk] 
> Logged in
> . SETACL Inbox te...@onnet.ch  lrwstipekxa
> . OK Setacl complete.
> . GETACL Inbox
> * ACL Inbox te...@onnet.ch  akxeilprwtscd 
> t...@onnet.ch  lrwstipekxacd
> . OK Getacl completed.



smime.p7s
Description: S/MIME cryptographic signature

Re: Reproducible SIGSEGV when Dovecot 2.3 compiled against glibc-2.28

[Aki Tuomi]

Was able to find a way to get glibc-2.28 and it seems that they have
changed how crypt return value behaves.

I am not sure if this is intentional or not, but it appears that the
return value becomes invalidated as soon as function ends. Dovecot calls
crypt inside mycrypt. While in mycrypt, the pointer is valid. Once
mycrypt returns, the pointer suddenly becomes invalidated and causes crash.

This can be fixed by duplicating the value before return, but I am not
sure if this is the correct way to deal with this or not, you should
probably open issue with glibc developers.

Aki


On 08.08.2018 09:42, Reuben Farrelly wrote:
> Hi,
>
> The link to the release notes seems should have an 'l' on the end:
>
> Try: https://www.sourceware.org/ml/libc-alpha/2018-08/msg3.html
>
> This with gdb:
>
> thunderstorm /usr/src/dovecot/dovecot-2.3/src/auth # gdb
> /root/dovecot-auth-crash/auth /root/dovecot-auth-crash/core.auth.29667
> GNU gdb (Gentoo 8.1.1 p1) 8.1.1
> Copyright (C) 2018 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> 
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show
> copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-pc-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> .
> Find the GDB manual and other documentation resources online at:
> .
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from /root/dovecot-auth-crash/auth...done.
>
> warning: exec file is newer than core file.
> [New LWP 29667]
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> Core was generated by `dovecot/auth'.
> Program terminated with signal SIGSEGV, Segmentation fault.
> #0  __strcmp_sse2_unaligned () at
> ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:31
> 31  ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S: No such
> file or directory.
> (gdb) bt full
> #0  __strcmp_sse2_unaligned () at
> ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:31
> No locals.
> #1  0x562d7a9d8dcf in password_scheme_register_crypt () at
> password-scheme-crypt.c:191
>     i = 0
>     crypted = 0xf6e4b200  address 0xf6e4b200>
>     __func__ = 
> #2  0x562d7a9d87cb in password_schemes_init () at
> password-scheme.c:874
>     i = 27
> #3  0x562d7a9a082a in main_preinit () at main.c:185
>     mod_set = {abi_version = 0xf74856c0  memory at address 0xf74856c0>,
>   binary_name = 0x6f6c0d52e61baf00  memory at address 0x6f6c0d52e61baf00>,
>   setting_name = 0x7fa9f6e97011 <__x86_return_thunk+5>
> "\363\220\017\256\350\353\371H\215d$\b\303\350\a",
>   filter_callback = 0x7fa9f6ecd029 ,
> filter_context = 0x7fa9f6e97011 <__x86_return_thunk+5>,
>   require_init_funcs = false, debug = false,
> ignore_dlopen_errors = false, ignore_missing = false}
>     services = 0x562d7b4d9fa0
> #4  0x562d7a9a0ef5 in main (argc=1, argv=0x562d7b4d9ae0) at
> main.c:392
>     c = -1
> (gdb) p sample[i].key
> No symbol "i" in current context.
> (gdb) p sample[i].salt
> No symbol "i" in current context.
> (gdb)
>
> However:
>
> (gdb) p sample[0].key
> $1 = 0x562d7a9f2f1e "08/15!test~4711"
> (gdb) p sample[1].key
> $2 = 0x562d7a9f2f1e "08/15!test~4711"
> (gdb) p sample[2].key
> $3 = 0x562d7a9f2f1e "08/15!test~4711"
> (gdb) p sample[0].salt
> $4 = 0x562d7a9f2f2e "JB"
> (gdb) p sample[1].salt
> $5 = 0x562d7a9f2f40 "$5$rounds=1000$0123456789abcdef"
> (gdb) p sample[2].salt
> $6 = 0x562d7a9f2fb0 "$6$rounds=1000$0123456789abcdef"
> (gdb)
>
>
> (Different core file to earlier but the trace looks the same)
>
> I haven't experienced any problems with any other apps (yet).
>
> Thanks,
> Reuben
>
>
> On 8/08/2018 4:13 pm, Aki Tuomi wrote:
>> Hi!
>>
>> Thank you for the report, few points though:
>>
>>   - The link you provided is broken
>>
>>   - getting glibc-2.28 prebuilt seems to be bit problematic, and what I
>> read from their changelog, the crypt function should work as normal.
>> That said, it would be somewhat helpful if you could use gdb to find out
>> what was passed to crypt
>>
>> p sample[i].key
>> p sample[i].salt
>>
>> the return value is, for some reason, an invalid pointer, which it
>> really should not be. So you probably might want to raise this up with
>> glibc developers too.
>>
>> Aki
>>
>> On 08.08.2018 06:54, Reuben Farrelly wrote:
>>> Hi,
>>>
>>> Dovecot 2.3 (release and current -git) versions compile, but fail to
>>> run when compiled against glibc-2.28.
>>>
>>> This is what is logged on startup:
>>>
>>> Aug  8 08:24:39 thunderstorm.reub.net dovecot[569]: master: Dovecot
>>> v2.3.2.1 (0719df592) starting up for imap, lmtp, sieve, 

Re: Reproducible SIGSEGV when Dovecot 2.3 compiled against glibc-2.28

[Reuben Farrelly]

Hi,

The link to the release notes seems should have an 'l' on the end:

Try: https://www.sourceware.org/ml/libc-alpha/2018-08/msg3.html

This with gdb:

thunderstorm /usr/src/dovecot/dovecot-2.3/src/auth # gdb 
/root/dovecot-auth-crash/auth /root/dovecot-auth-crash/core.auth.29667 
GNU gdb (Gentoo 8.1.1 p1) 8.1.1

Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /root/dovecot-auth-crash/auth...done.

warning: exec file is newer than core file.
[New LWP 29667]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `dovecot/auth'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  __strcmp_sse2_unaligned () at 
../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:31
31  ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S: No such 
file or directory.

(gdb) bt full
#0  __strcmp_sse2_unaligned () at 
../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:31

No locals.
#1  0x562d7a9d8dcf in password_scheme_register_crypt () at 
password-scheme-crypt.c:191

i = 0
crypted = 0xf6e4b200 address 0xf6e4b200>

__func__ = 
#2  0x562d7a9d87cb in password_schemes_init () at password-scheme.c:874
i = 27
#3  0x562d7a9a082a in main_preinit () at main.c:185
mod_set = {abi_version = 0xf74856c0 memory at address 0xf74856c0>,
  binary_name = 0x6f6c0d52e61baf00 at address 0x6f6c0d52e61baf00>,
  setting_name = 0x7fa9f6e97011 <__x86_return_thunk+5> 
"\363\220\017\256\350\353\371H\215d$\b\303\350\a",
  filter_callback = 0x7fa9f6ecd029 , 
filter_context = 0x7fa9f6e97011 <__x86_return_thunk+5>,
  require_init_funcs = false, debug = false, 
ignore_dlopen_errors = false, ignore_missing = false}

services = 0x562d7b4d9fa0
#4  0x562d7a9a0ef5 in main (argc=1, argv=0x562d7b4d9ae0) at main.c:392
c = -1
(gdb) p sample[i].key
No symbol "i" in current context.
(gdb) p sample[i].salt
No symbol "i" in current context.
(gdb)

However:

(gdb) p sample[0].key
$1 = 0x562d7a9f2f1e "08/15!test~4711"
(gdb) p sample[1].key
$2 = 0x562d7a9f2f1e "08/15!test~4711"
(gdb) p sample[2].key
$3 = 0x562d7a9f2f1e "08/15!test~4711"
(gdb) p sample[0].salt
$4 = 0x562d7a9f2f2e "JB"
(gdb) p sample[1].salt
$5 = 0x562d7a9f2f40 "$5$rounds=1000$0123456789abcdef"
(gdb) p sample[2].salt
$6 = 0x562d7a9f2fb0 "$6$rounds=1000$0123456789abcdef"
(gdb)


(Different core file to earlier but the trace looks the same)

I haven't experienced any problems with any other apps (yet).

Thanks,
Reuben


On 8/08/2018 4:13 pm, Aki Tuomi wrote:

Hi!

Thank you for the report, few points though:

  - The link you provided is broken

  - getting glibc-2.28 prebuilt seems to be bit problematic, and what I
read from their changelog, the crypt function should work as normal.
That said, it would be somewhat helpful if you could use gdb to find out
what was passed to crypt

p sample[i].key
p sample[i].salt

the return value is, for some reason, an invalid pointer, which it
really should not be. So you probably might want to raise this up with
glibc developers too.

Aki

On 08.08.2018 06:54, Reuben Farrelly wrote:

Hi,

Dovecot 2.3 (release and current -git) versions compile, but fail to
run when compiled against glibc-2.28.

This is what is logged on startup:

Aug  8 08:24:39 thunderstorm.reub.net dovecot[569]: master: Dovecot
v2.3.2.1 (0719df592) starting up for imap, lmtp, sieve, submission, sieve
Aug  8 08:24:39 thunderstorm.reub.net dovecot[569]: master: Error:
service(auth): command startup failed, throttling for 2 secs
Aug  8 08:24:39 thunderstorm.reub.net dovecot[574]: auth: Fatal:
master: service(auth): child 582 killed with signal 11 (core dumped)
Aug  8 08:24:39 thunderstorm.reub.net dovecot[574]: replicator: Error:
userdb lookup: Disconnected unexpectedly
Aug  8 08:24:52 thunderstorm.reub.net dovecot[569]: master: Warning:
Killed with signal 15 (by pid=670 uid=0 code=kill)

The issue is specifically with the 'auth' binary.  Other components
all appear to be unaffected.  The 'auth' binary dies with a
Segmentation Fault when run as a standalone executable too.
As the auth binary is critical to many different parts of Dovecot, a
failure of this is catastrophic.

This is a 100% reproducible problem.  The platform is Gentoo x86_64.

Re: Reproducible SIGSEGV when Dovecot 2.3 compiled against glibc-2.28

[Aki Tuomi]

Hi!

Thank you for the report, few points though:

 - The link you provided is broken

 - getting glibc-2.28 prebuilt seems to be bit problematic, and what I
read from their changelog, the crypt function should work as normal.
That said, it would be somewhat helpful if you could use gdb to find out
what was passed to crypt

p sample[i].key
p sample[i].salt

the return value is, for some reason, an invalid pointer, which it
really should not be. So you probably might want to raise this up with
glibc developers too.

Aki

On 08.08.2018 06:54, Reuben Farrelly wrote:
> Hi,
>
> Dovecot 2.3 (release and current -git) versions compile, but fail to
> run when compiled against glibc-2.28.
>
> This is what is logged on startup:
>
> Aug  8 08:24:39 thunderstorm.reub.net dovecot[569]: master: Dovecot
> v2.3.2.1 (0719df592) starting up for imap, lmtp, sieve, submission, sieve
> Aug  8 08:24:39 thunderstorm.reub.net dovecot[569]: master: Error:
> service(auth): command startup failed, throttling for 2 secs
> Aug  8 08:24:39 thunderstorm.reub.net dovecot[574]: auth: Fatal:
> master: service(auth): child 582 killed with signal 11 (core dumped)
> Aug  8 08:24:39 thunderstorm.reub.net dovecot[574]: replicator: Error:
> userdb lookup: Disconnected unexpectedly
> Aug  8 08:24:52 thunderstorm.reub.net dovecot[569]: master: Warning:
> Killed with signal 15 (by pid=670 uid=0 code=kill)
>
> The issue is specifically with the 'auth' binary.  Other components
> all appear to be unaffected.  The 'auth' binary dies with a
> Segmentation Fault when run as a standalone executable too.
> As the auth binary is critical to many different parts of Dovecot, a
> failure of this is catastrophic.
>
> This is a 100% reproducible problem.  The platform is Gentoo x86_64.
>
> thunderstorm /usr/libexec/dovecot # ./auth-old
> Segmentation fault
> thunderstorm /usr/libexec/dovecot #
>
> [I've renamed the original binary to auth-old, and put in it's place a
> working 'auth' binary built against glibc-2.27 in order to have a
> functioning system]
>
> Problem matrix looks like this:
>
> Build on a glibc-2.27 system, run on a glibc-2.27 - OK
> Build on a glibc-2.27 system, run on a glibc-2.28 - OK
> Build on a glibc-2.28 system, run on a glibc-2.27 - SEGFAULT
> Build on a glibc-2.28 system, run on a glibc-2.28 - SEGFAULT
>
> (All other components including gcc otherwise identical)
>
> ./configure --prefix=/usr --build=x86_64-pc-linux-gnu
> --host=x86_64-pc-linux-gnu --mandir=/usr/share/man
> --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
> --localstatedir=/var/lib --disable-dependency-tracking
> --disable-silent-rules --docdir=/usr/share/doc/dovecot-_p20180807
> --htmldir=/usr/share/doc/dovecot-_p20180807/html
> --libdir=/usr/lib64 --with-rundir=/run/dovecot
> --with-statedir=/var/lib/dovecot --with-moduledir=/usr/lib64/dovecot
> --without-stemmer --disable-rpath --without-libbsd --with-icu
> --with-ssl --with-systemdsystemunitdir=/lib/systemd/system
> --with-sodium --with-bzlib --without-libcap --without-gssapi
> --without-lua --without-ldap --with-lucene --with-lz4 --with-lzma
> --without-mysql --with-pam --without-pgsql --without-sqlite
> --without-solr --with-libwrap --without-textcat --without-vpopmail
> --with-zlib --disable-static
>
>
> Strace:
>
> thunderstorm /usr/libexec/dovecot # strace ./auth-old
> execve("./auth-old", ["./auth-old"], 0x7ffd17c804c0 /* 27 vars */) = 0
> brk(NULL)   = 0x557e9dc28000
> access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or
> directory)
> openat(AT_FDCWD,
> "/usr/lib64/dovecot/old-stats/tls/x86_64/x86_64/libstats_auth.so",
> O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> stat("/usr/lib64/dovecot/old-stats/tls/x86_64/x86_64", 0x7ffcc7973020)
> = -1 ENOENT (No such file or directory)
> openat(AT_FDCWD,
> "/usr/lib64/dovecot/old-stats/tls/x86_64/libstats_auth.so",
> O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> stat("/usr/lib64/dovecot/old-stats/tls/x86_64", 0x7ffcc7973020) = -1
> ENOENT (No such file or directory)
> openat(AT_FDCWD,
> "/usr/lib64/dovecot/old-stats/tls/x86_64/libstats_auth.so",
> O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> stat("/usr/lib64/dovecot/old-stats/tls/x86_64", 0x7ffcc7973020) = -1
> ENOENT (No such file or directory)
> openat(AT_FDCWD, "/usr/lib64/dovecot/old-stats/tls/libstats_auth.so",
> O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> stat("/usr/lib64/dovecot/old-stats/tls", 0x7ffcc7973020) = -1 ENOENT
> (No such file or directory)
> openat(AT_FDCWD,
> "/usr/lib64/dovecot/old-stats/x86_64/x86_64/libstats_auth.so",
> O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> stat("/usr/lib64/dovecot/old-stats/x86_64/x86_64", 0x7ffcc7973020) =
> -1 ENOENT (No such file or directory)
> openat(AT_FDCWD,
> "/usr/lib64/dovecot/old-stats/x86_64/libstats_auth.so",
> O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
>