[horde] ingo TLS certificate error problem

[Andy Dorman]

We have several servers that support a spam/virus filtering service and
an email service of a different name. The email filtering and email
hosting services use different domain names and the server host names
use a third, our company domain name.

The problem happens when Ingo tries to use TLS to connect and the
certificate is for the email hosting service (mail.FanMail.com) and the
server name is for our company (IronicDesign.com).

This causes PHP to complain as shown here

HORDE: [ingo] PHP ERROR: stream_socket_enable_crypto(): Peer certificate
CN=`mail.fanmail.com' did not match expected
CN=`yorick.ironicdesign.com' [pid 26001 on line 1215 of
"/usr/share/php/Net/Sieve.php"]

and the user sees an error: "Script not updated: There was an error
activating the script. The driver said: Failed to establish TLS connection"

After Googling I found where I can tell PHP to not verify the peer

$conf['ssl']['verify_peer'] = FALSE;
$conf['ssl']['verify_peer_name'] = FALSE;

OR I could possibly tell Ingo to use the mail.fanmail.com certificate?

I am trying to figure out which approach will work and how to apply it.
I would prefer to use ingo/backends.local.php which we already use to
set the appropriate host name for a user to connect to.

However, I can not find an option like these below in our current
backends.local.php to tell Ingo or PHP to use the 'mail.fanmail.com'
certificate.

$backends['sieve']['transport'][Ingo::RULE_ALL]['params']['logintype'] =
'PLAIN';
$backends['sieve']['transport'][Ingo::RULE_ALL]['params']['usetls'] = true;
$backends['sieve']['transport'][Ingo::RULE_ALL]['params']['port'] = 4190;

I suppose a third option is to set 'usetls' to false, but I would prefer
not to do that as some day we hope to move our mail servers into VMs
outside our local network.

Thanks for any help.

[Andy Dorman]

Post by Andy Dorman
We have several servers that support a spam/virus filtering service
and an email service of a different name. The email filtering and
email hosting services use different domain names and the server host
names use a third, our company domain name.
The problem happens when Ingo tries to use TLS to connect and the
certificate is for the email hosting service (mail.FanMail.com) and
the server name is for our company (IronicDesign.com).
This causes PHP to complain as shown here
HORDE: [ingo] PHP ERROR: stream_socket_enable_crypto(): Peer
certificate CN=`mail.fanmail.com' did not match expected
CN=`yorick.ironicdesign.com' [pid 26001 on line 1215 of
"/usr/share/php/Net/Sieve.php"]
and the user sees an error: "Script not updated: There was an error
activating the script. The driver said: Failed to establish TLS
connection"
After Googling I found where I can tell PHP to not verify the peer
$conf['ssl']['verify_peer'] = FALSE;
$conf['ssl']['verify_peer_name'] = FALSE;
OR I could possibly tell Ingo to use the mail.fanmail.com certificate?
I am trying to figure out which approach will work and how to apply
it. I would prefer to use ingo/backends.local.php which we already use
to set the appropriate host name for a user to connect to.

In that case, you should set the hostspec to 'mail.fanmail.com'. Of
course, that name should (DNS) resolve to the IP address of the server
where Sieve is living.
<?php
$backends['imap']['disabled'] = true;
$backends['sieve']['disabled'] = false;
$backends['sieve']['transport'][Ingo::RULE_ALL]['params']['hostspec'] =
'mail.fanmail.com';
Of course, the certificate on the server should contain
CN='mail.fanmail.com'. TLS doesn't care about hostname greetings, the
verification process uses the CN in the certificate and must match the
(forward) DNS record of that CN (reverse is not required).

Post by Andy Dorman
However, I can not find an option like these below in our current
backends.local.php to tell Ingo or PHP to use the 'mail.fanmail.com'
certificate.
$backends['sieve']['transport'][Ingo::RULE_ALL]['params']['logintype']
= 'PLAIN';
$backends['sieve']['transport'][Ingo::RULE_ALL]['params']['usetls'] =
true;
$backends['sieve']['transport'][Ingo::RULE_ALL]['params']['port'] = 4190;
I suppose a third option is to set 'usetls' to false, but I would
prefer not to do that as some day we hope to move our mail servers
into VMs outside our local network.
Thanks for any help.
--
Andy Dorman

