Re: [qmailtoaster] Authentication issues with Squirrelmail and RoundCube

2019-07-22 Thread remo
I am not sure why you keep having all this issues. Let me know off line maybe I 
can take a look. 

> Il giorno 22 lug 2019, alle ore 19:41, Eric's mail  
> ha scritto:
> 
> 
> Angus,
> 
> Did you think about simply using port 25, no authentication or encryption, 
> which is how squirrelmail on QMT used to be configured, relying on HTTPS 
> alone for password and email security across the cloud as the email (after 
> the cloud) is submitted directly to the server (tcpserver) by the server 
> (apache) itself (127.0.0.1) rendering encryption useless or redundant. I 
> think this is the route I will go because with every upgrade of roundcube, 
> the webmail I prefer, there seems to be issues with past configurations.
> 
> Eric
> 
> Get Outlook for Android
> 
> 
> 
> 
>> On Mon, Jul 22, 2019 at 5:46 PM -0600, "Angus McIntyre"  
>> wrote:
>> 
>> r...@mattei.org wrote on 7/22/19 10:22 AM:
>>  > You need to install the cert on your machine. Does the /etc/hosts
>>  > have the name of your machine can you try to ping that name to
>>  > see if it resolves?
>> 
>> The certificate is installed.
>> 
>> The hostname in '/etc/hosts' resolves, and responds to pings.
>> 
>> 
>> I replaced the self-signed PEM that shipped with qmailtoaster with one 
>> that I made myself by concatenating the ‘.key’ and ‘.crt’ files from my 
>> server certificate. Inspecting the resulting .pem with ‘openssl x509 -in 
>> servercert.pem -text’ confirms that the resulting .pem is for the domain 
>> that I expect. File permissions and ownership are correct.
>> 
>> '/etc/hosts' for my newly-built server contains the following line:
>> 
>>127.0.1.1 s6.mydomain.com s6
>> 
>> (obviously, 'mydomain' is not the actual name here). The .pem file 
>> contains the lines:
>> 
>>Subject: OU=Domain Control Validated, OU=PositiveSSL, 
>> CN=mail.mydomain.dev
>> 
>> and
>> 
>>X509v3 Subject Alternative Name:
>>  DNS:mail.mydomain.dev, DNS:www.mail.mydomain.dev
>> 
>> 's6.mydomain.com' and 'mail.mydomain.dev' all resolve to the same IP.
>> 
>> My existing qmailtoaster server (running an older version of the 
>> software) has '/etc/hosts' containing:
>> 
>>127.0.1.1 s2.mydomain.com s2
>> 
>> and the .pem file contains:
>> 
>>Subject: OU=Domain Control Validated, OU=PositiveSSL Multi-Domain, 
>> CN=mydomain.com
>> 
>> and
>> 
>>X509v3 Subject Alternative Name:
>>  DNS:mydomain.com, DNS:mail.mydomain.com, DNS:www.mydomain.com
>> 
>> 's6.mydomain.com' resolves to the same IP as 'mail.mydomain.dev'; 
>> 's2.mydomain.com' resolves to the same IP as 'mail.mydomain.com'.
>> 
>> As far as I can see, the two situations are equivalent, with the slight 
>> difference that the official server name of the new box 
>> ('s6.mydomain.com') is not a subdomain of the domain in the PEM file 
>> ('mail.mydomain.dev'), whereas on the old box the name of the host 
>> ('s2.mydomain.com') is a subdomain of one of the domain names in the PEM 
>> file ('mydomain.com'). I don't know if this is a possible cause of my 
>> problems.
>> 
>> One other difference is that I don’t have a PTR record for 
>> 's6.mydomain.com'. An RDNS lookup on the IP of 's2.mydomain.com' will 
>> yield 's2.mydomain.com', but an RDNS lookup on the IP of 
>> 's6.mydomain.com' yields the FQDN of the Linode VM it runs on. Could 
>> that be an issue?
>> 
>> I'll keep digging on this, but if anyone has any suggestions of tests or 
>> tools I might use, I'd welcome your recommendations.
>> 
>> Thanks,
>> 
>> Angus
>> 
>> 
>> 
>> > 
>> >> Il giorno 21 lug 2019, alle ore 20:03, Angus McIntyre  ha scritto:
>> >>
>> >> Thanks to a great deal of help from Remi and Eric, I have now managed to 
>> >> get my Ansible role to the point where it can successfully build out a 
>> >> QMailToaster server running PHP 7.1 and RoundCube 1.4rc1.
>> >>
>> >> However, because nothing is ever that easy, RoundCube and SquirrelMail 
>> >> have now stopped sending mail (RainLoop works fine).
>> >>
>> >> 1) SquirrelMail
>> >>
>> >> SquirrelMail was installed from the qmailtoaster RPMs, using:
>> >>
>> >> yum --enablerepo=qmt-testing update
>> >> yum --enablerepo=qmt-devel update
>> >>
>> >> as on the homepage of qmailtoaster.com. After installation, I patched the 
>> >> Squirrelmail config and the smtps supervise as directed at:
>> >>
>> >> http://www.qmailtoaster.com/sqmailconfig.html
>> >>
>> >> Attempting to send from SquirrelMail produces the message:
>> >>
>> >> 0 Can't open SMTP stream
>> >>
>> >> The /var/log/qmail/smtps/current log shows:
>> >>
>> >>   2019-07-22 02:45:15.173127500 tcpserver: status: 1/100
>> >>   2019-07-22 02:45:15.179903500 tcpserver: pid 2843 from 127.0.0.1
>> >>   2019-07-22 02:45:15.179905500 tcpserver: ok 2843 s6:127.0.0.1:465
>> >> :127.0.0.1::58822
>> >>   2019-07-22 02:45:15.197381500 tcpserver: end 2843 status 256
>> >>   2019-07-22 02:45:15.197383500 tcpserver: status: 0/100
>> >>
>> >> 2) RoundCube
>> >>
>> >> RoundCube is 1.4rc1, installed from the 

