Re: [qmailtoaster] Authentication issues with Squirrelmail and RoundCube

2019-07-23 Thread Andrew Swartz 

Angus,

That is an intriguing error.

SNI adoption has been very slow for email.  Dovecot supports it for 
POP3/IMAP clients.  Opensmtpd may be the only SMTP server which supports it.


The workaround SMTP behavior has been to look up the MX record of the 
"To:" domain, and then connect to THAT server and verify ITS 
certificate.  So contrary to HTTP where the verified certificate MUST 
match the requested domain name, mail only requires that the certificate 
match the server pointed to by the MX record (regardless of message's 
"To:" domain).


So in general, "SNI" does not come up in discussions of mail server 
certificates.


And thus your error message is quite intriguing.

Can you modify the perl script to output verbose information?


-Andy




On 7/23/2019 5:04 AM, Angus McIntyre wrote:

r...@mattei.org wrote on 7/22/19 11:06 PM:
 > I am not sure why you keep having all this issues. Let me
 > know off line maybe I can take a look.

Thanks, Remo. I think I may be getting closer to a fix.

The issues I was having with PHP/Roundcube installation turned out to be 
because I had the IUS repo enabled, and that was introducing conflicts. 
I've now managed to work past that.


My new problems look like a certificate issue, and I think the problem 
is that my certificate requires SNI.


If I run:

   perl analyze-ssl.pl mail.mydomain.dev:465

I get:

    * SNI supported    : certificate verify fails without SNI
    * certificate verified : FAIL: SSL connect attempt failed
    error:14007086:SSL routines:CONNECT_CR_CERT:certificate verify failed

whereas if I do:

   perl analyze-ssl.pl mail.mydomain.dev:443

I get:

   * SNI supported    : ok
   * certificate verified : ok

I'm using the same certificate for securing the webserver (port 443) and 
SMTPS (port 465). The webserver works fine, probably because Apache is 
passing the requested hostname to Server Name Indication; SMTPS fails 
with a certificate error, probably because there's no hostname passed to 
SNI, and the server's intrinsic hostname (s6.mydomain.com) doesn't match 
the name on the certificate.


Things I'm going to try:

   1. Adding 'mail.mydomain.dev' to /etc/hosts
   2. Using a self-signed certificate signed to 's6.mydomain.com'.
   3. Buying another certificate specifically for 's6.mydomain.com'

Sound reasonable?

Angus



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 
* SNI supported    : certificate verify fails without SNI
  * certificate verified : FAIL: SSL connect attempt failed 
error:14007086:SSL routines:CONNECT_CR_CERT:certificate verify failed




On Mon, Jul 22, 2019 at 5:46 PM -0600, "Angus McIntyre" 
mailto:an...@pobox.com>> 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

Re: [qmailtoaster] Authentication issues with Squirrelmail and RoundCube

2019-07-23 Thread remo 
You do not have to buy a new cert use let’s encrypt or self sign it works just 
fine. 

> Il giorno 23 lug 2019, alle ore 06:04, Angus McIntyre  ha 
> scritto:
> 
> r...@mattei.org wrote on 7/22/19 11:06 PM:
> > I am not sure why you keep having all this issues. Let me
> > know off line maybe I can take a look.
> 
> Thanks, Remo. I think I may be getting closer to a fix.
> 
> The issues I was having with PHP/Roundcube installation turned out to be 
> because I had the IUS repo enabled, and that was introducing conflicts. I've 
> now managed to work past that.
> 
> My new problems look like a certificate issue, and I think the problem is 
> that my certificate requires SNI.
> 
> If I run:
> 
>  perl analyze-ssl.pl mail.mydomain.dev:465
> 
> I get:
> 
>   * SNI supported: certificate verify fails without SNI
>   * certificate verified : FAIL: SSL connect attempt failed
>   error:14007086:SSL routines:CONNECT_CR_CERT:certificate verify failed
> 
> whereas if I do:
> 
>  perl analyze-ssl.pl mail.mydomain.dev:443
> 
> I get:
> 
>  * SNI supported: ok
>  * certificate verified : ok
> 
> I'm using the same certificate for securing the webserver (port 443) and 
> SMTPS (port 465). The webserver works fine, probably because Apache is 
> passing the requested hostname to Server Name Indication; SMTPS fails with a 
> certificate error, probably because there's no hostname passed to SNI, and 
> the server's intrinsic hostname (s6.mydomain.com) doesn't match the name on 
> the certificate.
> 
> Things I'm going to try:
> 
>  1. Adding 'mail.mydomain.dev' to /etc/hosts
>  2. Using a self-signed certificate signed to 's6.mydomain.com'.
>  3. Buying another certificate specifically for 's6.mydomain.com'
> 
> Sound reasonable?
> 
> Angus
> 
> 
> 
 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 