Sorry, I would love to do that, but it won't work. We have a bunch of
servers that are all doing email+sieve for mail.fanmail.com users and
domain.

When the user logs into webmail, the Imp/Ingo client does an LDAP lookup
(in backends.local.php) for the specific server/host that contains that
user's email+sieve scripts. That email+sieve server
(yorick.ironicdesign.com in my log line above) has to be used in the
hostspec so Imp and Ingo pass their requests to the correct server.

So I have to set hostspec to be the physical server, but the SSL
certificate is for the service, mail.fanmail.com.

For now I suppose I will turn off tls. That is OK since all our sieve
requests use a private internal network space. We will just have to
figure out a solution before we can move our IMAP servers to VMs in
remote hosts.

Andy Dorman

[Andy Dorman]

Post by Andy Dorman

Post by Andy Dorman
We have several servers that support a spam/virus filtering service
and an email service of a different name. The email filtering and
email hosting services use different domain names and the server host
names use a third, our company domain name.
The problem happens when Ingo tries to use TLS to connect and the
certificate is for the email hosting service (mail.FanMail.com) and
the server name is for our company (IronicDesign.com).
This causes PHP to complain as shown here
HORDE: [ingo] PHP ERROR: stream_socket_enable_crypto(): Peer
certificate CN=`mail.fanmail.com' did not match expected
CN=`yorick.ironicdesign.com' [pid 26001 on line 1215 of
"/usr/share/php/Net/Sieve.php"]
and the user sees an error: "Script not updated: There was an error
activating the script. The driver said: Failed to establish TLS
connection"
After Googling I found where I can tell PHP to not verify the peer
$conf['ssl']['verify_peer'] = FALSE;
$conf['ssl']['verify_peer_name'] = FALSE;
OR I could possibly tell Ingo to use the mail.fanmail.com certificate?
I am trying to figure out which approach will work and how to apply
it. I would prefer to use ingo/backends.local.php which we already use
to set the appropriate host name for a user to connect to.

In that case, you should set the hostspec to 'mail.fanmail.com'. Of
course, that name should (DNS) resolve to the IP address of the server
where Sieve is living.
<?php
$backends['imap']['disabled'] = true;
$backends['sieve']['disabled'] = false;
$backends['sieve']['transport'][Ingo::RULE_ALL]['params']['hostspec'] =
'mail.fanmail.com';
Of course, the certificate on the server should contain
CN='mail.fanmail.com'. TLS doesn't care about hostname greetings, the
verification process uses the CN in the certificate and must match the
(forward) DNS record of that CN (reverse is not required).

Post by Andy Dorman
However, I can not find an option like these below in our current
backends.local.php to tell Ingo or PHP to use the 'mail.fanmail.com'
certificate.
$backends['sieve']['transport'][Ingo::RULE_ALL]['params']['logintype']
= 'PLAIN';
$backends['sieve']['transport'][Ingo::RULE_ALL]['params']['usetls'] =
true;
$backends['sieve']['transport'][Ingo::RULE_ALL]['params']['port'] = 4190;
I suppose a third option is to set 'usetls' to false, but I would
prefer not to do that as some day we hope to move our mail servers
into VMs outside our local network.
Thanks for any help.
--
Andy Dorman

Sorry, I would love to do that, but it won't work. We have a bunch of
servers that are all doing email+sieve for mail.fanmail.com users and
domain.
When the user logs into webmail, the Imp/Ingo client does an LDAP lookup
(in backends.local.php) for the specific server/host that contains that
user's email+sieve scripts. That email+sieve server
(yorick.ironicdesign.com in my log line above) has to be used in the
hostspec so Imp and Ingo pass their requests to the correct server.
So I have to set hostspec to be the physical server, but the SSL
certificate is for the service, mail.fanmail.com.
For now I suppose I will turn off tls. That is OK since all our sieve
requests use a private internal network space. We will just have to
figure out a solution before we can move our IMAP servers to VMs in
remote hosts.
Andy Dorman

OK, this is weird...so I thought I could turn tls off by setting this in
backends.local.php:

$backends['sieve']['transport'][Ingo::RULE_ALL]['params']['usetls'] = false;

But even after restarting php-fpm and Apache2 I continue to get this log
error:

HORDE: [ingo] PHP ERROR: stream_socket_enable_crypto(): Peer certificate
CN=`mail.fanmail.com' did not match expected
CN=`yorick.ironicdesign.com' [pid 26624 on line 1215 of
"/usr/share/php/Net/Sieve.php"]

and the user still sees the error alert I mentioned above.

Interestingly enough, the changes that trigger the error are successful.
If it wasn't for the PHP ERROR log line and the alert to the user, there
would be no problem.

I apologize for not mentioning this before, but this is a Debian setup
with Horde Groupware Webmail Edition 5.2.16 (Horde 5.2.12, Imp 6.2.16 &
Ingo 3.2.12) and Cyrus IMAP 2.5.10.

Andy Dorman

[Grouchy Sysadmin]

Post by Andy Dorman

Post by Andy Dorman

Post by Andy Dorman
We have several servers that support a spam/virus filtering service
and an email service of a different name. The email filtering and
email hosting services use different domain names and the server host
names use a third, our company domain name.
The problem happens when Ingo tries to use TLS to connect and the
certificate is for the email hosting service (mail.FanMail.com) and
the server name is for our company (IronicDesign.com).
This causes PHP to complain as shown here
HORDE: [ingo] PHP ERROR: stream_socket_enable_crypto(): Peer
certificate CN=`mail.fanmail.com' did not match expected
CN=`yorick.ironicdesign.com' [pid 26001 on line 1215 of
"/usr/share/php/Net/Sieve.php"]
and the user sees an error: "Script not updated: There was an error
activating the script. The driver said: Failed to establish TLS
connection"
After Googling I found where I can tell PHP to not verify the peer
$conf['ssl']['verify_peer'] = FALSE;
$conf['ssl']['verify_peer_name'] = FALSE;
OR I could possibly tell Ingo to use the mail.fanmail.com certificate?
I am trying to figure out which approach will work and how to apply
it. I would prefer to use ingo/backends.local.php which we already use
to set the appropriate host name for a user to connect to.

In that case, you should set the hostspec to 'mail.fanmail.com'. Of
course, that name should (DNS) resolve to the IP address of the server
where Sieve is living.
<?php
$backends['imap']['disabled'] = true;
$backends['sieve']['disabled'] = false;
$backends['sieve']['transport'][Ingo::RULE_ALL]['params']['hostspec'] =
'mail.fanmail.com';
Of course, the certificate on the server should contain
CN='mail.fanmail.com'. TLS doesn't care about hostname greetings, the
verification process uses the CN in the certificate and must match the
(forward) DNS record of that CN (reverse is not required).

Post by Andy Dorman
However, I can not find an option like these below in our current
backends.local.php to tell Ingo or PHP to use the 'mail.fanmail.com'
certificate.
$backends['sieve']['transport'][Ingo::RULE_ALL]['params']['logintype']
= 'PLAIN';
$backends['sieve']['transport'][Ingo::RULE_ALL]['params']['usetls'] =
true;
$backends['sieve']['transport'][Ingo::RULE_ALL]['params']['port'] = 4190;
I suppose a third option is to set 'usetls' to false, but I would
prefer not to do that as some day we hope to move our mail servers
into VMs outside our local network.
Thanks for any help.
--
Andy Dorman

Sorry, I would love to do that, but it won't work. We have a bunch of
servers that are all doing email+sieve for mail.fanmail.com users and
domain.
When the user logs into webmail, the Imp/Ingo client does an LDAP lookup
(in backends.local.php) for the specific server/host that contains that
user's email+sieve scripts. That email+sieve server
(yorick.ironicdesign.com in my log line above) has to be used in the
hostspec so Imp and Ingo pass their requests to the correct server.
So I have to set hostspec to be the physical server, but the SSL
certificate is for the service, mail.fanmail.com.
For now I suppose I will turn off tls. That is OK since all our sieve
requests use a private internal network space. We will just have to
figure out a solution before we can move our IMAP servers to VMs in
remote hosts.
Andy Dorman