Re: [qmailtoaster] Authentication issues with Squirrelmail and RoundCube

2019-07-22 Thread Eric's mail
Angus,




Did you think about simply using port 25, no authentication or encryption, 
which is how squirrelmail on QMT used to be configured, relying on HTTPS alone 
for password and email security across the cloud as the email (after the cloud) 
is submitted directly to the server (tcpserver) by the server (apache) itself 
(127.0.0.1) rendering encryption useless or redundant. I think this is the 
route I will go because with every upgrade of roundcube, the webmail I prefer, 
there seems to be issues with past configurations.




Eric




Get Outlook for Android







On Mon, Jul 22, 2019 at 5:46 PM -0600, "Angus McIntyre"  wrote:










r...@mattei.org wrote on 7/22/19 10:22 AM:
 > You need to install the cert on your machine. Does the /etc/hosts
 > have the name of your machine can you try to ping that name to
 > see if it resolves?

The certificate is installed.

The hostname in '/etc/hosts' resolves, and responds to pings.


I replaced the self-signed PEM that shipped with qmailtoaster with one 
that I made myself by concatenating the ‘.key’ and ‘.crt’ files from my 
server certificate. Inspecting the resulting .pem with ‘openssl x509 -in 
servercert.pem -text’ confirms that the resulting .pem is for the domain 
that I expect. File permissions and ownership are correct.

'/etc/hosts' for my newly-built server contains the following line:

   127.0.1.1 s6.mydomain.com s6

(obviously, 'mydomain' is not the actual name here). The .pem file 
contains the lines:

   Subject: OU=Domain Control Validated, OU=PositiveSSL, 
CN=mail.mydomain.dev

and

   X509v3 Subject Alternative Name:
 DNS:mail.mydomain.dev, DNS:www.mail.mydomain.dev

's6.mydomain.com' and 'mail.mydomain.dev' all resolve to the same IP.

My existing qmailtoaster server (running an older version of the 
software) has '/etc/hosts' containing:

   127.0.1.1 s2.mydomain.com s2

and the .pem file contains:

   Subject: OU=Domain Control Validated, OU=PositiveSSL Multi-Domain, 
CN=mydomain.com

and

   X509v3 Subject Alternative Name:
 DNS:mydomain.com, DNS:mail.mydomain.com, DNS:www.mydomain.com

's6.mydomain.com' resolves to the same IP as 'mail.mydomain.dev'; 
's2.mydomain.com' resolves to the same IP as 'mail.mydomain.com'.

As far as I can see, the two situations are equivalent, with the slight 
difference that the official server name of the new box 
('s6.mydomain.com') is not a subdomain of the domain in the PEM file 
('mail.mydomain.dev'), whereas on the old box the name of the host 
('s2.mydomain.com') is a subdomain of one of the domain names in the PEM 
file ('mydomain.com'). I don't know if this is a possible cause of my 
problems.