>>> * SNI supported: certificate verify fails without SNI
> * certificate verified : FAIL: SSL connect attempt failed error:14007086:SSL 
> routines:CONNECT_CR_CERT:certificate verify failed
>>> 
>>> 
>>> 
 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

Re: [qmailtoaster] Authentication issues with Squirrelmail and RoundCube

2019-07-23 Thread Eric Broch 
Do you have a script in /home/vpopmail/domain/yourdomain.com/user, 
perhaps a .qmail file with .mailfilter script?


On 7/23/2019 7:48 AM, Tahnan Al Anas wrote:

Hi Eric,

Thank you for your reply. The issue is happening in webmail. I am 
using roundcube, squirrel mail, rain loop and after logic webmail. 
Some user use Microsoft outlook. But mail that received by server 
going to squirrel, roundcube spam folder, for which client unable to 
get it in their outlook inbox. I have increased simscan hit from 12 to 
80 to test, also whilst domain. You have any idea why it might happen?


On Tue, 23 Jul 2019, 6:50 pm Eric Broch, > wrote:


Hi Muhammad,

I don't think QMT 'naturally' any mail to spam folder. Is this
perhaps a client setting? What email client are they using?

Eric

On 7/23/2019 1:53 AM, Tahnan Al Anas wrote:

Hi,

Some of my user are getting mail at their spam box from some
domain. Can you suggest what can be done to prevent mail getting
delivered at spam box? They prefer to get it in inbox.


--
--

Best Regards
Muhammad Tahnan Al Anas


On Tue, Jul 23, 2019 at 8:41 AM Eric's mail
mailto:ebr...@whitehorsetc.com>> wrote:

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"
mailto:an...@pobox.com>> 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.1s6.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.1s2.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

Re: [qmailtoaster] Rainloop and folders (was: Re: [qmailtoaster] Authentication issues with Squirrelmail and RoundCube)

2019-07-23 Thread Eric Broch 

The Fix:

https://github.com/RainLoop/rainloop-webmail/issues/978

Edit file,

/usr/share/rainloop/data/_data_/_default_/configs/application.ini

change setting,

imap_folder_list_limit = 200 // 0 is off


Eric



On 7/23/2019 7:38 AM, Eric Broch wrote:


*You have too many folders!*
We have shown only a part of them, to avoid performance problems.

Re: [qmailtoaster] Authentication issues with Squirrelmail and RoundCube

2019-07-23 Thread Tahnan Al Anas 
Hi Eric,

Thank you for your reply. The issue is happening in webmail. I am using
roundcube, squirrel mail, rain loop and after logic webmail. Some user use
Microsoft outlook. But mail that received by server going to squirrel,
roundcube spam folder, for which client unable to get it in their outlook
inbox. I have increased simscan hit from 12 to 80 to test, also whilst
domain. You have any idea why it might happen?

On Tue, 23 Jul 2019, 6:50 pm Eric Broch,  wrote:

> Hi Muhammad,
>
> I don't think QMT 'naturally' any mail to spam folder. Is this perhaps a
> client setting? What email client are they using?
>
> Eric
> On 7/23/2019 1:53 AM, Tahnan Al Anas wrote:
>
> Hi,
>
> Some of my user are getting mail at their spam box from some domain. Can
> you suggest what can be done to prevent mail getting delivered at spam box?
> They prefer to get it in inbox.
>
>
> --
> --
>
> Best Regards
> Muhammad Tahnan Al Anas
>
>
> On Tue, Jul 23, 2019 at 8:41 AM Eric's mail 
> wrote:
>
>> 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
>>>

Re: [qmailtoaster] Rainloop and folders (was: Re: [qmailtoaster] Authentication issues with Squirrelmail and RoundCube)

2019-07-23 Thread Eric Broch 

*You have too many folders!*
We have shown only a part of them, to avoid performance problems.

On 7/23/2019 7:32 AM, Angus McIntyre wrote:
Eric Broch wrote on 7/23/19 8:58 AM:> Also, as a side note Rainloop 
refuses to display one of my folders which

roundcube and squirrelmail do display. Has anyone else seen this?


I found that with Rainloop, you need to specifically switch on the 
folders that you want to see in the sidebar. Pre-existing folders 
aren't displayed simply because they happen to be there.


Go to 'Settings', choose 'Folders' and click the eye icon next to the 
folder(s) you want to show.


I think that Rainloop won't let you enable folders that contain other 
folders, so if you have for example:


   Folder1
 Folder2

you will be able to enable Folder2, and Folder1 will show up in the 
sidebar as its parent -- but it won't be a full-fledged mailbox in its 
own right. If there's any mail in Folder1, you probably won't be able 
to see it.


You may be encountering a different issue, in which case, ¯\_(ツ)_/¯, 
this is all I have. But if you haven't tried 'switching on' the 
folders in Rainloop's settings already, try that first.


Angus


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

[qmailtoaster] Rainloop and folders (was: Re: [qmailtoaster] Authentication issues with Squirrelmail and RoundCube)

2019-07-23 Thread Angus McIntyre 
Eric Broch wrote on 7/23/19 8:58 AM:> Also, as a side note Rainloop 
refuses to display one of my folders which

roundcube and squirrelmail do display. Has anyone else seen this?


I found that with Rainloop, you need to specifically switch on the 
folders that you want to see in the sidebar. Pre-existing folders aren't 
displayed simply because they happen to be there.


Go to 'Settings', choose 'Folders' and click the eye icon next to the 
folder(s) you want to show.


I think that Rainloop won't let you enable folders that contain other 
folders, so if you have for example:


   Folder1
 Folder2

you will be able to enable Folder2, and Folder1 will show up in the 
sidebar as its parent -- but it won't be a full-fledged mailbox in its 
own right. If there's any mail in Folder1, you probably won't be able to 
see it.


You may be encountering a different issue, in which case, ¯\_(ツ)_/¯, 
this is all I have. But if you haven't tried 'switching on' the folders 
in Rainloop's settings already, try that first.


Angus


-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] Authentication issues with Squirrelmail and RoundCube

2019-07-23 Thread Angus McIntyre 

r...@mattei.org wrote on 7/22/19 11:06 PM:
> I am not sure why you keep having all this issues. Let me
> know off line maybe I can take a look.

Thanks, Remo. I think I may be getting closer to a fix.

The issues I was having with PHP/Roundcube installation turned out to be 
because I had the IUS repo enabled, and that was introducing conflicts. 
I've now managed to work past that.


My new problems look like a certificate issue, and I think the problem 
is that my certificate requires SNI.


If I run:

  perl analyze-ssl.pl mail.mydomain.dev:465

I get:

   * SNI supported: certificate verify fails without SNI
   * certificate verified : FAIL: SSL connect attempt failed
   error:14007086:SSL routines:CONNECT_CR_CERT:certificate verify failed

whereas if I do:

  perl analyze-ssl.pl mail.mydomain.dev:443

I get:

  * SNI supported: ok
  * certificate verified : ok