OK, this is weird...so I thought I could turn tls off by setting this in
$backends['sieve']['transport'][Ingo::RULE_ALL]['params']['usetls'] = false;
But even after restarting php-fpm and Apache2 I continue to get this log
HORDE: [ingo] PHP ERROR: stream_socket_enable_crypto(): Peer certificate
CN=`mail.fanmail.com' did not match expected
CN=`yorick.ironicdesign.com' [pid 26624 on line 1215 of
"/usr/share/php/Net/Sieve.php"]
and the user still sees the error alert I mentioned above.
Interestingly enough, the changes that trigger the error are successful.
If it wasn't for the PHP ERROR log line and the alert to the user, there
would be no problem.
I apologize for not mentioning this before, but this is a Debian setup
with Horde Groupware Webmail Edition 5.2.16 (Horde 5.2.12, Imp 6.2.16 &
Ingo 3.2.12) and Cyrus IMAP 2.5.10.
Andy Dorman

Hi Andy,

Is Cyrus trying to establish a TLS connection first? That might be what
is causing the user visible error. I had a similar issue, and had to
white list the Ingo server for cleartext connections from Dovecot.

[Andy Dorman]

Post by Grouchy Sysadmin

Post by Andy Dorman

Post by Andy Dorman

Post by Andy Dorman
We have several servers that support a spam/virus filtering service
and an email service of a different name. The email filtering and
email hosting services use different domain names and the server host
names use a third, our company domain name.
The problem happens when Ingo tries to use TLS to connect and the
certificate is for the email hosting service (mail.FanMail.com) and
the server name is for our company (IronicDesign.com).
This causes PHP to complain as shown here
HORDE: [ingo] PHP ERROR: stream_socket_enable_crypto(): Peer
certificate CN=`mail.fanmail.com' did not match expected
CN=`yorick.ironicdesign.com' [pid 26001 on line 1215 of
"/usr/share/php/Net/Sieve.php"]
and the user sees an error: "Script not updated: There was an error
activating the script. The driver said: Failed to establish TLS
connection"
After Googling I found where I can tell PHP to not verify the peer
$conf['ssl']['verify_peer'] = FALSE;
$conf['ssl']['verify_peer_name'] = FALSE;
OR I could possibly tell Ingo to use the mail.fanmail.com certificate?
I am trying to figure out which approach will work and how to apply
it. I would prefer to use ingo/backends.local.php which we already use
to set the appropriate host name for a user to connect to.

In that case, you should set the hostspec to 'mail.fanmail.com'. Of
course, that name should (DNS) resolve to the IP address of the server
where Sieve is living.
<?php
$backends['imap']['disabled'] = true;
$backends['sieve']['disabled'] = false;
$backends['sieve']['transport'][Ingo::RULE_ALL]['params']['hostspec'] =
'mail.fanmail.com';
Of course, the certificate on the server should contain
CN='mail.fanmail.com'. TLS doesn't care about hostname greetings, the
verification process uses the CN in the certificate and must match the
(forward) DNS record of that CN (reverse is not required).

Post by Andy Dorman
However, I can not find an option like these below in our current
backends.local.php to tell Ingo or PHP to use the 'mail.fanmail.com'
certificate.
$backends['sieve']['transport'][Ingo::RULE_ALL]['params']['logintype']
= 'PLAIN';
$backends['sieve']['transport'][Ingo::RULE_ALL]['params']['usetls'] =
true;
$backends['sieve']['transport'][Ingo::RULE_ALL]['params']['port'] = 4190;
I suppose a third option is to set 'usetls' to false, but I would
prefer not to do that as some day we hope to move our mail servers
into VMs outside our local network.
Thanks for any help.
--
Andy Dorman

Sorry, I would love to do that, but it won't work. We have a bunch of
servers that are all doing email+sieve for mail.fanmail.com users and
domain.
When the user logs into webmail, the Imp/Ingo client does an LDAP lookup
(in backends.local.php) for the specific server/host that contains that
user's email+sieve scripts. That email+sieve server
(yorick.ironicdesign.com in my log line above) has to be used in the
hostspec so Imp and Ingo pass their requests to the correct server.
So I have to set hostspec to be the physical server, but the SSL
certificate is for the service, mail.fanmail.com.
For now I suppose I will turn off tls. That is OK since all our sieve
requests use a private internal network space. We will just have to
figure out a solution before we can move our IMAP servers to VMs in
remote hosts.
Andy Dorman