One other difference is that I don’t have a PTR record for 
's6.mydomain.com'. An RDNS lookup on the IP of 's2.mydomain.com' will 
yield 's2.mydomain.com', but an RDNS lookup on the IP of 
's6.mydomain.com' yields the FQDN of the Linode VM it runs on. Could 
that be an issue?

I'll keep digging on this, but if anyone has any suggestions of tests or 
tools I might use, I'd welcome your recommendations.

Thanks,

Angus



> 
>> Il giorno 21 lug 2019, alle ore 20:03, Angus McIntyre  ha scritto:
>>
>> Thanks to a great deal of help from Remi and Eric, I have now managed to 
>> get my Ansible role to the point where it can successfully build out a 
>> QMailToaster server running PHP 7.1 and RoundCube 1.4rc1.
>>
>> However, because nothing is ever that easy, RoundCube and SquirrelMail have 
>> now stopped sending mail (RainLoop works fine).
>>
>> 1) SquirrelMail
>>
>> SquirrelMail was installed from the qmailtoaster RPMs, using:
>>
>> yum --enablerepo=qmt-testing update
>> yum --enablerepo=qmt-devel update
>>
>> as on the homepage of qmailtoaster.com. After installation, I patched the 
>> Squirrelmail config and the smtps supervise as directed at:
>>
>> http://www.qmailtoaster.com/sqmailconfig.html
>>
>> Attempting to send from SquirrelMail produces the message:
>>
>> 0 Can't open SMTP stream
>>
>> The /var/log/qmail/smtps/current log shows:
>>
>>   2019-07-22 02:45:15.173127500 tcpserver: status: 1/100
>>   2019-07-22 02:45:15.179903500 tcpserver: pid 2843 from 127.0.0.1
>>   2019-07-22 02:45:15.179905500 tcpserver: ok 2843 s6:127.0.0.1:465
>> :127.0.0.1::58822
>>   2019-07-22 02:45:15.197381500 tcpserver: end 2843 status 256
>>   2019-07-22 02:45:15.197383500 tcpserver: status: 0/100
>>
>> 2) RoundCube
>>
>> RoundCube is 1.4rc1, installed from the remi-test repo. Following Eric's 
>> instructions, I edited '/etc/roundcubemail/config.inc.php' so that it 
>> contains:
>>
>>   $config['smtp_server'] = 'tls://mail.myhost.com';
>>
>>   $config['smtp_conn_options'] = array(
>>  'ssl' => array(
>> 'peer_name' => 'mail.myhost.com',
>> 'verify_peer'  => true,
>> 'verify_depth' => 3,
>> 'cafile'   => '/var/qmail/control/servercert.pem',
>>),
>>   );
>>
>> (where 'mail.myhost.com' is the actual name of my mailserver, as it appears 
>> in the 

Re: [qmailtoaster] Authentication issues with Squirrelmail and RoundCube

2019-07-22 Thread Angus McIntyre

r...@mattei.org wrote on 7/22/19 10:22 AM:
> You need to install the cert on your machine. Does the /etc/hosts
> have the name of your machine can you try to ping that name to
> see if it resolves?

The certificate is installed.

The hostname in '/etc/hosts' resolves, and responds to pings.


I replaced the self-signed PEM that shipped with qmailtoaster with one 
that I made myself by concatenating the ‘.key’ and ‘.crt’ files from my 
server certificate. Inspecting the resulting .pem with ‘openssl x509 -in 
servercert.pem -text’ confirms that the resulting .pem is for the domain 
that I expect. File permissions and ownership are correct.


'/etc/hosts' for my newly-built server contains the following line:

  127.0.1.1 s6.mydomain.com s6

(obviously, 'mydomain' is not the actual name here). The .pem file 
contains the lines:


  Subject: OU=Domain Control Validated, OU=PositiveSSL, 
CN=mail.mydomain.dev


and

  X509v3 Subject Alternative Name:
DNS:mail.mydomain.dev, DNS:www.mail.mydomain.dev

's6.mydomain.com' and 'mail.mydomain.dev' all resolve to the same IP.

My existing qmailtoaster server (running an older version of the 
software) has '/etc/hosts' containing:


  127.0.1.1 s2.mydomain.com s2

and the .pem file contains:

  Subject: OU=Domain Control Validated, OU=PositiveSSL Multi-Domain, 
CN=mydomain.com


and

  X509v3 Subject Alternative Name:
DNS:mydomain.com, DNS:mail.mydomain.com, DNS:www.mydomain.com

's6.mydomain.com' resolves to the same IP as 'mail.mydomain.dev'; 
's2.mydomain.com' resolves to the same IP as 'mail.mydomain.com'.


As far as I can see, the two situations are equivalent, with the slight 
difference that the official server name of the new box 
('s6.mydomain.com') is not a subdomain of the domain in the PEM file 
('mail.mydomain.dev'), whereas on the old box the name of the host 
('s2.mydomain.com') is a subdomain of one of the domain names in the PEM 
file ('mydomain.com'). I don't know if this is a possible cause of my 
problems.


One other difference is that I don’t have a PTR record for 
's6.mydomain.com'. An RDNS lookup on the IP of 's2.mydomain.com' will 
yield 's2.mydomain.com', but an RDNS lookup on the IP of 
's6.mydomain.com' yields the FQDN of the Linode VM it runs on. Could 
that be an issue?


I'll keep digging on this, but if anyone has any suggestions of tests or 
tools I might use, I'd welcome your recommendations.


Thanks,

Angus






Il giorno 21 lug 2019, alle ore 20:03, Angus McIntyre  ha 
scritto:

Thanks to a great deal of help from Remi and Eric, I have now managed to get 
my Ansible role to the point where it can successfully build out a QMailToaster 
server running PHP 7.1 and RoundCube 1.4rc1.

However, because nothing is ever that easy, RoundCube and SquirrelMail have now 
stopped sending mail (RainLoop works fine).

1) SquirrelMail

