[root@catchmail2 control]# ls -la /var/qmail/control/
total 132
drwxr-xr-x. 3 root qmail 4096 Oct 16 01:01 .
drwxr-xr-x. 13 root qmail 159 Oct 1 10:09 ..
-rw-r--r--. 1 root qmail 32 Sep 29 17:19 badloadertypes
-rw-r--r-- 1 root root 2048 Oct 9 15:08 badloadertypes.cdb
-rw-r--r--. 1 root qmail 25 Sep 29 17:19 badmailfrom
-rw-r--r--. 1 root qmail 29 Sep 29 17:19 badmailto
-rw-r--r--. 1 root qmail 360 Sep 29 17:19 badmimetypes
-rw-r--r-- 1 root root 2048 Oct 9 15:08 badmimetypes.cdb
lrwxrwxrwx. 1 root qmail 14 Sep 29 17:19 clientcert.pem ->
servercert.pem
-rw-r--r--. 1 root qmail 4 Sep 29 17:19 concurrencyincoming
-rw-r--r--. 1 root qmail 3 Sep 29 17:19 concurrencyremote
-rw-r--r--. 1 root qmail 9 Sep 29 17:19 databytes
-rw-r--r--. 1 root qmail 11 Sep 29 17:19 defaultdelivery
-rw-r--r--. 1 root qmail 14 Oct 1 10:07 defaultdomain
-rw-r--r--. 1 root qmail 14 Oct 1 10:07 defaulthost
-rw-r--r-- 1 root qmail 424 Oct 16 01:01 dh2048.pem
drwxr-xr-x. 2 qmailr qmail 202 Oct 8 11:15 dkim
-rw-r--r--. 1 root root 10 Oct 6 09:45 locals
-rw-------. 1 root root 0 Oct 1 10:09 locals.lock
-rw-r--r--. 1 root qmail 4 Sep 29 17:19 logcount
-rw-r--r--. 1 root qmail 8 Sep 29 17:19 logsize
-rw-r--r--. 1 root qmail 25 Oct 1 10:07 me
-rw-r-----. 1 root vchkpw 2830 Oct 1 10:07 orig-servercert.pem
-rw-r--r--. 1 root qmail 14 Oct 1 10:07 plusdomain
-rw-r--r--. 1 root qmail 0 Sep 29 17:19 policy
-rw-r--r--. 1 root qmail 6 Sep 29 17:19 queuelifetime
-rw-r--r--. 1 root root 251 Oct 6 09:45 rcpthosts
-rw-------. 1 root root 0 Oct 1 10:09 rcpthosts.lock
-rw-r--r-- 1 root qmail 1679 Oct 16 01:01 rsa2048.pem
-rw-r----- 1 root vchkpw 8934 Oct 15 16:43 servercert.pem
-rw-r--r--. 1 46 root 59 Dec 24 2013 simcontrol
-rw-r--r-- 1 root root 2129 Oct 9 15:08 simcontrol.cdb
-rw-r--r-- 1 root root 2166 Oct 9 15:08 simversions.cdb
-rw-r--r--. 1 root qmail 87 Oct 1 10:07 smtpgreeting
-rw-r--r--. 1 root qmail 0 Sep 29 17:19 smtproutes
-rw-r--r--. 1 root qmail 2 Sep 29 17:19 spfbehavior
lrwxrwxrwx. 1 root root 35 Oct 1 10:07 tlsclientciphers ->
/var/qmail/control/tlsserverciphers
-rw-r--r--. 1 root qmail 3285 Oct 1 10:07 tlsserverciphers
-rw-r--r--. 1 root root 452 Oct 6 09:45 virtualdomains
-rw-------. 1 root root 0 Oct 1 10:09 virtualdomains.lock
CheckTLS.com reports:
FAILED FAILED //email/test From: Your email was sent, however it was NOT
SENT SECURELY using TLS.
The log of the mail to checktls.com -
2020-10-16 07:14:48.069306500 new msg 8497405
2020-10-16 07:14:48.069309500 info msg 8497405: bytes 817 from
<[email protected]> qp 569418 uid 89
2020-10-16 07:14:48.069310500 starting delivery 87: msg 8497405 to
remote [email protected]
2020-10-16 07:14:48.069311500 status: local 0/10 remote 1/60
2020-10-16 07:14:48.521062500 delivery 87: success:
<[email protected]>_165.227.190.238_accepted_message./Remote_host_said:_250_Ok/
2020-10-16 07:14:48.521064500 status: local 0/10 remote 0/60
2020-10-16 07:14:48.521065500 end msg 8497405
2020-10-16 07:14:57.942882500 new msg 8497405
2020-10-16 07:14:57.942883500 info msg 8497405: bytes 2348 from
<[email protected]> qp 569438 uid 89
2020-10-16 07:14:57.942884500 starting delivery 88: msg 8497405 to local
[email protected]
2020-10-16 07:14:57.942885500 status: local 1/10 remote 0/60
2020-10-16 07:14:57.997390500 delivery 88: success:
lda([email protected]):_Error:_net_connect_unix(/var/run/dovecot/stats-writer)_failed:_Permission_denied/did_0+0+1/
2020-10-16 07:14:57.997392500 status: local 0/10 remote 0/60
2020-10-16 07:14:57.997393500 end msg 8497405
I obscured my public IP in the thread to 9.8.7.6, but the headers in the
gmail message show my mail server's IP, there is no smarthost that I am
aware of.
On 10/15/20 7:51 PM, Eric Broch wrote:
I can't remember a time when sending to gmail failed to produce a tls
connection. I don't wonder if there is a smarthost in between stopping it?
On 10/15/2020 5:23 PM, Jaime Lerner wrote:
An easier place to check is to go to checktls.com to get an excellent
output of your mailserver connection and whether it is using TLS.
Might help with trouble-shooting....
*From: *Eric Broch <[email protected]>
*Reply-To: *<[email protected]>
*Date: *Thursday, October 15, 2020 at 5:39 PM
*To: *<[email protected]>
*Subject: *Re: [qmailtoaster] QMT is not issuing a STARTTLS on
outbound SMTP
What's this look like
# ls -la /var/qmail/control
On 10/15/2020 2:54 PM, Jim McNamara wrote:
[root@catchmail2 control]# yum list installed | grep qmail
qmail.x86_64 1.03-3.3.1.qt.el8 @qmt-testing
qmailadmin.x86_64 1.2.16-5.1.qt.el8 @qmt-testing
qmailmrtg.x86_64 4.2-4.qt.el8 @qmt-testing
On 10/15/20 4:48 PM, Eric Broch wrote:
What version of qmail?
On 10/15/2020 2:47 PM, Jim McNamara wrote:
Received: from mymachine.tld (mymachine.tld. [9.8.7.6])
by mx.google.com with ESMTP id
p5si1775654qvb.199.2020.10.15.09.52.15
for <[email protected] <mailto:[email protected]>>;
Thu, 15 Oct 2020 09:52:15 -0700 (PDT)
Received: from mymachine.tld (mymachine.tld. [9.8.7.6])
by mx.google.com with ESMTP id
n10si156346qvl.1.2020.10.15.13.37.49
for <[email protected] <mailto:[email protected]>>;
Thu, 15 Oct 2020 13:37:49 -0700 (PDT)
No mention whatsoever of TLS, the next lines of the
headers begin:
Received-SPF: pass
On 10/15/20 3:32 PM, Eric Broch wrote:
Check the header of an email you've sent to Gmail
from your QMT,
you should see something like the following:
Received: from localhost (mx.mydomain.com.
[xxx.xxx.xxx.xxx])
by mx.google.com with ESMTPS id
be3si1766151plb.73.2020.10.15.11.34.29
for <[email protected]
<mailto:[email protected]>>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384
bits=256/256);
I'm sending from a CentOS 8/QMT I just fired up and
am testing.
Eric
On 10/15/2020 12:57 PM, Jim McNamara wrote:
Hello, list!
According to
http://www.qmailtoaster.net/notls.html , all
outbound
SMTP should be using TLS unless a domain is
configured explicitly
not use it. However, without even creating the
directory
/var/qmail/control/notlshosts every message I
send from my server
to gmail.com is going unencrypted. The
/var/log/qmail/send/current
file has entries like:
2020-10-15 14:29:58.418313500 new msg 8428251
2020-10-15 14:29:58.418315500 info msg 8428251:
bytes 574 from
<[email protected] <mailto:[email protected]>> qp
511025 uid 89
2020-10-15 14:29:58.418336500 starting delivery
1: msg 8428251 to
remote [email protected]
<mailto:[email protected]>
2020-10-15 14:29:58.418337500 status: local 0/10
remote 1/60
2020-10-15 14:29:59.220407500 delivery 1: success:
<[email protected]
<mailto:[email protected]>>_173.194.204.26_accepted_message./Remote_host_said:_250_2.0.0_OK__1602786599_w13si301qtv.16_-_gsmtp/
2020-10-15 14:29:59.220525500 status: local 0/10
remote 0/60
2020-10-15 14:29:59.220563500 end msg 8428251
The message in gmail shows up with the padlock
having a red line
through it, indicating it was not encrypted
during transit. Since
I see the 250 in the send log, I would assume
that should my
server attempt to use TLS, there should be a,
"starttls" getting
logged?
My /var/qmail/supervise/send/run file is simply:
#!/bin/sh
exec /var/qmail/rc
Did I do something wrong that outbound SMTP is
not even asking for
TLS?
---------------------------------------------------------------------
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]>
---------------------------------------------------------------------
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]>
---------------------------------------------------------------------
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]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