OK, this is weird...so I thought I could turn tls off by setting this in
$backends['sieve']['transport'][Ingo::RULE_ALL]['params']['usetls'] = false;
But even after restarting php-fpm and Apache2 I continue to get this log
HORDE: [ingo] PHP ERROR: stream_socket_enable_crypto(): Peer certificate
CN=`mail.fanmail.com' did not match expected
CN=`yorick.ironicdesign.com' [pid 26624 on line 1215 of
"/usr/share/php/Net/Sieve.php"]
and the user still sees the error alert I mentioned above.
Interestingly enough, the changes that trigger the error are successful.
If it wasn't for the PHP ERROR log line and the alert to the user, there
would be no problem.
I apologize for not mentioning this before, but this is a Debian setup
with Horde Groupware Webmail Edition 5.2.16 (Horde 5.2.12, Imp 6.2.16 &
Ingo 3.2.12) and Cyrus IMAP 2.5.10.
Andy Dorman

Hi Andy,
Is Cyrus trying to establish a TLS connection first? That might be what
is causing the user visible error. I had a similar issue, and had to
white list the Ingo server for cleartext connections from Dovecot.

You may be correct...just before the PHP ERROR log line I see this...

cyrus/sieve[26784]: starttls: TLSv1 with cipher ECDHE-RSA-AES128-SHA
(128/128 bits new) no authentication

That would certainly explain why turning it off in ingo is having no effect.

[Andy Dorman]

I don't see how this is ever going to work if you can't resolve the CN
of the certificate to the IP address of the server (which in your case
will never work). How can a client verify if the certificate a server
presents is for that server, other than by checking if one of the Common
Names matches a with the IP address of the server?

Post by Andy Dorman
For now I suppose I will turn off tls. That is OK since all our sieve
requests use a private internal network space. We will just have to
figure out a solution before we can move our IMAP servers to VMs in
remote hosts.

You'll have much more to figure out, since IMAP clients will not trust
the certificates either for the same reason above.

Strangely enough, IMAP through our nginx proxy (which also uses the
mail.fanmail.com SSL certificate) does the exact same LDAP lookup to
direct requests to the correct IMAP host and this handles TLS just fine.

Perhaps we need to adjust our webmail config to go through the nginx
proxy like all other external clients instead of trying to connect to
IMAP/Sieve direct on the correct server.

[Andy Dorman]

Post by Andy Dorman

I don't see how this is ever going to work if you can't resolve the CN
of the certificate to the IP address of the server (which in your case
will never work). How can a client verify if the certificate a server
presents is for that server, other than by checking if one of the Common
Names matches a with the IP address of the server?

Post by Andy Dorman
For now I suppose I will turn off tls. That is OK since all our sieve
requests use a private internal network space. We will just have to
figure out a solution before we can move our IMAP servers to VMs in
remote hosts.

You'll have much more to figure out, since IMAP clients will not trust
the certificates either for the same reason above.

Strangely enough, IMAP through our nginx proxy (which also uses the
mail.fanmail.com SSL certificate) does the exact same LDAP lookup to
direct requests to the correct IMAP host and this handles TLS just fine.
Perhaps we need to adjust our webmail config to go through the nginx
proxy like all other external clients instead of trying to connect to
IMAP/Sieve direct on the correct server.

Thanks Arien...you make a very good point.

So, instead of going direct to the specific server for ingo/sieve, I
modified our development server to use our Nginx front-end proxy just
like external IMAP clients do (and tls works fine for external IMAP
clients). Here are the updated settings in ingo/backends.local.php:

$backends['imap']['disabled'] = true;
$backends['sieve']['disabled'] = false;
$backends['sieve']['preferred'] = '';

$backends['sieve']['script'][Ingo::RULE_ALL]['driver'] = 'sieve';
$backends['sieve']['script'][Ingo::RULE_ALL]['params']['utf8'] = true;
$backends['sieve']['script'][Ingo::RULE_ALL]['params']['imapflags'] = true;
$backends['sieve']['script'][Ingo::RULE_ALL]['params']['notify'] = true;

$backends['sieve']['transport'][Ingo::RULE_ALL]['driver'] = 'timsieved';
$backends['sieve']['transport'][Ingo::RULE_ALL]['params']['hostspec'] =
'mail.fanmail.com';
$backends['sieve']['transport'][Ingo::RULE_ALL]['params']['logintype'] =
'PLAIN';
$backends['sieve']['transport'][Ingo::RULE_ALL]['params']['usetls'] = true;
$backends['sieve']['transport'][Ingo::RULE_ALL]['params']['port'] = 4190;
$backends['sieve']['transport'][Ingo::RULE_ALL]['params']['scriptname']
= 'ingo';