SquirrelMail was installed from the qmailtoaster RPMs, using:

yum --enablerepo=qmt-testing update
yum --enablerepo=qmt-devel update

as on the homepage of qmailtoaster.com. After installation, I patched the 
Squirrelmail config and the smtps supervise as directed at:

http://www.qmailtoaster.com/sqmailconfig.html

Attempting to send from SquirrelMail produces the message:

0 Can't open SMTP stream

The /var/log/qmail/smtps/current log shows:

  2019-07-22 02:45:15.173127500 tcpserver: status: 1/100
  2019-07-22 02:45:15.179903500 tcpserver: pid 2843 from 127.0.0.1
  2019-07-22 02:45:15.179905500 tcpserver: ok 2843 s6:127.0.0.1:465
:127.0.0.1::58822
  2019-07-22 02:45:15.197381500 tcpserver: end 2843 status 256
  2019-07-22 02:45:15.197383500 tcpserver: status: 0/100

2) RoundCube

RoundCube is 1.4rc1, installed from the remi-test repo. Following Eric's 
instructions, I edited '/etc/roundcubemail/config.inc.php' so that it contains:

  $config['smtp_server'] = 'tls://mail.myhost.com';

  $config['smtp_conn_options'] = array(
 'ssl' => array(
'peer_name' => 'mail.myhost.com',
'verify_peer'  => true,
'verify_depth' => 3,
'cafile'   => '/var/qmail/control/servercert.pem',
   ),
  );

(where 'mail.myhost.com' is the actual name of my mailserver, as it appears in 
the 'servercert.pem' file).

Trying to send from RoundCube produces a 220 Authentication Failed message. The 
transcript in RoundCube's SMTP log looks like:

  [21-Jul-2019 22:26:08 -0400]:  Connecting to
  tls://mail.myhost.com:587...
  [21-Jul-2019 22:26:08 -0400]:  Recv: 220 s6.myhost.net -
  Welcome to Qmail Toaster Ver. 1.03-2.1.qt.el7 SMTP Server ESMTP
  [21-Jul-2019 22:26:08 -0400]:  Send: EHLO mail.myhost.com
  [21-Jul-2019 22:26:08 -0400]:  Recv: 250-s6.myhost.net -
  Welcome to Qmail Toaster Ver. 1.03-2.1.qt.el7 SMTP Server
  [21-Jul-2019 22:26:08 -0400]:  Recv: 250-STARTTLS
  [21-Jul-2019 22:26:08 -0400]:  Recv: 250-PIPELINING
  [21-Jul-2019 22:26:08 -0400]:  Recv: 250-8BITMIME
  [21-Jul-2019 22:26:08 -0400]:  Recv: 250 SIZE 20971520
  [21-Jul-2019 22:26:08 -0400]:  Send: STARTTLS
 

Re: [qmailtoaster] Authentication issues with Squirrelmail and RoundCube

2019-07-22 Thread remo
You need to install the cert on your machine. Does the /etc/hosts have the name 
of your machine can you try to ping that name to see if it resolves? 

