Re: dovecot-pigeonhole running external script ends with signal 11
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 4 Jan 2017, Tobi wrote: [New process 20844] Program received signal SIGSEGV, Segmentation fault. [Switching to process 20844] 0x77203694 in _IO_vfprintf_internal (s=s@entry=0x7fffd710, format=, format@entry=0x55764938 "chroot(%s) failed: Bad address", ap=ap@entry=0x7fffd970) at vfprintf.c:1635 1635 process_string_arg (((struct printf_spec *) NULL)); Does your script tries to chroot? Do you have LMTP or Dovecot configured to chroot? As Stephan asked, can you determine with process is spawned here? The format string "chroot(%s) failed: Bad address" may stem from a Dovecot library. - -- Steffen Kaiser -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEVAwUBWG9Nxnz1H7kL/d9rAQJIrgf/Y6NvtcCa0HkOHogOJwC42a5NSpA5nqlP sdANI8onYt/JReJA9PzeIKXgCps92xj0d85LNAIVcS4HjKcnBJZLSuWCVg8ppyjy NQbW499DsPtW/sw4bjs4P/yUR5eLw8ERV5EOABwemTBQz03EuBVa4bm6vkses+sN X+C9WJ54bBtjH6fPljpTagwfijNgAnPbkr/EuthMOKzx5IS02Nr3ec0hgDdFGHPu 4slRViTuYSr1dx0MmsqdiEE6wDdZLagLuc6kpVWa5M04L7wrQIri4b6AECf5sFOZ YQaosywbBTZKGYMXGHwX09A3wa8Uei1WgXkRNh6NyVbdy+Ubp5Dahw== =ntGy -END PGP SIGNATURE-
OP/PSA: Net Systems Research mail port diddlers
http://netsystemsresearch.com/ dovecot.log.1.bz2:Jan 05 17:28:15 pop3-login: Info: Disconnected (no auth attempts in 3 secs): user=<>, rip=169.54.233.124, lip=MYIP, TLS handshaking: Disconnected, session= Their "research" pokes your email ports. Block if you want or participate in the (cough cough) research. IP addresses and opt-out email address on webpage.
Re: Dovecot dsync tcps sends incomplete certificate chain
On 01/05/2017 08:55 PM, Juri wrote: > 5 Gennaio 2017 01:21, "John Fawcett" wrote: > >> On 01/04/2017 08:40 PM, Juri wrote: >> >> > Thank you. > > In fact I tried both settings, that is > |ssl_client_ca_dir = /etc/ssl/certs > |ssl_client_ca_file = /etc/letsencrypt/live/mail.dividebyzero.it/chain.pem > but with no luck. > Actually, I noticed that with the two settings I get a slightly different > error message (it took me > quite a bit to notice it!), that is: > |Error: sync: Disconnected from remote: Received invalid SSL certificate: > unable to get issuer > certificate: /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3 > |Error: sync: Disconnected from remote: Received invalid SSL certificate: > unable to get *local* > issuer certificate: /CN=mail.dividebyzero.it > (emphasis mine). > I suppose that in the first case - as the server is sending only the last > certificate on the chain > - the client is unable to find the intermediate, while in the second case it > won't find the root > one. > > I then tried, as you suggested me, to concatenate both the intermediate and > the root certificate in > a single file, and it finally worked. > In any case the original point still stands: in the sync mode - at least on > my version (2.2.13) - > the server sends only the last cert, so the client has to have the rest of > the chain, instead of > needing to have only the root certificate. > > May I ask you which is the version of Dovecot bundled with CentOS, to know if > this may be a bug > fixed in a newer version? > > Juri Hi Juri if you find validation failing when you have only the root certificate in the CA file but a chained server+intermediate in the server certificate file, then your analysis makes sense and it seems that the intermediate certificate is not being sent by the server. That ties in with the different error messages between imap and replication. It might be interesting to do a test with -showcerts parameter. |openssl s_client -showcerts -connect hostname:|7557 |openssl s_client -showcerts -connect hostname:993 The bundled version of Dovecot on Centos 7 is 2.2.10 but I am not using that version. I am on 2.2.26, where I don't have the problem you see and both services send the server and intermediate certificate. I was unable to see any specific patches to the ssl or doveadm code for this issue, though it has undergone a few changes from 2.2.13. John |
Re: dovecot-pigeonhole running external script ends with signal 11
Op 1/4/2017 om 9:37 AM schreef Tobi: > Hi Aki > > yes I built dovecot and pigeonhole rpms in the same rpmbuild. pigeonhole > rpm is based on 0.4.14 > Do you think that the error might come from self building the rpms? But what version of Pigeonhole are you actually using? Version 0.4.16 is released for Dovecot v2.2.26. Also: - Can you find out which process is getting the segfault? GDB shows the pid and you should lookup what process that is while GDB is still active. - Isn't that GDB backtrace you provided deeper? It shows only two levels, but that makes no sense (i.e. main() is not listed). Regards, Stephan.
IMAP proxy for Exchange - encrypted backend Communication?
Hello, I try to setup a IMAP proxy for my old Exchange server. Running Dovecot v2.x on Centos 7. So far I follow http://wiki2.dovecot.org/HowTo/ImapcProxy and it seem to work. The only but major thing is with this setup - the communication between proxy and backend is not encrypted. :( To fix this, I changed the config and add: imapc_ssl=imaps imapc_port=993 but it doesnt work, because of verify failure of the self signed backend certificate: Jan 5 21:48:55 imap dovecot: imap(user1): Error: imapc(192.168.1.1:993): Couldn't initialize SSL context: Can't verify remote server certs without trusted CAs (ssl_client_ca_* settings) Jan 5 21:48:55 imap dovecot: imap(user1): Error: imapc(192.168.1.1:993): No SSL context Jan 5 21:48:55 imap dovecot: imap(user1): Error: imapc: Command failed: Disconnected from server Jan 5 21:48:55 imap dovecot: imap(user1): Error: user tkoenig: Initialization failed: Initializing mail storage from mail_location setting failed: Mailbox list driver imapc: Failed to access imapc backend Jan 5 21:48:55 imap dovecot: imap(user1): Error: Invalid user settings. Refer to server log for more information. I didnt found anything in the documentation which tells dovcot not verify the backend certificate. Is there a know way to get it runing? Many thanks for any hint! regrds, Tom
Re: Dovecot dsync tcps sends incomplete certificate chain
5 Gennaio 2017 01:21, "John Fawcett" wrote:
> On 01/04/2017 08:40 PM, Juri wrote:
>
>> Hi,
>> I'm trying to configure a Dovecot dsync service between two servers, using a
>> tcp+ssl connection and
>> a valid Let's Encrypt certificate.
>> I followed the guide on the wiki (http://wiki.dovecot.org/Replication) using
>> the tcps method, but
>> when I launch the replication it fails writing on the log
>> (/var/log/mail.err):
>> (Server 1 - sync "client" )| Error: sync: Disconnected from remote: Received
>> invalid SSL
>> certificate: unable to get local issuer certificate: /CN=mail.dividebyzero.it
>> (Server 2 - sync "server")| Error: doveadm client disconnected before
>> handshake:
>>
>> If I try to connect to the server using openssl s_client, on the port 993
>> (imaps) the server
>> correctly sends the full chain:
>> $ openssl s_client -connect server1.fqdn:993
>> CONNECTED(0003)
>> depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
>> verify return:1
>> depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
>> verify return:1
>> depth=0 CN = mail.dividebyzero.it
>> verify return:1
>> ---
>> Certificate chain
>> 0 s:/CN=mail.dividebyzero.it
>> i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
>> 1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
>> i:/O=Digital Signature Trust Co./CN=DST Root CA X3
>> ...
>>
>> while on the doveadm port it fails:
>> $ openssl s_client -connect server1.fqdn:7557
>> CONNECTED(0003)
>> depth=0 CN = mail.dividebyzero.it
>> verify error:num=20:unable to get local issuer certificate
>> verify return:1
>> depth=0 CN = mail.dividebyzero.it
>> verify error:num=21:unable to verify the first certificate
>> verify return:1
>> ---
>> Certificate chain
>> 0 s:/CN=mail.dividebyzero.it
>> i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
>> ...
>>
>> I run Dovecot 2.2.13 on Debian 8.6:
>> $ dovecot -n
>> # 2.2.13: /etc/dovecot/dovecot.conf
>> # OS: Linux 3.16.0-4-amd64 x86_64 Debian 8.6
>> auth_default_realm = dividebyzero.it
>> auth_mechanisms = plain login
>> doveadm_password = (redacted)
>> doveadm_port = 7557
>> mail_location = maildir:~/Maildir
>> mail_plugins = " notify replication"
>> namespace inbox { (removed) }
>> passdb {
>> driver = pam
>> }
>> passdb {
>> args = username_format=%n /etc/vmail/%d/passwd
>> driver = passwd-file
>> }
>> plugin {
>> mail_replica = tcps:otherserver.fqdn
>> }
>> protocols = " imap lmtp"
>> service aggregator {
>> fifo_listener replication-notify-fifo {
>> user = dovecot
>> }
>> unix_listener replication-notify {
>> user = dovecot
>> }
>> }
>> service auth {
>> unix_listener auth-client {
>> group = Debian-exim
>> mode = 0660
>> }
>> unix_listener auth-userdb {
>> user = vmail
>> }
>> }
>> service doveadm {
>> inet_listener {
>> port = 7557
>> ssl = yes
>> }
>> }
>> service imap-login {
>> inet_listener imap {
>> port = 143
>> }
>> inet_listener imaps {
>> port = 993
>> ssl = yes
>> }
>> }
>> service replicator {
>> process_min_avail = 1
>> unix_listener replicator-doveadm {
>> mode = 0666
>> }
>> }
>> ssl = required
>> ssl_cert = > ssl_client_ca_file = /etc/letsencrypt/live/mail.dividebyzero.it/chain.pem
>> ssl_key = > userdb {
>> driver = passwd
>> }
>> userdb {
>> args = uid=vmail gid=vmail home=/var/local/vmail/%d/%n
>> driver = static
>> }
>>
>> Is it a known problem, or has it been resolved in a subsequent version?
>> If it is not, can you suggest me a workaround in the meantime?
>> Thank you.
>
> I would do those test using the -CAfile parameter to be sure of the
> local certificate file being used:
>
> openssl s_client -connect server1.fqdn:993 -CAfile
> /etc/letsencrypt/live/mail.dividebyzero.it/chain.pem
> openssl s_client -connect server1.fqdn:7557 -CAfile
> /etc/letsencrypt/live/mail.dividebyzero.it/chain.pem
>
> You should also be able to see the problem using the verify command directly
> (on the cert copied
> from the remote server)
> openssl verify -CAfile /etc/letsencrypt/live/mail.dividebyzero.it/chain.pem
> fullchain_copied_from_remote_server.pem
>
> This error happens when the local CA file or directory that is specified
> does not contain the root certificate or the root certificate and
> intermediate ones in the case that the intermediates are not supplied by
> the server. My understanding is that Dovecot supplies the intermediate
> certificates both for replication and imap services if they are in the
> server certificate file. So you should be able to solve this by making
> the root certificate available to Dovecot (parameter
> ssl_client_ca_file). In the worst case you can concatenate the
> intermediate and root certificates.
>
> The certificate you are likely missing is the root certificate:
>
> /O=Digital Signature Trust Co./CN=DST Root CA X3
>
> You can follow the link on this page for it:
> https://letsencrypt.org/certificates
> (link DST Root CA X3.)
>
> I recently set up replication following the wiki and I think you
> deviated from the instructions at thi
Re: dovecot-pigeonhole running external script ends with signal 11
Problem avoided by a quite ugly workaround :-) The script now is called by postfix as a transport. Works so far and the script never segfaults until now. Would still prefer the solution via dovecot sieve but for the moment the postfix solution is okay with me. Cheers tobi - Originale Nachricht - Von: Tobi Gesendet: 04.01.17 - 09:37 An: dovecot@dovecot.org Betreff: Re: dovecot-pigeonhole running external script ends with signal 11 > Hi Aki > > yes I built dovecot and pigeonhole rpms in the same rpmbuild. pigeonhole > rpm is based on 0.4.14 > Do you think that the error might come from self building the rpms? > > Regards > > tobi > > Am 04.01.2017 um 08:55 schrieb Aki Tuomi: >> On 04.01.2017 09:49, Tobi wrote: >>> Hi Stephan >>> >>> Am 03.01.2017 um 21:12 schrieb Stephan Bosch: >>> Since you're using LMTP, you could try to run the lmtp service from command line in GDB. In essence, this looks as follows (you will need to run this as the mail user, e.g. vmail, or you can run it as root): $ gdb --args /usr/lib/dovecot/lmtp >>> I did so and it seems that libc.so.6 throws the error as I get the >>> following result (as root): >>> >>> [New process 14843] >>> Program received signal SIGSEGV, Segmentation fault. >>> [Switching to process 14843] >>> 0x77241b71 in __strlen_sse2 () from /lib64/libc.so.6 >>> >>> bt full does not give me more than this >>> >>> #0 0x77241b71 in __strlen_sse2 () from /lib64/libc.so.6 >>> No symbol table info available. >>> Cannot access memory at address 0x7fffd848 >>> >>> Then I installed debuginfo for glibc via debuginfo-install >>> glibc-2.17-157.el7_3.1.x86_64 and get >>> >>> Program received signal SIGSEGV, Segmentation fault. >>> [Switching to process 18099] >>> __strlen_sse2 () at ../sysdeps/x86_64/strlen.S:31 >>> 31 movdqu (%rdi), %xmm1 >>> >>> So this is an issue for glibc developpers? Just wonder why this error >>> does not occur if I call the script directly on cli or if I use >>> sieve-test program. It seems only to occur if the script called from dovecot >>> >>> To compare I tried gdb as well as user vmail and get more detailed >>> information >>> >>> [New process 20844] >>> Program received signal SIGSEGV, Segmentation fault. >>> [Switching to process 20844] >>> 0x77203694 in _IO_vfprintf_internal (s=s@entry=0x7fffd710, >>> format=, >>> format@entry=0x55764938 "chroot(%s) failed: Bad address", >>> ap=ap@entry=0x7fffd970) at vfprintf.c:1635 >>> 1635 process_string_arg (((struct printf_spec *) NULL)); >>> >>> bt full does return much more in this case. I attached that output as >>> bt_full.txt to this mail (maybe it can be of help) >>> >>> Thanks for your help >>> >>> tobi >>> >> >> Did you update both dovecot *and* pigeonhole when you last updated? >> >> Aki >>
doveadm output format changes
It appears that doveadm output format changes every now and then, without particular notice. For example, the following command: doveadm -f pager mailbox status 'messages recent' '*' did output something like this until v2.2.24 : mailbox: Mailbox1 messages: 58 recent: 12 ^L mailbox: Mailbox2 messages: 128 recent: 0 but switched to that in v2.2.26 : Mailbox1 messages: 58 recent: 12 ^L Mailbox2 messages: 128 recent: 0 This seems related to the following changelog entry: 2016-10-25 20:51:36 +0300 Timo Sirainen (5baa99e) doveadm: "pager" formatter supports now DOVEADM_PRINT_HEADER_FLAG_HIDE_TITLE M src/doveadm/doveadm-print-pager.c Some other format changes did also occur in the past. For example, "doveadm user" had a specific format in v2.0.19 (and ignored the "-f format" option), and obviously defaulted to the "-f tab" format (which has different rendering) somewhere in the v2.2.x or 2.1.x. Such changes render maintenance of wrapping scripts particularly tedious. Could it be possible to avoid such breaking changes in the future ? -- Benoit BRANCIARD Service InfraStructures (SIS) Direction du Système d'Information et des Usages Numériques (DSIUN) Université Paris 1 Panthéon-Sorbonne Centre Pierre Mendès France 90 rue de Tolbiac - 75634 Paris cedex 13 - France Bur. B406 - Tél +33 1 44 07 89 68 - Fax +33 1 44 07 89 66 Accueil: +33 1 44 07 89 65 - assistance-ds...@univ-paris1.fr http://dsi.univ-paris1.fr
