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

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

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

        (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]> qp 511025 uid 89

2020-10-15 14:29:58.418336500 starting delivery 1: msg 8428251 to 

remote [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]>_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]

For additional commands, e-mail: 

[email protected]

 

 

 

---------------------------------------------------------------------

To unsubscribe, e-mail: [email protected]

For additional commands, e-mail: 

[email protected]

 

 

---------------------------------------------------------------------

To unsubscribe, e-mail: [email protected]

For additional commands, e-mail: 

[email protected]

 

 

 

---------------------------------------------------------------------

To unsubscribe, e-mail: [email protected]

For additional commands, e-mail: [email protected]

 

 

---------------------------------------------------------------------

To unsubscribe, e-mail: [email protected]

For additional commands, e-mail: [email protected]

 

 

 

---------------------------------------------------------------------

To unsubscribe, e-mail: [email protected]

For additional commands, e-mail: [email protected]

 

 

Reply via email to