> Il giorno 21 lug 2019, alle ore 20:03, Angus McIntyre  ha 
> scritto:
> 
> Thanks to a great deal of help from Remi and Eric, I have now managed to get 
> my Ansible role to the point where it can successfully build out a 
> QMailToaster server running PHP 7.1 and RoundCube 1.4rc1.
> 
> However, because nothing is ever that easy, RoundCube and SquirrelMail have 
> now stopped sending mail (RainLoop works fine).
> 
> 1) SquirrelMail
> 
> SquirrelMail was installed from the qmailtoaster RPMs, using:
> 
>yum --enablerepo=qmt-testing update
>yum --enablerepo=qmt-devel update
> 
> as on the homepage of qmailtoaster.com. After installation, I patched the 
> Squirrelmail config and the smtps supervise as directed at:
> 
>http://www.qmailtoaster.com/sqmailconfig.html
> 
> Attempting to send from SquirrelMail produces the message:
> 
>0 Can't open SMTP stream
> 
> The /var/log/qmail/smtps/current log shows:
> 
>  2019-07-22 02:45:15.173127500 tcpserver: status: 1/100
>  2019-07-22 02:45:15.179903500 tcpserver: pid 2843 from 127.0.0.1
>  2019-07-22 02:45:15.179905500 tcpserver: ok 2843 s6:127.0.0.1:465
>:127.0.0.1::58822
>  2019-07-22 02:45:15.197381500 tcpserver: end 2843 status 256
>  2019-07-22 02:45:15.197383500 tcpserver: status: 0/100
> 
> 2) RoundCube
> 
> RoundCube is 1.4rc1, installed from the remi-test repo. Following Eric's 
> instructions, I edited '/etc/roundcubemail/config.inc.php' so that it 
> contains:
> 
>  $config['smtp_server'] = 'tls://mail.myhost.com';
> 
>  $config['smtp_conn_options'] = array(
> 'ssl' => array(
>'peer_name' => 'mail.myhost.com',
>'verify_peer'  => true,
>'verify_depth' => 3,
>'cafile'   => '/var/qmail/control/servercert.pem',
>   ),
>  );
> 
> (where 'mail.myhost.com' is the actual name of my mailserver, as it appears 
> in the 'servercert.pem' file).
> 
> Trying to send from RoundCube produces a 220 Authentication Failed message. 
> The transcript in RoundCube's SMTP log looks like:
> 
>  [21-Jul-2019 22:26:08 -0400]:  Connecting to
>  tls://mail.myhost.com:587...
>  [21-Jul-2019 22:26:08 -0400]:  Recv: 220 s6.myhost.net -
>  Welcome to Qmail Toaster Ver. 1.03-2.1.qt.el7 SMTP Server ESMTP
>  [21-Jul-2019 22:26:08 -0400]:  Send: EHLO mail.myhost.com
>  [21-Jul-2019 22:26:08 -0400]:  Recv: 250-s6.myhost.net -
>  Welcome to Qmail Toaster Ver. 1.03-2.1.qt.el7 SMTP Server
>  [21-Jul-2019 22:26:08 -0400]:  Recv: 250-STARTTLS
>  [21-Jul-2019 22:26:08 -0400]:  Recv: 250-PIPELINING
>  [21-Jul-2019 22:26:08 -0400]:  Recv: 250-8BITMIME
>  [21-Jul-2019 22:26:08 -0400]:  Recv: 250 SIZE 20971520
>  [21-Jul-2019 22:26:08 -0400]:  Send: STARTTLS
>  [21-Jul-2019 22:26:08 -0400]:  Recv: 220 ready for tls
>  [21-Jul-2019 22:26:08 -0400]:  Send: RSET
>  [21-Jul-2019 22:27:08 -0400]:  Send: QUIT
>  [21-Jul-2019 22:27:08 -0400]:  Recv: 454 TLS connection
>  failed: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown
>  protocol (#4.3.0)
> 
> 3) Desktop client
> 
> Trying to send from a desktop client (PostBox) also fails, generating the 
> warning:
> 
>  Could not verify this certificate because the issuer is unknown
> 
> The issuer in this case is actually Sectigo, which is the new name for 
> Comodo, who should be reasonably reputable.
> 
> The 'servercert.pem' file that I'm using is generated from the same '.key' 
> and '.crt' files that I use to secure the webserver, which appear to work 
> fine in that context.
> 
> 
> 
> Has anyone encountered this issue, or can suggest a possible fix?
> 
> Thanks for any help you can give me,
> 
> Angus
> 
> 
> 
> -
> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
> 
-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com