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
<[email protected]
<mailto:[email protected]>> 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 <https://aka.ms/ghei36>
On Mon, Jul 22, 2019 at 5:46 PM -0600, "Angus
McIntyre" <[email protected]
<mailto:[email protected]>> wrote:
[email protected] <mailto:[email protected]> 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 <http://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 <http://mail.mydomain.dev>
and
X509v3 Subject Alternative Name:
DNS:mail.mydomain.dev <http://mail.mydomain.dev>,
DNS:www.mail.mydomain.dev <http://www.mail.mydomain.dev>
's6.mydomain.com <http://s6.mydomain.com>' and'mail.mydomain.dev
<http://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 <http://s2.mydomain.com> s2
and the .pem file contains:
Subject: OU=Domain Control Validated, OU=PositiveSSL
Multi-Domain,
CN=mydomain.com <http://mydomain.com>
and
X509v3 Subject Alternative Name:
DNS:mydomain.com <http://mydomain.com>, DNS:mail.mydomain.com
<http://mail.mydomain.com>, DNS:www.mydomain.com <http://www.mydomain.com>
's6.mydomain.com <http://s6.mydomain.com>' resolves to the same
IP as'mail.mydomain.dev <http://mail.mydomain.dev>';
's2.mydomain.com <http://s2.mydomain.com>' resolves to the same
IP as'mail.mydomain.com <http://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 <http://s6.mydomain.com>') is not a
subdomain of the domain in the PEM file
('mail.mydomain.dev <http://mail.mydomain.dev>'), whereas
on the old box the name of the host
('s2.mydomain.com <http://s2.mydomain.com>') is a
subdomain of one of the domain names in the PEM
file ('mydomain.com <http://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 <http://s6.mydomain.com>'. An RDNS lookup on
the IP of's2.mydomain.com <http://s2.mydomain.com>' will
yield 's2.mydomain.com <http://s2.mydomain.com>', but an
RDNS lookup on the IP of
's6.mydomain.com <http://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
<http://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 <http://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
<http://mail.myhost.com>';
>>
>> $config['smtp_conn_options'] = array(
>> 'ssl' => array(
>> 'peer_name' => 'mail.myhost.com
<http://mail.myhost.com>',
>> 'verify_peer' => true,
>> 'verify_depth' => 3,
>> 'cafile' =>
'/var/qmail/control/servercert.pem',
>> ),
>> );
>>
>> (where 'mail.myhost.com <http://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
<http://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
<http://mail.myhost.com>
>> [21-Jul-2019 22:26:08 -0400]: Recv: 250-s6.myhost.net
<http://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:
[email protected]
<mailto:[email protected]>
>> For additional commands, e-mail:
[email protected]
<mailto:[email protected]>
>>
---------------------------------------------------------------------
To unsubscribe,
e-mail:[email protected]
<mailto:[email protected]>
For additional commands,
e-mail:[email protected]
<mailto:[email protected]>