Now the PHP ERROR log entry is gone and sieve filter changes work (FWIW
they always worked but they still do), but the user error notification
on the web page still pops up.

We actually see 2 notifications that seem to contradict:

- Changes saved.
- Script not updated: There was an error activating the script. The
driver said: Connection refused.

I am NOT a PHP expert, but I am going to do some code diving and see if
I can figure out what is causing the error notification even when
everything works. Since this is not happening to anyone else there must
be something else I am missing in my configuration.

Again, this is a Debian setup with Horde Groupware Webmail Edition
5.2.16 (Horde 5.2.12, Imp 6.2.16 & Ingo 3.2.12), Cyrus IMAP 2.5.10 and
PHP 5.6.26.

[Vilius Sumskas/LNK]

Post by Andy Dorman

Post by Andy Dorman

I don't see how this is ever going to work if you can't resolve the CN
of the certificate to the IP address of the server (which in your case
will never work). How can a client verify if the certificate a server
presents is for that server, other than by checking if one of the Common
Names matches a with the IP address of the server?

Post by Andy Dorman
For now I suppose I will turn off tls. That is OK since all our sieve
requests use a private internal network space. We will just have to
figure out a solution before we can move our IMAP servers to VMs in
remote hosts.

You'll have much more to figure out, since IMAP clients will not trust
the certificates either for the same reason above.

Strangely enough, IMAP through our nginx proxy (which also uses the
mail.fanmail.com SSL certificate) does the exact same LDAP lookup to
direct requests to the correct IMAP host and this handles TLS just fine.
Perhaps we need to adjust our webmail config to go through the nginx
proxy like all other external clients instead of trying to connect to
IMAP/Sieve direct on the correct server.