I'm using the same certificate for securing the webserver (port 443) and 
SMTPS (port 465). The webserver works fine, probably because Apache is 
passing the requested hostname to Server Name Indication; SMTPS fails 
with a certificate error, probably because there's no hostname passed to 
SNI, and the server's intrinsic hostname (s6.mydomain.com) doesn't match 
the name on the certificate.


Things I'm going to try:

  1. Adding 'mail.mydomain.dev' to /etc/hosts
  2. Using a self-signed certificate signed to 's6.mydomain.com'.
  3. Buying another certificate specifically for 's6.mydomain.com'

Sound reasonable?

Angus



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 
* SNI supported: certificate verify fails without SNI
 * certificate verified : FAIL: SSL connect attempt failed 
error:14007086:SSL routines:CONNECT_CR_CERT:certificate verify failed




On Mon, Jul 22, 2019 at 5:46 PM -0600, "Angus McIntyre" 
mailto:an...@pobox.com>> 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

Re: [qmailtoaster] Authentication issues with Squirrelmail and RoundCube

2019-07-23 Thread Eric Broch 

Hi Angus,

If you're using webmail on any of those other clients HTTPS is a secure 
channel. YOU MUST MAKE SURE THAT YOUR APACHE SETTINGS FORCE HTTPS for 
each of our three webmail options, though. I cannot stress this enough.


Also, as a side note Rainloop refuses to display one of my folders which 
roundcube and squirrelmail do display. Has anyone else seen this?


Eric

On 7/23/2019 6:02 AM, Angus McIntyre wrote:

Hi Eric

Thanks for the suggestion. I think I'll certainly go that route for 
the webmail clients -- Roundcube, Rainloop and Squirrelmail -- for the 
reasons you suggest.


However, I also need to make this setup work with desktop and mobile 
clients like Apple Mail and Postbox, and they will need a secure 
channel to the server.


Thanks again,

Angus


On 2019-07-22 22:40, Eric's mail wrote:

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 [1]

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

Re: [qmailtoaster] Authentication issues with Squirrelmail and RoundCube

2019-07-23 Thread Eric Broch 

Hi Muhammad,

I don't think QMT 'naturally' any mail to spam folder. Is this perhaps a 
client setting? What email client are they using?


Eric

On 7/23/2019 1:53 AM, Tahnan Al Anas wrote:

Hi,

Some of my user are getting mail at their spam box from some domain. 
Can you suggest what can be done to prevent mail getting delivered at 
spam box? They prefer to get it in inbox.



--
--

Best Regards
Muhammad Tahnan Al Anas


On Tue, Jul 23, 2019 at 8:41 AM Eric's mail > wrote:


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"
mailto:an...@pobox.com>> 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.1s6.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.1s2.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.

Re: [qmailtoaster] Authentication issues with Squirrelmail and RoundCube

2019-07-23 Thread Angus McIntyre 

Hi Eric

Thanks for the suggestion. I think I'll certainly go that route for the 
webmail clients -- Roundcube, Rainloop and Squirrelmail -- for the 
reasons you suggest.


However, I also need to make this setup work with desktop and mobile 
clients like Apple Mail and Postbox, and they will need a secure channel 
to the server.


Thanks again,

Angus


On 2019-07-22 22:40, Eric's mail wrote:

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 [1]

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',

Re: [qmailtoaster] Authentication issues with Squirrelmail and RoundCube

2019-07-23 Thread Tahnan Al Anas 
Hi,

Some of my user are getting mail at their spam box from some domain. Can
you suggest what can be done to prevent mail getting delivered at spam box?
They prefer to get it in inbox.


--
--

Best Regards
Muhammad Tahnan Al Anas


On Tue, Jul 23, 2019 at 8:41 AM Eric's mail  wrote:

> 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
>> >>
>> >>

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

Re: [qmailtoaster] Authentication issues with Squirrelmail and RoundCube

2019-07-21 Thread Eric Broch 
Just as long as you have https set up for both roundcube and 
squirrelmail you could use port 25, tls is not necessary.


On 7/21/2019 9:02 PM, Angus McIntyre wrote:
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