I have sieve working fine with dovecot.
I can edit the filters via ssh and they do the right thing.
My mail server is on a different IP than the Dovecot install, which makes login a bit more complicated, but login works properly for roundcube's mail access, but the same config options do not seem to work with the managesieve plugin. I've tried a few options, googled about, and figured I'd ask:
IMAP config, which works, looks like:
$config['default_host'] = 'ssl://mail.domain.tld'; $config['default_port'] = 993; $config['imap_conn_options'] = array( 'ssl' => array( 'verify_peer' => false, 'verfify_peer_name' => false, ), );
this connects generating log entries like:
Jul 13 10:56:36 imap-login: Info: Login: user=me@domain.tld, method=PLAIN, rip=10.3.69.139, lip=10.3.69.135, mpid=21055, TLS, session=<1nRXpzZUIVUKA0WL>
(all good).
Configuring the manage sieve plugin as:
$config['managesieve_port'] = 4190;
$config['managesieve_host'] = 'ssl://mail.domain.tld';
$config['managesieve_auth_type'] = plain;
$config['managesieve_auth_cid'] = '%u';
$config['managesieve_auth_pw'] = '%p';
$config['imap_conn_options'] = array(
'ssl' => array(
'verify_peer' => false,
'verfify_peer_name' => false,
),
);
$config['managesieve_conn_options'] = null;
when I select the filters icon, the logs show:
Jul 13 10:59:47 managesieve-login: Info: Disconnected: Too many invalid commands. (no auth attempts in 0 secs): user=<>, rip=10.3.69.139, lip=10.3.69.135, session=<7gnCsjZUkpoKA0WL>
Seems to be opening a connection, but not speaking the right connection languge....
Also, alas, $config['managesieve_debug'] = true;
does not result in /var/log/sieve being generated (or after being created, being populated)
Any hints very much appreciated.
David Gessel skrev den 2017-07-13 20:07:
does not result in /var/log/sieve being generated (or after being created, being populated)
roundcube does not use syslog, in the chroot roundcube dir you have a subdir logs/
no logs there ?
Any hints very much appreciated.
tirred now to read my config
using only 127.0.0.1 for server hosts, maybe some php class keep rfc1918 ssl/tls secure still, dont know or ever needed to try
On 14/07/2017 04:07, David Gessel wrote:
Configuring the manage sieve plugin as:
$config['managesieve_port'] = 4190; $config['managesieve_host'] = 'ssl://mail.domain.tld';
remove ssl://
and set:
$rcmail_config['managesieve_usetls'] = true;
Thanks Benny!
Good hint to the logs dir, no "sieve" file was created but
/usr/local/www/roundcube/logs
exists and has an .htaccess file. There is nothing else.
# touch sieve # chmod 777 sieve
not logging, alas... but Noel's advice has moved me forward and dovecot has logged a handshake failure (due to expired cert). That's easy to fix...
-David
-------- Original Message -------- Subject: Re: [RCU] managesieve From: Benny Pedersen me@junc.eu To: users@lists.roundcube.net Date: Fri Jul 14 2017 00:22:56 GMT+0300 (AST)
David Gessel skrev den 2017-07-13 20:07:
does not result in /var/log/sieve being generated (or after being created, being populated)
roundcube does not use syslog, in the chroot roundcube dir you have a subdir logs/
no logs there ?
Any hints very much appreciated.
tirred now to read my config
using only 127.0.0.1 for server hosts, maybe some php class keep rfc1918 ssl/tls secure still, dont know or ever needed to try _______________________________________________ Roundcube Users mailing list users@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/users
Thanks! A step closer. It seems the roundcube logins can be set to ignore certificate errors, but managesieve isn't:
Jul 14 04:34:49 managesieve-login: Info: Disconnected (no auth attempts in 0 secs): user=<>, rip=10.3.69.139, lip=10.3.69.135, TLS handshaking: SSL_accept() failed: error:14094415:SSL routines:ssl3_read_bytes:sslv3 alert certificate expired: SSL alert number 45, session=<d7vVb0VUNlsKA0WL>
This isn't accurate: it is a self-signed cert good until 2025.
While I'm OK with lets encrypt certificates, self-signed certificates should be supported. As I remember, I ran into this problem with roundcube's checks, which is why the ssl://.... and
$config['imap_conn_options'] = array( 'ssl' => array( 'verify_peer' => false, 'verfify_peer_name' => false, ), );
which "managesieve_usetls" seems to ignore.
Any way to get managesieve to function the same way or is this a "pay the cert mafia or else..." situation?
-David
-------- Original Message -------- Subject: Re: [RCU] managesieve From: Noel Butler noel.butler@ausics.net To: users@lists.roundcube.net Date: Fri Jul 14 2017 04:56:31 GMT+0300 (AST)
On 14/07/2017 04:07, David Gessel wrote:
Configuring the manage sieve plugin as:
$config['managesieve_port'] = 4190; $config['managesieve_host'] = 'ssl://mail.domain.tld';
remove ssl://
and set:
$rcmail_config['managesieve_usetls'] = true;
--
Kind Regards,
Noel Butler
This Email, including any attachments, may contain legally privileged information, therefore remains confidential and subject to copyright protected under international law. You may not disseminate, discuss, or reveal, any part, to anyone, without the authors express written authority to do so. If you are not the intended recipient, please notify the sender then delete all copies of this message including attachments, immediately. Confidentiality, copyright, and legal privilege are not waived or lost by reason of the mistaken delivery of this message. Only PDF http://www.adobe.com/ and ODF http://en.wikipedia.org/wiki/OpenDocument documents accepted, please do not send proprietary formatted documents
Roundcube Users mailing list users@lists.roundcube.net http://lists.roundcube.net/mailman/listinfo/users
Hi David,
is clock in sync on the machine (just to eliminate this as possible error)?
Regarding your self-signed issues I'd suggest to let your system trust the certificate which you use. Either by putting the CA cert or the server cert in your trust store (depends on your system). There is a big difference between using a certificate which can be validated (even when self signed) and trusting any presented certificate (even if there are config switches to disable checking).
hth+regards, Thomas
On 14.07.2017 13:44, David Gessel wrote:
Thanks! A step closer. It seems the roundcube logins can be set to ignore certificate errors, but managesieve isn't:
Jul 14 04:34:49 managesieve-login: Info: Disconnected (no auth attempts in 0 secs): user=<>, rip=10.3.69.139, lip=10.3.69.135, TLS handshaking: SSL_accept() failed: error:14094415:SSL routines:ssl3_read_bytes:sslv3 alert certificate expired: SSL alert number 45, session=<d7vVb0VUNlsKA0WL>
This isn't accurate: it is a self-signed cert good until 2025.
While I'm OK with lets encrypt certificates, self-signed certificates should be supported. As I remember, I ran into this problem with roundcube's checks, which is why the ssl://.... and
$config['imap_conn_options'] = array( 'ssl' => array( 'verify_peer' => false, 'verfify_peer_name' => false, ), );
which "managesieve_usetls" seems to ignore.
Any way to get managesieve to function the same way or is this a "pay the cert mafia or else..." situation?
-David
Thomas,
They share a clock, so yes (jails, freebsd).
Adding the cert to the store seems painfully obvious. I'll give that a try, though I think it may be time to embrace Lets Encrypt.
-David
-------- Original Message -------- Subject: Re: [RCU] managesieve From: roundcube--lists@thomas.freit.ag To: users@lists.roundcube.net Date: Fri Jul 14 2017 22:11:59 GMT+0300 (AST)
Hi David,
is clock in sync on the machine (just to eliminate this as possible error)?
Regarding your self-signed issues I'd suggest to let your system trust the certificate which you use. Either by putting the CA cert or the server cert in your trust store (depends on your system). There is a big difference between using a certificate which can be validated (even when self signed) and trusting any presented certificate (even if there are config switches to disable checking).
hth+regards, Thomas
-
Benny Pedersen -
David Gessel -
Noel Butler -
roundcube--lists＠thomas.freit.ag