The one that works fine was my openxchange server, that loads contacts
from openldap.
In my opinion I don't have installed a security framework list SELinux
or AppArmor.
The output of namei -l /etc/ssl/certs/LetsEncrypt.pem
f: /etc/ssl/certs/LetsEncrypt.pem
drwxr-xr-x root root /
On 21/03/17 07:03, Joseph Tam wrote:
Sami Ketola writes:
Can anyone with Solr installed confirm/refute this: does installing
Solr keep iOS clients from roofing the connection count?
I doubt it, but since IMAP SEARCH goes all the way down to the backends
mail_max_userip_connections can be
Don't lose any of the dovecot-* files and your clients should be fine. I've
done 1) a couple of times and nobody got hurt.What you should do is keep the
two servers (the old and the new one), and once the new one is ready test with
your client only (change your client's IMAP/POP server
On 11.03.2017 09:43, azu...@pobox.sk wrote:
Do you have mailbox_list_index=yes? That's at least buggy with
aliases and the fix isn't easy.
>>>
>>>
>>> Yes, i have. Do i need to disable it? What impact will it have?
>>
>> For mailbox aliases to work, yes. It will stop using index file
Hi to all.
It's time to migrate an old server to a newer platform
Some questions:
1) what happens by changing the pop3/IMAP server on the client?
Is the client (Outlook, Thunderbird,...) smart enough to not download every
message again?
I'm asking this because the easier way to migrate would be
I have a new pcap from beginning to the end with openldap "TLS
negoiation failed"
https://gwarband.de/openldap/tracefile.dump
The sourceports are 45376 and 45377
Tobias
Am 2017-03-20 19:59, schrieb Aki Tuomi:
Well, those actually *reduce* the possible algorithms that can be
used, so
Sami Ketola writes:
Can anyone with Solr installed confirm/refute this: does installing
Solr keep iOS clients from roofing the connection count?
I doubt it, but since IMAP SEARCH goes all the way down to the backends
mail_max_userip_connections can be used to limit the number of
connections.
This appears to be Tika related. I’m running the latest Tika (1.14).
I’ve turned OFF tika, and can index everything.
I do have some of the “bad” messages saved.
What can I supply to help debug this?
--
Larry Rosenman http://www.lerctr.org/~ler
Phone:
Yeah, it's tika related. Also looks rather simple to fix.
Aki
> On March 20, 2017 at 9:44 PM Larry Rosenman wrote:
>
>
> This appears to be Tika related. I’m running the latest Tika (1.14).
>
>
>
> I’ve turned OFF tika, and can index everything.
>
>
>
> I do
Did you do some succesful lookup with something there? I can see few failed
attempts and one that seems to have worked just fine.
As pointed out earlier, are you using security frameworks like SELinux or
AppArmor? Also, can you provide namei -l /etc/ssl/certs/LetsEncrypt.pem
The failed
I have an existing server using mdbox & sis. There is a quantity of
corruption - I have no idea where it came in. I'd had a previous
rebuild some years ago and I thought I had a clean datastore. By
"corruption" I mean missing attachments and either missing or mixed-up
emails.
I've setup a
The user "dovecot" can access and read the cert.
Here is an output of the console:
https://gwarband.de/openldap/dovecot-certs.log
So I think there is nothing what prevent Dovecot to access the file.
Tobias
Am 2017-03-20 20:14, schrieb Tomas Habarta:
Actually, I likely managed to replicate the
Well, those actually *reduce* the possible algorithms that can be used, so
uncommenting those can make things worse.
Anyways, your pcap seems incomplete, can you try again?
Aki
> On March 20, 2017 at 8:14 PM i...@gwarband.de wrote:
>
>
> I have also tested with 2.2.28 and this version has
Actually, I likely managed to replicate the problem itself.
I've observed described behavior (timeout with connection error) only if
Dovecot's tls_ca_cert_file provided either non-existent file or there
was no read access to the existing file -- found during review after
sending my last post as I
> On 16 Mar 2017, at 22.23, Joseph Tam wrote:
>
> Can anyone with Solr installed confirm/refute this: does installing
> Solr keep iOS clients from roofing the connection count?
I doubt it, but since IMAP SEARCH goes all the way down to the backends
* Ralf Hildebrandt :
> Hi!
>
> I upgraded the 2.2 packages today (from 2:2.2.28-1~auto+5 to
> 2:2.2.28-1~auto+8) I now I'm getting an error:
I was able to determine the last working version: 2:2.2.28-1~auto+6
and the first "broken" version:
I've tested your soulution, but it also says the same error.
I've tested all combinations of:
- tls_ca_cert_file =
- tls = yes
- tls_require_cert = demand
Every time it says "Connection error".
Only when tls is uncommented it says "TLS required".
Additional information
* Ralf Hildebrandt :
> * Ralf Hildebrandt :
> > Hi!
> >
> > I upgraded the 2.2 packages today (from 2:2.2.28-1~auto+5 to
> > 2:2.2.28-1~auto+8) I now I'm getting an error:
>
> I was able to determine the last working version:
On 20.03.2017 13:49, Jerry wrote:
> I have been reading up on TLS and Dovecot and came across this URL:
> https://www.weakdh.org/sysadmin.html which recommended these settings
> for Dovecot. I would like to know if they are correct? Some much
> documentation on the web is pure garbage.
>
>
I have been reading up on TLS and Dovecot and came across this URL:
https://www.weakdh.org/sysadmin.html which recommended these settings
for Dovecot. I would like to know if they are correct? Some much
documentation on the web is pure garbage.
Dovecot
These changes should be made in
Bonjour,
Nobody uses the SIC functionnality ?
I think an extra option like hash added to doveadm fetch would resolve
my problem, any plan in a future version ? (may be I've missed an
command that can list hashes from a mail for restoring a mailbox. It's
the part after the X in the mail storage I
Hi!
I upgraded the 2.2 packages today (from 2:2.2.28-1~auto+5 to 2:2.2.28-1~auto+8)
I now I'm getting an error:
Mar 20 13:25:58 mproxy dovecot: auth: Error: imapc(email.charite.de:993):
Couldn't initialize SSL context: Can't verify remote server certs without
trusted CAs (ssl_client_ca_*
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 16 Mar 2017, Dirk Laurenz wrote:
What's anying is, that only on iOS ( ) i see a huge bunch of .CONTROL
directories - marked grey.
It seems to be a copy of the existing folder structure. I don't see this on
(Y)
Is there any chance
On 20.03.2017 12:58, Steffen Kaiser wrote:
> On Thu, 16 Mar 2017, Dirk Laurenz wrote:
>
> > What's anying is, that only on iOS ( ) i see a huge bunch of
> .CONTROL directories - marked grey.
>
> > It seems to be a copy of the existing folder structure. I don't see
> this on
>
> (Y)
>
> > Is
Hello,
I'm trying to migrate mail accounts from an old server to a new one.
As I need to migrate dozens of accounts which take about 1G each, I need
to do stateful sync to make my migration in two times :
1 - I run a :
doveadm -D -o mail_fsync=never -o imapc_user=us...@olddomain.fr
sync
I've finally managed that running on Debian 8 test machine by commenting
tls_ca_cert_file =
option from dovecot-ldap.conf, so only
tls = yes
tls_require_cert = demand
Not sure why is that as on my CentOS6 Dovecot works even with that
commented option. May be that CentOS
http://www.lerctr.org/~ler/dovecot/doveadm-2017-03-20.txt
doveconf –n attached and at:
http://www.lerctr.org/~ler/dovecot/doveconf.n.txt
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: larry...@gmail.com
US Mail:
I have also tested with 2.2.28 and this version has the same issue.
The finding of compatible ciphers is not the problem because I have
uncommented the ldap entrys:
TLSCipherSuite
SECURE128:-ARCFOUR-128:-CAMELLIA-128-CBC:-3DES-CBC:-CAMELLIA-128-GCM
TLSProtocolMin 3.1
Maybe
On 20.03.2017 14:30, Ralf Hildebrandt wrote:
> ssl_client_ca_file =
* Aki Tuomi :
>
>
> On 20.03.2017 14:30, Ralf Hildebrandt wrote:
> > ssl_client_ca_file =
> Leave the < out. It is misleading, I know, but it does say file. =)
Makes no difference:
# doveconf |fgrep ssl_client_ca
ssl_client_ca_dir =
ssl_client_ca_file =
Hi,
I'm configuring a proxy host to connect to backend servers. As proxy is
done based on an LDAP attribute of the user, I'm not using director.
In the proxy server I have configured:
doveadm_port = 24245
doveadm_password = secret
And in the backend:
service doveadm {
On 20.03.2017 16:40, Ralf Hildebrandt wrote:
> * Aki Tuomi :
>>
>> On 20.03.2017 14:30, Ralf Hildebrandt wrote:
>>> ssl_client_ca_file = > Leave the < out. It is misleading, I know, but it does say file. =)
> Makes no difference:
>
> # doveconf |fgrep ssl_client_ca
>
On 20 Mar 2017, at 13.24, Cédric ML wrote:
>
> Hello,
>
> I'm trying to migrate mail accounts from an old server to a new one.
> As I need to migrate dozens of accounts which take about 1G each, I need to
> do stateful sync to make my migration in two times :
>
>
* Ralf Hildebrandt :
> * Aki Tuomi :
>
> > Could you send us the gdb bt full backtrace for the core file?
>
> Currently I can't get it to create coredumps
Got a coredump and backtrace:
=
Mar 20 16:10:17 mproxy dovecot:
Can sombody say something about this request?
This is an email from the openldap-technical mailinglist from openldap.
Systemdetails are mention in the other email.
Originalnachricht
Betreff: Re: Dovecot can't connect to openldap over starttls
Datum: 2017-03-20 16:18
Absender:
* Aki Tuomi :
> Could you send us the gdb bt full backtrace for the core file?
Currently I can't get it to create coredumps
doveconf -n:
# 2.2.devel (3f97702): /etc/dovecot/dovecot.conf
# Pigeonhole version 0.4.devel (023f391)
# OS: Linux 4.4.0-65-generic x86_64 Ubuntu
> On March 20, 2017 at 5:28 PM i...@gwarband.de wrote:
>
>
> Can sombody say something about this request?
>
> This is an email from the openldap-technical mailinglist from openldap.
>
> Systemdetails are mention in the other email.
>
> Originalnachricht
> Betreff: Re:
37 matches
Mail list logo