Thanks Arien...you make a very good point.
So, instead of going direct to the specific server for ingo/sieve, I
modified our development server to use our Nginx front-end proxy just
like external IMAP clients do (and tls works fine for external IMAP
$backends['imap']['disabled'] = true;
$backends['sieve']['disabled'] = false;
$backends['sieve']['preferred'] = '';
$backends['sieve']['script'][Ingo::RULE_ALL]['driver'] = 'sieve';
$backends['sieve']['script'][Ingo::RULE_ALL]['params']['utf8'] = true;
$backends['sieve']['script'][Ingo::RULE_ALL]['params']['imapflags'] = true;
$backends['sieve']['script'][Ingo::RULE_ALL]['params']['notify'] = true;
$backends['sieve']['transport'][Ingo::RULE_ALL]['driver'] = 'timsieved';
$backends['sieve']['transport'][Ingo::RULE_ALL]['params']['hostspec'] =
'mail.fanmail.com';
$backends['sieve']['transport'][Ingo::RULE_ALL]['params']['logintype'] =
'PLAIN';
$backends['sieve']['transport'][Ingo::RULE_ALL]['params']['usetls'] = true;
$backends['sieve']['transport'][Ingo::RULE_ALL]['params']['port'] = 4190;

Does your Nginx proxy actually listens on that port? FWIW I don't think
Nginx supports proxying of Sieve protocol.

https://lists.andrew.cmu.edu/pipermail/info-cyrus/2013-December/037112.html

Post by Andy Dorman
$backends['sieve']['transport'][Ingo::RULE_ALL]['params']['scriptname']
= 'ingo';
Now the PHP ERROR log entry is gone and sieve filter changes work (FWIW
they always worked but they still do), but the user error notification
on the web page still pops up.
- Changes saved.
- Script not updated: There was an error activating the script. The
driver said: Connection refused.

Changes get saved to local Horde store (cache), but they are not sent to
sieve probably.

Post by Andy Dorman
I am NOT a PHP expert, but I am going to do some code diving and see if
I can figure out what is causing the error notification even when
everything works. Since this is not happening to anyone else there must
be something else I am missing in my configuration.
Again, this is a Debian setup with Horde Groupware Webmail Edition
5.2.16 (Horde 5.2.12, Imp 6.2.16 & Ingo 3.2.12), Cyrus IMAP 2.5.10 and
PHP 5.6.26.

[Andy Dorman]

Post by Andy Dorman

Post by Andy Dorman

I don't see how this is ever going to work if you can't resolve the

CN

Post by Andy Dorman

Post by Andy Dorman

of the certificate to the IP address of the server (which in your

case

Post by Andy Dorman

Post by Andy Dorman

will never work). How can a client verify if the certificate a server
presents is for that server, other than by checking if one of the

Common

Post by Andy Dorman

Post by Andy Dorman

Names matches a with the IP address of the server?

Post by Andy Dorman
For now I suppose I will turn off tls. That is OK since all our

sieve

Post by Andy Dorman

Post by Andy Dorman

Post by Andy Dorman
requests use a private internal network space. We will just have to
figure out a solution before we can move our IMAP servers to VMs in
remote hosts.

You'll have much more to figure out, since IMAP clients will not

trust

Post by Andy Dorman

Post by Andy Dorman

the certificates either for the same reason above.

Strangely enough, IMAP through our nginx proxy (which also uses the
mail.fanmail.com SSL certificate) does the exact same LDAP lookup to
direct requests to the correct IMAP host and this handles TLS just

fine.

Post by Andy Dorman

Post by Andy Dorman
Perhaps we need to adjust our webmail config to go through the nginx
proxy like all other external clients instead of trying to connect to
IMAP/Sieve direct on the correct server.

Thanks Arien...you make a very good point.
So, instead of going direct to the specific server for ingo/sieve, I
modified our development server to use our Nginx front-end proxy just
like external IMAP clients do (and tls works fine for external IMAP
$backends['imap']['disabled'] = true;
$backends['sieve']['disabled'] = false;
$backends['sieve']['preferred'] = '';
$backends['sieve']['script'][Ingo::RULE_ALL]['driver'] = 'sieve';
$backends['sieve']['script'][Ingo::RULE_ALL]['params']['utf8'] = true;
$backends['sieve']['script'][Ingo::RULE_ALL]['params']['imapflags'] =

true;

Post by Andy Dorman
$backends['sieve']['script'][Ingo::RULE_ALL]['params']['notify'] = true;
$backends['sieve']['transport'][Ingo::RULE_ALL]['driver'] = 'timsieved';
$backends['sieve']['transport'][Ingo::RULE_ALL]['params']['hostspec'] =
'mail.fanmail.com';
$backends['sieve']['transport'][Ingo::RULE_ALL]['params']['logintype'] =
'PLAIN';
$backends['sieve']['transport'][Ingo::RULE_ALL]['params']['usetls'] =

true;

Post by Andy Dorman
$backends['sieve']['transport'][Ingo::RULE_ALL]['params']['port'] =

4190;
Does your Nginx proxy actually listens on that port? FWIW I don't think
Nginx supports proxying of Sieve protocol.
https://lists.andrew.cmu.edu/pipermail/info-cyrus/2013-December/037112.html

Post by Andy Dorman
$backends['sieve']['transport'][Ingo::RULE_ALL]['params']['scriptname']
= 'ingo';
Now the PHP ERROR log entry is gone and sieve filter changes work (FWIW
they always worked but they still do), but the user error notification
on the web page still pops up.
- Changes saved.
- Script not updated: There was an error activating the script. The
driver said: Connection refused.

Changes get saved to local Horde store (cache), but they are not sent to
sieve probably.

Post by Andy Dorman
I am NOT a PHP expert, but I am going to do some code diving and see if
I can figure out what is causing the error notification even when
everything works. Since this is not happening to anyone else there must
be something else I am missing in my configuration.
Again, this is a Debian setup with Horde Groupware Webmail Edition
5.2.16 (Horde 5.2.12, Imp 6.2.16 & Ingo 3.2.12), Cyrus IMAP 2.5.10 and
PHP 5.6.26.

Good catch Vilius. You are correct that Nginx does not listen on port
4190 and it looks like it will not support the sieve traffic. I feel
like a real dummy.

I have reverted my backend config to go direct to the server and
disabled tls. This is currently not a security issue since all sieve
traffic is on the cluster local network. Now the user does not get an
error and PHP is happy.

However, if we ever want to move our webmail service to a VM outside our
local net we will either have to figure out how to tell sieve to use a
certificate for the hostname or tell PHP to accept the service
certificate instead of the hostname certificate.

Thank you everyone for your help and suggestions.