Re: [qmailtoaster] TLS connect fails; dh key too small

[Eric Broch]

There is no DH key implemented by the TLS code in qmail-remote. The DH 
key in /var/qmail/control is only used by qmail-smtp (incoming). What 
I've read seems to indicate that and adjustment needs to be made to 
openssl itself in /etc/pki/tls/openssl.cnf


From here:

https://github.com/louislam/uptime-kuma/issues/1331

and here:

https://stackoverflow.com/questions/36417224/openssl-dh-key-too-small-error

Set

|CipherString = DEFAULT@SECLEVEL=1 |

On 2/21/2023 6:23 AM, Andreas wrote:
TLS connect failed: error:141A318A:SSL routines:tls_process_ske_dhe:dh 
key too small

Re: [qmailtoaster] TLS issue with Spamdyke v5.0.1

[nowuknow]

This particular log was when I was testing idle timeout of 300 seconds 
in Spamdyke, thus the longer delay.


Overall, the server is not that busy (avg 1-1.5), but will keep an eye 
out for peak loads that may coincide with timeouts.



On 12/27/22 18:29, Eric Broch wrote:


It looks like the start of the connection at 18:37:41 and when the 
timeout occurs at 18:42:03 is a pretty big chunk of time. The idle 
timeout in you spamdyke file is 60 seconds. This doesn't sound like a 
problem with TLS. It seems like a problem with the time of 
negotiation. How busy is your server?




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

Re: [qmailtoaster] TLS issue with Spamdyke v5.0.1

[Eric Broch]

It looks like the start of the connection at 18:37:41 and when the 
timeout occurs at 18:42:03 is a pretty big chunk of time. The idle 
timeout in you spamdyke file is 60 seconds. This doesn't sound like a 
problem with TLS. It seems like a problem with the time of negotiation. 
How busy is your server?


On 12/27/2022 12:13 PM, nowuk...@gmail.com wrote:


Mistakenly, I ended up taking this conversation off the list. Here is 
the summary conclusion for anyone that may encounter a similar situation.


It appears to be mostly network issue. At Eric's advice, I downgraded 
Spamdyke and the delivery seemed to improve. I still see timeouts, as 
shown below, but in the end, Yahoo delivered the message below several 
minutes later. Notably, messages from Gmail sometimes show timeouts, 
but typically get delivered within minutes. I am still investigating 
potential networking issues causing the MX lookup to fail.


Thanks, again, to everyone who offered assistance.

Regards,

Ed


12/27/2022 18:37:41 - Remote rDNS = sonic315-13.consmr.mail.bf2.yahoo.com

12/27/2022 18:37:41 LOG OUTPUT
DEBUG(filter_rdns_missing()@filter.c:947): checking for missing rDNS; 
rdns: sonic315-13.consmr.mail.bf2.yahoo.com
DEBUG(filter_ip_in_rdns_cc()@filter.c:978): checking for IP in rDNS 
+country code; rdns: sonic315-13.consmr.mail.bf2.yahoo.com
DEBUG(filter_rdns_whitelist_file()@filter.c:1055): searching rDNS 
whitelist file(s); rdns: sonic315-13.consmr.mail.bf2.yahoo.com
DEBUG(filter_rdns_blacklist_file()@filter.c:1159): searching rDNS 
blacklist file(s); rdns: sonic315-13.consmr.mail.bf2.yahoo.com
DEBUG(filter_ip_whitelist()@filter.c:1228): searching IP whitelist 
file(s); ip: 74.6.134.123
DEBUG(filter_ip_blacklist()@filter.c:1279): searching IP blacklist 
file(s); ip: 74.6.134.123
DEBUG(filter_ip_in_rdns_whitelist()@filter.c:1380): checking for IP in 
rDNS +keyword(s) in whitelist file; ip: 74.6.134.123 rdns: 
sonic315-13.consmr.mail.bf2.yahoo.com
DEBUG(filter_ip_in_rdns_blacklist()@filter.c:1333): checking for IP in 
rDNS +keyword(s) in blacklist file; ip: 74.6.134.123 rdns: 
sonic315-13.consmr.mail.bf2.yahoo.com
DEBUG(filter_rdns_resolve()@filter.c:1426): checking rDNS resolution; 
rdns: sonic315-13.consmr.mail.bf2.yahoo.com
DEBUG(filter_dns_rbl()@filter.c:1645): checking DNS RBL(s); ip: 
74.6.134.123
DEBUG(filter_earlytalker()@filter.c:1817): checking for earlytalker; 
delay: 6
DEBUG(undo_softlimit()@spamdyke.c:3203): reset address space soft 
limit to infinity: please stop using the softlimit program
DEBUG(undo_softlimit()@spamdyke.c:3223): reset data segment soft limit 
to infinity: please stop using the softlimit program
DEBUG(undo_softlimit()@spamdyke.c:3241): reset stack size soft limit 
to infinity: please stop using the softlimit program


12/27/2022 18:37:47 FROM CHILD TO REMOTE: 60 bytes
220 --removed-- - No spam or viruses accepted ESMTP

12/27/2022 18:37:47 FROM REMOTE TO CHILD: 44 bytes
EHLO sonic315-13.consmr.mail.bf2.yahoo.com

12/27/2022 18:37:47 FROM CHILD TO REMOTE: 54 bytes
250---removed-- - No spam or viruses accepted

12/27/2022 18:37:47 FROM CHILD TO REMOTE: 14 bytes
250-STARTTLS

12/27/2022 18:37:47 FROM CHILD TO REMOTE: 16 bytes
250-PIPELINING

12/27/2022 18:37:47 FROM CHILD TO REMOTE: 14 bytes
250-8BITMIME

12/27/2022 18:37:47 FROM CHILD TO REMOTE: 19 bytes
250-SIZE 20971520

12/27/2022 18:37:47 FROM CHILD TO REMOTE: 31 bytes
250 AUTH LOGIN PLAIN CRAM-MD5

12/27/2022 18:37:47 FROM REMOTE TO CHILD: 10 bytes
STARTTLS

12/27/2022 18:37:47 FROM SPAMDYKE TO REMOTE: 14 bytes
220 Proceed.

12/27/2022 18:37:48 LOG OUTPUT TLS
DEBUG(tls_start()@tls.c:417): TLS/SSL connection established, using 
cipher AES128-GCM-SHA256, 128 bits


12/27/2022 18:37:48 - TLS negotiated and started

12/27/2022 18:37:48 FROM REMOTE TO CHILD: 44 bytes TLS
EHLO sonic315-13.consmr.mail.bf2.yahoo.com

12/27/2022 18:37:48 FROM CHILD TO REMOTE: 54 bytes TLS
250---removed-- - No spam or viruses accepted

12/27/2022 18:37:48 FROM CHILD, FILTERED: 14 bytes TLS
250-STARTTLS

12/27/2022 18:37:48 FROM CHILD TO REMOTE: 16 bytes TLS
250-PIPELINING

12/27/2022 18:37:48 FROM CHILD TO REMOTE: 14 bytes TLS
250-8BITMIME

12/27/2022 18:37:48 FROM CHILD TO REMOTE: 19 bytes TLS
250-SIZE 20971520

12/27/2022 18:37:48 FROM CHILD TO REMOTE: 31 bytes TLS
250 AUTH LOGIN PLAIN CRAM-MD5

12/27/2022 18:37:49 FROM REMOTE TO CHILD: 33 bytes TLS
MAIL FROM:<--removed-->

12/27/2022 18:37:49 LOG OUTPUT TLS
DEBUG(find_username()@spamdyke.c:127): searching for username between 
positions 11 and 29: MAIL FROM:<--removed-->
DEBUG(find_domain()@spamdyke.c:361): searching for domain between 
positions 20 and 29: MAIL FROM:<--removed-->

DEBUG(find_address()@spamdyke.c:726): found username: --removed--
DEBUG(find_address()@spamdyke.c:743): found domain: yahoo.com
DEBUG(filter_sender_whitelist()@filter.c:1871): searching sender 
whitelist(s); sender: --removed--
DEBUG(filter_sender_blacklist()@filter.c:2011): searching sender 
blacklist(s); sender: --removed--
DEBUG(filter_sende

Re: [qmailtoaster] TLS issue with Spamdyke v5.0.1

[Remo Mattei]

Hi I had something similar but my qmail pem was empty and that created a few 
issues once fixed that all good.

--
Mandato da iPhone

> On domenica, dic 25, 2022 at 21:45, Eric Broch  (mailto:ebr...@whitehorsetc.com)> wrote:
> Do you have openssl-* installed?
> On Dec 25, 2022, at 9:57 PM, nowuk...@gmail.com (mailto:nowuk...@gmail.com) 
> wrote:
> > Hi,
> >
> > It seems like suddenly my QMT installation started acting up and reject
> > mail (several days now). It does not deliver bounces but reports that
> > the sending server, e.g., Yahoo, etc, could not connect to send mail.
> > There is no MTA code in returned mail, at all. Initially, Gmail was
> > having an issue, as well, but now seems to be able to send mail.
> >
> > I am convinced it was due to some package upgrade, but I am at my wits
> > end to figure out how to fix this. Any hints would be appreciated. The
> > certificate file is Let's Encrypt certificate I have used for some time
> > now and key packaged into PEM file.
> >
> > Current package versions are (some upgraded recently, as I was trying to
> > fix it with no success):
> >
> > autorespond-2.0.5-1.qt.el7.x86_64
> > control-panel-0.5.1-1.qt.el7.x86_64
> > daemontools-0.76-0.qt.el7.x86_64
> > dovecot-2.3.11.3 (http://2.3.11.3)-13.qt.el7.x86_64
> > dspam-3.10.2-15.qt.el7.x86_64
> > dspam-client-3.10.2-15.qt.el7.x86_64
> > dspam-hash-3.10.2-15.qt.el7.x86_64
> > dspam-libs-3.10.2-15.qt.el7.x86_64
> > dspam-mysql-3.10.2-15.qt.el7.x86_64
> > ezmlm-0.53.324-0.qt.el7.x86_64
> > ezmlm-cgi-0.53.324-0.qt.el7.x86_64
> > isoqlog-2.2.1-2.qt.el7.x86_64
> > libdomainkeys-devel-0.69-1.qt.el7.x86_64
> > libsrs2-1.0.18-0.qt.el7.x86_64
> > libsrs2-devel-1.0.18-0.qt.el7.x86_64
> > maildrop-2.9.1-2.qt.el7.x86_64
> > maildrop-devel-2.9.1-2.qt.el7.x86_64
> > mailman-debuginfo-2.1.12-20.qt.el7.x86_64
> > openssl11-1.1.1k-6.qt.el7.x86_64
> > openssl11-libs-1.1.1k-6.qt.el7.x86_64
> > qmail-1.03-2.2.1.qt.el7.x86_64
> > qmailadmin-1.2.16-3.2.qt.el7.x86_64
> > qmailmrtg-4.2-3.qt.el7.x86_64
> > qmt-plus-1-0.qt.el7.noarch
> > qmt-release-1-7.qt.el7.noarch
> > spamdyke-5.0.1-3.qt.el7.x86_64
> > ucspi-tcp-0.88-0.qt.el7.x86_64
> > vpopmail-5.4.33-2.qt.el7.x86_64
> > vqadmin-2.3.7-1.qt.el7.x86_64
> >
> > Thanks,
> >
> > Ed
> >
> >
> > P.S. In the Spamdyke logs, I see that the TLS connection has been
> > established but it times out:
> >
> > Dec 25 18:32:27 mx2 spamdyke[17819]:
> > DEBUG(filter_ip_in_rdns_cc()@filter.c:978): checking for IP in rDNS
> > +country code; rdns: mta5.ealerts.bankofamerica.com 
> > (http://mta5.ealerts.bankofamerica.com)
> > Dec 25 18:32:27 mx2 spamdyke[17819]:
> > DEBUG(filter_rdns_whitelist_file()@filter.c:1055): searching rDNS
> > whitelist file(s); rdns: mta5.ealerts.bankofamerica.com 
> > (http://mta5.ealerts.bankofamerica.com)
> > Dec 25 18:32:27 mx2 spamdyke[17819]:
> > DEBUG(filter_rdns_blacklist_file()@filter.c:1159): searching rDNS
> > blacklist file(s); rdns: mta5.ealerts.bankofamerica.com 
> > (http://mta5.ealerts.bankofamerica.com)
> > Dec 25 18:32:27 mx2 spamdyke[17819]:
> > DEBUG(filter_ip_whitelist()@filter.c:1228): searching IP whitelist
> > file(s); ip: 68.232.194.2 (http://68.232.194.2)
> > Dec 25 18:32:27 mx2 spamdyke[17819]:
> > DEBUG(filter_ip_blacklist()@filter.c:1279): searching IP blacklist
> > file(s); ip: 68.232.194.2 (http://68.232.194.2)
> > Dec 25 18:32:27 mx2 spamdyke[17819]:
> > DEBUG(filter_ip_in_rdns_whitelist()@filter.c:1380): checking for IP in
> > rDNS +keyword(s) in whitelist file; ip: 68.232.194.2 (http://68.232.194.2) 
> > rdns:
> > mta5.ealerts.bankofamerica.com (http://mta5.ealerts.bankofamerica.com)
> > Dec 25 18:32:27 mx2 spamdyke[17819]:
> > DEBUG(filter_ip_in_rdns_blacklist()@filter.c:1333): checking for IP in
> > rDNS +keyword(s) in blacklist file; ip: 68.232.194.2 (http://68.232.194.2) 
> > rdns:
> > mta5.ealerts.bankofamerica.com (http://mta5.ealerts.bankofamerica.com)
> > Dec 25 18:32:27 mx2 spamdyke[17819]:
> > DEBUG(filter_rdns_resolve()@filter.c:1426): checking rDNS resolution;
> > rdns: mta5.ealerts.bankofamerica.com (http://mta5.ealerts.bankofamerica.com)
> > Dec 25 18:32:27 mx2 spamdyke[17819]:
> > DEBUG(filter_dns_rbl()@filter.c:1645): checking DNS RBL(s); ip: 
> > 68.232.194.2 (http://68.232.194.2)
> > Dec 25 18:32:27 mx2 spamdyke[17819]:
> > DEBUG(filter_earlytalker()@filter.c:1817): checking for earlytalker;
> > delay: 2
> > Dec 25 18:32:30 mx2 spamdyke[17819]: DEBUG(tls_start()@tls.c:439):
> > TLS/SSL connection established, using cipher AES256-GCM-SHA384, 256 bits
> > Dec 25 18:32:31 mx2 spamdyke[17819]:
> > DEBUG(find_username()@spamdyke.c:127): searching for username between
> > positions 11 and 93: MAIL
> > FROM:
> > BODY=8BITMIME
> > Dec 25 18:32:31 mx2 spamdyke[17819]:
> > DEBUG(find_domain()@spamdyke.c:361): searching for domain between
> > positions 61 and 93: MAIL
> > FROM:
> > BODY=8BITMIME
> > Dec 25 18:32:31 mx2 spamdyke[17819]:
> > DEBUG(find_address()@spamdyke.c:726): found username:
> > bounce-145816_HTML-1692157747-5010266-

Re: [qmailtoaster] TLS issue with Spamdyke v5.0.1

[Eric Broch]

Do you have openssl-* installed?

On Dec 25, 2022, 9:57 PM, at 9:57 PM, nowuk...@gmail.com wrote:
>Hi,
>
>It seems like suddenly my QMT installation started acting up and reject
>
>mail (several days now). It does not deliver bounces but reports that
>the sending server, e.g., Yahoo, etc, could not connect to send mail.
>There is no MTA code in returned mail, at all. Initially, Gmail was
>having an issue, as well, but now seems to be able to send mail.
>
>I am convinced it was due to some package upgrade, but I am at my wits
>end to figure out how to fix this. Any hints would be appreciated. The
>certificate file is Let's Encrypt certificate I have used for some time
>
>now and key packaged into PEM file.
>
>Current package versions are (some upgraded recently, as I was trying
>to
>fix it with no success):
>
>autorespond-2.0.5-1.qt.el7.x86_64
>control-panel-0.5.1-1.qt.el7.x86_64
>daemontools-0.76-0.qt.el7.x86_64
>dovecot-2.3.11.3-13.qt.el7.x86_64
>dspam-3.10.2-15.qt.el7.x86_64
>dspam-client-3.10.2-15.qt.el7.x86_64
>dspam-hash-3.10.2-15.qt.el7.x86_64
>dspam-libs-3.10.2-15.qt.el7.x86_64
>dspam-mysql-3.10.2-15.qt.el7.x86_64
>ezmlm-0.53.324-0.qt.el7.x86_64
>ezmlm-cgi-0.53.324-0.qt.el7.x86_64
>isoqlog-2.2.1-2.qt.el7.x86_64
>libdomainkeys-devel-0.69-1.qt.el7.x86_64
>libsrs2-1.0.18-0.qt.el7.x86_64
>libsrs2-devel-1.0.18-0.qt.el7.x86_64
>maildrop-2.9.1-2.qt.el7.x86_64
>maildrop-devel-2.9.1-2.qt.el7.x86_64
>mailman-debuginfo-2.1.12-20.qt.el7.x86_64
>openssl11-1.1.1k-6.qt.el7.x86_64
>openssl11-libs-1.1.1k-6.qt.el7.x86_64
>qmail-1.03-2.2.1.qt.el7.x86_64
>qmailadmin-1.2.16-3.2.qt.el7.x86_64
>qmailmrtg-4.2-3.qt.el7.x86_64
>qmt-plus-1-0.qt.el7.noarch
>qmt-release-1-7.qt.el7.noarch
>spamdyke-5.0.1-3.qt.el7.x86_64
>ucspi-tcp-0.88-0.qt.el7.x86_64
>vpopmail-5.4.33-2.qt.el7.x86_64
>vqadmin-2.3.7-1.qt.el7.x86_64
>
>Thanks,
>
>Ed
>
>
>P.S. In the Spamdyke logs, I see that the TLS connection has been
>established but it times out:
>
>Dec 25 18:32:27 mx2 spamdyke[17819]:
>DEBUG(filter_ip_in_rdns_cc()@filter.c:978): checking for IP in rDNS
>+country code; rdns: mta5.ealerts.bankofamerica.com
>Dec 25 18:32:27 mx2 spamdyke[17819]:
>DEBUG(filter_rdns_whitelist_file()@filter.c:1055): searching rDNS
>whitelist file(s); rdns: mta5.ealerts.bankofamerica.com
>Dec 25 18:32:27 mx2 spamdyke[17819]:
>DEBUG(filter_rdns_blacklist_file()@filter.c:1159): searching rDNS
>blacklist file(s); rdns: mta5.ealerts.bankofamerica.com
>Dec 25 18:32:27 mx2 spamdyke[17819]:
>DEBUG(filter_ip_whitelist()@filter.c:1228): searching IP whitelist
>file(s); ip: 68.232.194.2
>Dec 25 18:32:27 mx2 spamdyke[17819]:
>DEBUG(filter_ip_blacklist()@filter.c:1279): searching IP blacklist
>file(s); ip: 68.232.194.2
>Dec 25 18:32:27 mx2 spamdyke[17819]:
>DEBUG(filter_ip_in_rdns_whitelist()@filter.c:1380): checking for IP in
>rDNS +keyword(s) in whitelist file; ip: 68.232.194.2 rdns:
>mta5.ealerts.bankofamerica.com
>Dec 25 18:32:27 mx2 spamdyke[17819]:
>DEBUG(filter_ip_in_rdns_blacklist()@filter.c:1333): checking for IP in
>rDNS +keyword(s) in blacklist file; ip: 68.232.194.2 rdns:
>mta5.ealerts.bankofamerica.com
>Dec 25 18:32:27 mx2 spamdyke[17819]:
>DEBUG(filter_rdns_resolve()@filter.c:1426): checking rDNS resolution;
>rdns: mta5.ealerts.bankofamerica.com
>Dec 25 18:32:27 mx2 spamdyke[17819]:
>DEBUG(filter_dns_rbl()@filter.c:1645): checking DNS RBL(s); ip:
>68.232.194.2
>Dec 25 18:32:27 mx2 spamdyke[17819]:
>DEBUG(filter_earlytalker()@filter.c:1817): checking for earlytalker;
>delay: 2
>Dec 25 18:32:30 mx2 spamdyke[17819]: DEBUG(tls_start()@tls.c:439):
>TLS/SSL connection established, using cipher AES256-GCM-SHA384, 256
>bits
>Dec 25 18:32:31 mx2 spamdyke[17819]:
>DEBUG(find_username()@spamdyke.c:127): searching for username between
>positions 11 and 93: MAIL
>FROM:
>
>BODY=8BITMIME
>Dec 25 18:32:31 mx2 spamdyke[17819]:
>DEBUG(find_domain()@spamdyke.c:361): searching for domain between
>positions 61 and 93: MAIL
>FROM:
>
>BODY=8BITMIME
>Dec 25 18:32:31 mx2 spamdyke[17819]:
>DEBUG(find_address()@spamdyke.c:726): found username:
>bounce-145816_HTML-1692157747-5010266-522000109-17
>Dec 25 18:32:31 mx2 spamdyke[17819]:
>DEBUG(find_address()@spamdyke.c:743): found domain:
>bounce.ealerts.bankofamerica.com
>Dec 25 18:32:31 mx2 spamdyke[17819]:
>DEBUG(filter_sender_whitelist()@filter.c:1871): searching sender
>whitelist(s); sender:
>bounce-145816_html-1692157747-5010266-522000109...@bounce.ealerts.bankofamerica.com
>Dec 25 18:32:31 mx2 spamdyke[17819]:
>DEBUG(filter_sender_blacklist()@filter.c:2011): searching sender
>blacklist(s); sender:
>bounce-145816_html-1692157747-5010266-522000109...@bounce.ealerts.bankofamerica.com
>Dec 25 18:32:31 mx2 spamdyke[17819]:
>DEBUG(filter_sender()@filter.c:2296): checking for sender domain MX
>record; domain: bounce.ealerts.bankofamerica.com
>Dec 25 18:33:32 mx2 spamdyke[17819]: TIMEOUT from:
>bounce-145816_html-1692157747-5010266-522000109...@bounce.ealerts.bankofamerica.com
>
>to: (unknown) origin_ip: 68.232.194.2 origin_rdns:
>mta5.ealerts.bank

Re: [qmailtoaster] TLS connection failed: ciphersuite wrong

[Eric Broch]

Hi Peter,

OpenSSL version 1.1.1 (RHEL8) and derivatives uses a different function 
than OpenSSL 1.0.2 (RHEL7) to set connection ciphers. Before the patch, 
the function in question for qmail-remote wasn't setting the connection 
ciphers (tlsclientciphers) so it went to default from opensslcnf.conf, 
the patched version will set connection ciphers correctly. I'm guessing 
you won't need the settings in openssl.cnf anymore since the new 
function is used and it sets the cipher list for the connection. It 
would be interesting to revert openssl.cnf back to it's original 
settings and test. If okay change the crypto policies to DEFAULT and see 
what happens.


Let me know your findings if you go that way.

Eric

On 3/24/2022 2:18 PM, Peter Peltonen wrote:

Hi Eric,

I now installed the rpm from testing repo, restarted qmail and did three tests:

- emailed Gmail address, mail relayed through my qmail box: OK
- replied from Gmail to my qmail box: OK
- emailed hornet security: OK

What I have in qmail send log is:
Remote_host_said:_250_2.0.0_OK_accept_as_13208F02763:a113fcad4200a6e05349a9b2d4c38ecd_by_mx-gate19-hz2/

So far so good.

My other settings currently:

# update-crypto-policies --show
LEGACY

and in /etc/crypto-policies/back-ends/opensslcnf.config I have
CipherString = @SECLEVEL=1

Is LEGACY still fine ? And should I switch back to @SECLEVEL=2 ?

Best,
Peter

On Sat, Mar 19, 2022 at 6:40 PM Eric Broch  wrote:

List,

qmail-1.03-3.3.6.qt.md.el8.x86_64.rpm is in the testing repo. This is
patched with updated loading of ciphers consistent with OpenSSL 1.1.1 on
RHEL8 (and 8 derivatives) both in mysql and mariadb trees (non md to come).

Here's the patch:

--- qmail-1.03-3.3.5/qmail-remote.c 2022-03-18 08:22:01.810701523 -0600
+++ qmail-1.03-3.3.5-new/qmail-remote.c 2022-03-18 13:48:22.951868716 -0600
@@ -426,16 +426,26 @@
   }
 }

-  SSL_library_init();
-  ctx = SSL_CTX_new(SSLv23_client_method());
+#if OPENSSL_VERSION_NUMBER >= 0x10101000L
+   OPENSSL_init_ssl(OPENSSL_INIT_LOAD_SSL_STRINGS,NULL); /* TLS 1.3 */
+   ctx = SSL_CTX_new(TLS_client_method());
+#else
+   SSL_library_init();   /* TLS < 1.3 */
+   ctx = SSL_CTX_new(SSLv23_client_method());
+#endif
 if (!ctx) {
   if (!smtps && !servercert) return 0;
   smtptext.len = 0;
   tls_quit_error("ZTLS error initializing ctx");
 }

-  /* POODLE vulnerability */
+#if OPENSSL_VERSION_NUMBER >= 0x10101000L
+  SSL_CTX_set_options(ctx,SSL_OP_ALL);
+  SSL_CTX_set_min_proto_version(ctx,TLS1_VERSION);
+  SSL_CTX_set_max_proto_version(ctx,TLS1_3_VERSION);
+#else
 SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3);
+#endif

 if (servercert) {
   if (!SSL_CTX_load_verify_locations(ctx, servercert, NULL)) {
@@ -476,7 +486,11 @@
   ciphers = saciphers.s;
 }
 else ciphers = "DEFAULT";
-  SSL_set_cipher_list(myssl, ciphers);
+#if OPENSSL_VERSION_NUMBER >= 0x10101000L
+   SSL_set_ciphersuites(myssl,ciphers); /* TLS 1.3 */
+#else
+   SSL_set_cipher_list(myssl,ciphers);  /* TLS < 1.3 */
+#endif
 alloc_free(saciphers.s);

 SSL_set_fd(myssl, smtpfd);
--- qmail-1.03-3.3.5/tls.c  2022-03-18 08:22:02.507741854 -0600
+++ qmail-1.03-3.3.5-new/tls.c  2022-03-18 14:02:17.001103857 -0600
@@ -14,7 +14,9 @@
   {
 int r = ERR_get_error();
 if (!r) return NULL;
+#if OPENSSL_VERSION_NUMBER < 0x10101000L
 SSL_load_error_strings();
+#endif
 return ERR_error_string(r, NULL);
   }
   const char *ssl_error_str()
--- qmail-1.03-3.3.5/qmail-smtpd.c  2022-03-18 08:22:01.827702507 -0600
+++ qmail-1.03-3.3.5-new/qmail-smtpd.c  2022-03-18 14:41:30.512190971 -0600
@@ -1469,14 +1469,22 @@
 X509_LOOKUP *lookup;
 int session_id_context = 1; /* anything will do */

-  SSL_library_init();
-
-  /* a new SSL context with the bare minimum of options */
+#if OPENSSL_VERSION_NUMBER >= 0x10101000L
+  OPENSSL_init_ssl(OPENSSL_INIT_LOAD_SSL_STRINGS,NULL); /* TLS 1.3 */
+  ctx = SSL_CTX_new(TLS_server_method());
+#else
+  SSL_library_init();   /* TLS < 1.3 */
 ctx = SSL_CTX_new(SSLv23_server_method());
+#endif
 if (!ctx) { tls_err("unable to initialize ctx"); return; }

-  /* POODLE vulnerability */
+#if OPENSSL_VERSION_NUMBER >= 0x10101000L
+  SSL_CTX_set_options(ctx,SSL_OP_ALL);
+  SSL_CTX_set_min_proto_version(ctx,TLS1_VERSION);
+  SSL_CTX_set_max_proto_version(ctx,TLS1_3_VERSION);
+#else
 SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3);
+#endif

 /* renegotiation should include certificate request */
 SSL_CTX_set_options(ctx, SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION);
@@ -1529,7 +1537,11 @@
   }
 }
 if (!ciphers || !*ciphers) ciphers = "DEFAULT";
-  SSL_set_cipher_list(myssl, ciphers);
+#if OPENSSL_VERSION_NUMBER >= 0x10101000L
+  SSL_set_ciphersuites(myssl,ciphers); /* TLS 1.3 */
+#else
+  SSL_set_cipher_list(myssl,ciphers);  /* TLS < 1.3 */
+#endif
 alloc_free(saciphers.s);

 SSL_set_t

Re: [qmailtoaster] TLS connection failed: ciphersuite wrong

[Peter Peltonen]

Hi Eric,

I now installed the rpm from testing repo, restarted qmail and did three tests:

- emailed Gmail address, mail relayed through my qmail box: OK
- replied from Gmail to my qmail box: OK
- emailed hornet security: OK

What I have in qmail send log is:
Remote_host_said:_250_2.0.0_OK_accept_as_13208F02763:a113fcad4200a6e05349a9b2d4c38ecd_by_mx-gate19-hz2/

So far so good.

My other settings currently:

# update-crypto-policies --show
LEGACY

and in /etc/crypto-policies/back-ends/opensslcnf.config I have
CipherString = @SECLEVEL=1

Is LEGACY still fine ? And should I switch back to @SECLEVEL=2 ?

Best,
Peter

On Sat, Mar 19, 2022 at 6:40 PM Eric Broch  wrote:
>
> List,
>
> qmail-1.03-3.3.6.qt.md.el8.x86_64.rpm is in the testing repo. This is
> patched with updated loading of ciphers consistent with OpenSSL 1.1.1 on
> RHEL8 (and 8 derivatives) both in mysql and mariadb trees (non md to come).
>
> Here's the patch:
>
> --- qmail-1.03-3.3.5/qmail-remote.c 2022-03-18 08:22:01.810701523 -0600
> +++ qmail-1.03-3.3.5-new/qmail-remote.c 2022-03-18 13:48:22.951868716 -0600
> @@ -426,16 +426,26 @@
>   }
> }
>
> -  SSL_library_init();
> -  ctx = SSL_CTX_new(SSLv23_client_method());
> +#if OPENSSL_VERSION_NUMBER >= 0x10101000L
> +   OPENSSL_init_ssl(OPENSSL_INIT_LOAD_SSL_STRINGS,NULL); /* TLS 1.3 */
> +   ctx = SSL_CTX_new(TLS_client_method());
> +#else
> +   SSL_library_init();   /* TLS < 1.3 */
> +   ctx = SSL_CTX_new(SSLv23_client_method());
> +#endif
> if (!ctx) {
>   if (!smtps && !servercert) return 0;
>   smtptext.len = 0;
>   tls_quit_error("ZTLS error initializing ctx");
> }
>
> -  /* POODLE vulnerability */
> +#if OPENSSL_VERSION_NUMBER >= 0x10101000L
> +  SSL_CTX_set_options(ctx,SSL_OP_ALL);
> +  SSL_CTX_set_min_proto_version(ctx,TLS1_VERSION);
> +  SSL_CTX_set_max_proto_version(ctx,TLS1_3_VERSION);
> +#else
> SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3);
> +#endif
>
> if (servercert) {
>   if (!SSL_CTX_load_verify_locations(ctx, servercert, NULL)) {
> @@ -476,7 +486,11 @@
>   ciphers = saciphers.s;
> }
> else ciphers = "DEFAULT";
> -  SSL_set_cipher_list(myssl, ciphers);
> +#if OPENSSL_VERSION_NUMBER >= 0x10101000L
> +   SSL_set_ciphersuites(myssl,ciphers); /* TLS 1.3 */
> +#else
> +   SSL_set_cipher_list(myssl,ciphers);  /* TLS < 1.3 */
> +#endif
> alloc_free(saciphers.s);
>
> SSL_set_fd(myssl, smtpfd);
> --- qmail-1.03-3.3.5/tls.c  2022-03-18 08:22:02.507741854 -0600
> +++ qmail-1.03-3.3.5-new/tls.c  2022-03-18 14:02:17.001103857 -0600
> @@ -14,7 +14,9 @@
>   {
> int r = ERR_get_error();
> if (!r) return NULL;
> +#if OPENSSL_VERSION_NUMBER < 0x10101000L
> SSL_load_error_strings();
> +#endif
> return ERR_error_string(r, NULL);
>   }
>   const char *ssl_error_str()
> --- qmail-1.03-3.3.5/qmail-smtpd.c  2022-03-18 08:22:01.827702507 -0600
> +++ qmail-1.03-3.3.5-new/qmail-smtpd.c  2022-03-18 14:41:30.512190971 -0600
> @@ -1469,14 +1469,22 @@
> X509_LOOKUP *lookup;
> int session_id_context = 1; /* anything will do */
>
> -  SSL_library_init();
> -
> -  /* a new SSL context with the bare minimum of options */
> +#if OPENSSL_VERSION_NUMBER >= 0x10101000L
> +  OPENSSL_init_ssl(OPENSSL_INIT_LOAD_SSL_STRINGS,NULL); /* TLS 1.3 */
> +  ctx = SSL_CTX_new(TLS_server_method());
> +#else
> +  SSL_library_init();   /* TLS < 1.3 */
> ctx = SSL_CTX_new(SSLv23_server_method());
> +#endif
> if (!ctx) { tls_err("unable to initialize ctx"); return; }
>
> -  /* POODLE vulnerability */
> +#if OPENSSL_VERSION_NUMBER >= 0x10101000L
> +  SSL_CTX_set_options(ctx,SSL_OP_ALL);
> +  SSL_CTX_set_min_proto_version(ctx,TLS1_VERSION);
> +  SSL_CTX_set_max_proto_version(ctx,TLS1_3_VERSION);
> +#else
> SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3);
> +#endif
>
> /* renegotiation should include certificate request */
> SSL_CTX_set_options(ctx, SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION);
> @@ -1529,7 +1537,11 @@
>   }
> }
> if (!ciphers || !*ciphers) ciphers = "DEFAULT";
> -  SSL_set_cipher_list(myssl, ciphers);
> +#if OPENSSL_VERSION_NUMBER >= 0x10101000L
> +  SSL_set_ciphersuites(myssl,ciphers); /* TLS 1.3 */
> +#else
> +  SSL_set_cipher_list(myssl,ciphers);  /* TLS < 1.3 */
> +#endif
> alloc_free(saciphers.s);
>
> SSL_set_tmp_rsa_callback(myssl, tmp_rsa_cb);
>
> On 3/18/2022 9:32 AM, Eric Broch wrote:
> > Hi Peter,
> >
> > I've been looking into this TLS issue and think I've found the
> > solution. It seems that the function in the newest version of OpenSSL
> > used in qmail-remote to load ciphers suits from the control directory
> > has been replaced so the default ciphers are loaded instead of the one
> > in the control directory. I've made changes to qmail-remote for the
> > latest OpenSSL to support TLS 1.3 and am using the proper function to
> > load the ciphers. It has been compiled on my Rocky8 box a

Re: [qmailtoaster] TLS connection failed: ciphersuite wrong

[Eric Broch]

List,

qmail-1.03-3.3.6.qt.md.el8.x86_64.rpm is in the testing repo. This is 
patched with updated loading of ciphers consistent with OpenSSL 1.1.1 on 
RHEL8 (and 8 derivatives) both in mysql and mariadb trees (non md to come).


Here's the patch:

--- qmail-1.03-3.3.5/qmail-remote.c 2022-03-18 08:22:01.810701523 -0600
+++ qmail-1.03-3.3.5-new/qmail-remote.c 2022-03-18 13:48:22.951868716 -0600
@@ -426,16 +426,26 @@
 }
   }

-  SSL_library_init();
-  ctx = SSL_CTX_new(SSLv23_client_method());
+#if OPENSSL_VERSION_NUMBER >= 0x10101000L
+   OPENSSL_init_ssl(OPENSSL_INIT_LOAD_SSL_STRINGS,NULL); /* TLS 1.3 */
+   ctx = SSL_CTX_new(TLS_client_method());
+#else
+   SSL_library_init();   /* TLS < 1.3 */
+   ctx = SSL_CTX_new(SSLv23_client_method());
+#endif
   if (!ctx) {
 if (!smtps && !servercert) return 0;
 smtptext.len = 0;
 tls_quit_error("ZTLS error initializing ctx");
   }

-  /* POODLE vulnerability */
+#if OPENSSL_VERSION_NUMBER >= 0x10101000L
+  SSL_CTX_set_options(ctx,SSL_OP_ALL);
+  SSL_CTX_set_min_proto_version(ctx,TLS1_VERSION);
+  SSL_CTX_set_max_proto_version(ctx,TLS1_3_VERSION);
+#else
   SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3);
+#endif

   if (servercert) {
 if (!SSL_CTX_load_verify_locations(ctx, servercert, NULL)) {
@@ -476,7 +486,11 @@
 ciphers = saciphers.s;
   }
   else ciphers = "DEFAULT";
-  SSL_set_cipher_list(myssl, ciphers);
+#if OPENSSL_VERSION_NUMBER >= 0x10101000L
+   SSL_set_ciphersuites(myssl,ciphers); /* TLS 1.3 */
+#else
+   SSL_set_cipher_list(myssl,ciphers);  /* TLS < 1.3 */
+#endif
   alloc_free(saciphers.s);

   SSL_set_fd(myssl, smtpfd);
--- qmail-1.03-3.3.5/tls.c  2022-03-18 08:22:02.507741854 -0600
+++ qmail-1.03-3.3.5-new/tls.c  2022-03-18 14:02:17.001103857 -0600
@@ -14,7 +14,9 @@
 {
   int r = ERR_get_error();
   if (!r) return NULL;
+#if OPENSSL_VERSION_NUMBER < 0x10101000L
   SSL_load_error_strings();
+#endif
   return ERR_error_string(r, NULL);
 }
 const char *ssl_error_str()
--- qmail-1.03-3.3.5/qmail-smtpd.c  2022-03-18 08:22:01.827702507 -0600
+++ qmail-1.03-3.3.5-new/qmail-smtpd.c  2022-03-18 14:41:30.512190971 -0600
@@ -1469,14 +1469,22 @@
   X509_LOOKUP *lookup;
   int session_id_context = 1; /* anything will do */

-  SSL_library_init();
-
-  /* a new SSL context with the bare minimum of options */
+#if OPENSSL_VERSION_NUMBER >= 0x10101000L
+  OPENSSL_init_ssl(OPENSSL_INIT_LOAD_SSL_STRINGS,NULL); /* TLS 1.3 */
+  ctx = SSL_CTX_new(TLS_server_method());
+#else
+  SSL_library_init();   /* TLS < 1.3 */
   ctx = SSL_CTX_new(SSLv23_server_method());
+#endif
   if (!ctx) { tls_err("unable to initialize ctx"); return; }

-  /* POODLE vulnerability */
+#if OPENSSL_VERSION_NUMBER >= 0x10101000L
+  SSL_CTX_set_options(ctx,SSL_OP_ALL);
+  SSL_CTX_set_min_proto_version(ctx,TLS1_VERSION);
+  SSL_CTX_set_max_proto_version(ctx,TLS1_3_VERSION);
+#else
   SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3);
+#endif

   /* renegotiation should include certificate request */
   SSL_CTX_set_options(ctx, SSL_OP_NO_SESSION_RESUMPTION_ON_RENEGOTIATION);
@@ -1529,7 +1537,11 @@
 }
   }
   if (!ciphers || !*ciphers) ciphers = "DEFAULT";
-  SSL_set_cipher_list(myssl, ciphers);
+#if OPENSSL_VERSION_NUMBER >= 0x10101000L
+  SSL_set_ciphersuites(myssl,ciphers); /* TLS 1.3 */
+#else
+  SSL_set_cipher_list(myssl,ciphers);  /* TLS < 1.3 */
+#endif
   alloc_free(saciphers.s);

   SSL_set_tmp_rsa_callback(myssl, tmp_rsa_cb);

On 3/18/2022 9:32 AM, Eric Broch wrote:

Hi Peter,

I've been looking into this TLS issue and think I've found the 
solution. It seems that the function in the newest version of OpenSSL 
used in qmail-remote to load ciphers suits from the control directory 
has been replaced so the default ciphers are loaded instead of the one 
in the control directory. I've made changes to qmail-remote for the 
latest OpenSSL to support TLS 1.3 and am using the proper function to 
load the ciphers. It has been compiled on my Rocky8 box and I've 
successfully used it to send emails. I can create and new RPM or make 
available the qmail-remote executable for download and testing. Let me 
know which you'd prefer.


Eric

On 3/2/2022 1:02 AM, Peter Peltonen wrote:

Any ideas how to solve the TLS connect errors?

A bit of a hack that comes to my mind would be to have a cron job to
switch back to LEGACY, process the queue and then switch back to
DEFAULT?

But a more elegant solution would be preferable :)

Best,
Peter

On Tue, Mar 1, 2022 at 9:13 AM Peter Peltonen 
 wrote:

Now after monitoring 36h after the change no cipher related errors,
but a few servers apparently have problems with higher TLS versions:

TLS_connect_failed:_error:1425F102:SSL_routines:ssl_choose_client_version:unsupported_protocol 



I assume that this is due to these
/etc/crypto-policies/back-ends/opensslcnf.config settings:

TLS.MinProtocol = TLSv1.2
TLS.MaxProtocol = TLSv1.3
DTLS.MinProto

Re: [qmailtoaster] TLS connection failed: ciphersuite wrong

[Eric Broch]

Hi Peter,

I've been looking into this TLS issue and think I've found the solution. 
It seems that the function in the newest version of OpenSSL used in 
qmail-remote to load ciphers suits from the control directory has been 
replaced so the default ciphers are loaded instead of the one in the 
control directory. I've made changes to qmail-remote for the latest 
OpenSSL to support TLS 1.3 and am using the proper function to load the 
ciphers. It has been compiled on my Rocky8 box and I've successfully 
used it to send emails. I can create and new RPM or make available the 
qmail-remote executable for download and testing. Let me know which 
you'd prefer.


Eric

On 3/2/2022 1:02 AM, Peter Peltonen wrote:

Any ideas how to solve the TLS connect errors?

A bit of a hack that comes to my mind would be to have a cron job to
switch back to LEGACY, process the queue and then switch back to
DEFAULT?

But a more elegant solution would be preferable :)

Best,
Peter

On Tue, Mar 1, 2022 at 9:13 AM Peter Peltonen  wrote:

Now after monitoring 36h after the change no cipher related errors,
but a few servers apparently have problems with higher TLS versions:

TLS_connect_failed:_error:1425F102:SSL_routines:ssl_choose_client_version:unsupported_protocol

I assume that this is due to these
/etc/crypto-policies/back-ends/opensslcnf.config settings:

TLS.MinProtocol = TLSv1.2
TLS.MaxProtocol = TLSv1.3
DTLS.MinProtocol = DTLSv1.2
DTLS.MaxProtocol = DTLSv1.2

If I lower MinProtocol to TLSv1.0 would that enable access to those
servers but use the higher protocol version for the rest of the world?

Best,
Peter


On Mon, Feb 28, 2022 at 1:44 AM Eric Broch  wrote:

I'd like to implement this programmatically so that we can set
parameters in a /var/qmail/control/sslconf file

On 2/27/2022 2:25 PM, Peter Peltonen wrote:

Hi Eric,

Okay my crypto-policy is now DEFAULT again and in opensslcnf.config I now have:

CipherString = 
DEFAULT@SECLEVEL=1:kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:-aDSS:-3DES:!DES:!RC4:!RC2:!IDEA:-SEED:!eNULL:!aNULL:!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8

I am grepping ssl from qmail/send log. Let's see how it goes.

Best,
Peter

On Thu, Feb 24, 2022 at 7:36 PM Eric Broch  wrote:

Peter,

Can you try something with your server to get mail delivery to normal.
Run command:

update-crypto-policies --set DEFAULT

Edit file  /etc/crypto-policies/back-ends/opensslcnf.config particularly
setting

CipherString = @SECLEVEL=2

change to

CipherString = DEFAULT@SECLEVEL=1

Watch logs

Eric

On 2/23/2022 8:53 AM, Peter Peltonen wrote:

You mean my server with qmail-1.03-3.3.1.qt.md.el8.x86_64 (not
qmail-1.03-2.2.1) with the LEGACY setting?

As far as I know the only problem I am having is with the
hornetsecurity.com servers. But to be honest I have not really been
monitoring the logs that carefully, that's the only server I've
received a complain about. I now tried sending them email with
unencrypted connection and it failed.

So I think I will now leave it to LEGACY, accept that I cannot deliver
mail to the hornet serers and keep monitoring now more closely for TLS
errors in the logs: if more turn up then I might consider again
switching to DEFAULT and then adding those servers to notlshosts/
although that looks like a nonendint task.

If someone comes up with a solution how I could have the best of both
worlds (= support everyone), let me know?

Best,
Peter

On Wed, Feb 23, 2022 at 5:08 PM Eric Broch  wrote:

Does your legacy server qmail-1.03-2.2.1 send to all?

On 2/23/2022 8:03 AM, Peter Peltonen wrote:

Here is another error I have now seen qmail/send log about 10 times in
the recent hour:

TLS_connect_failed:_error:141A318A:SSL_routines:tls_process_ske_dhe:dh_key_too_small

And this has now happened with two pretty big local service provider's
servers as well. I don't think I can continue with the DEFAULT
setting. I will now try to fall back to LEGACY and see if
hornetsecurity.com accepts unencrypted connections. And I really do
not understand the core of this problem: why cannot my server just
have the whole range of ciphers and protocols in use and apply the
most secure / appropriate one that the other party supports?

Best,
Peter

On Wed, Feb 23, 2022 at 4:29 PM Eric Broch  wrote:

If I remember correctly it had something to do with Dovecot
On Feb 23, 2022, at 2:25 AM, Peter Peltonen  wrote:

Hello,

Okay I now tested::

With LEGACY (which I had earlier) I get the
SSL_routines:set_client_ciphesuite:wrong_cipher_returned error in qmail/send 
log:

But with DEFAULT I get Remote_host_said:_250_2.0.0_OK_accept as the result

And I did the test without rebooting nor restarting qmail.

So apparently this command did the trick like Eric suggested:

update-crypto-policies --set DEFAULT

Now I wonder if this has some other consequences, what legacy stuff is now 
incompatible...?

Best,
Peter


ma 21. helmik. 2022 klo 17.55 Eric Broch < ebr...@whitehorsetc.com> kirjoitti:

reboot

On 2/21/2022 8:30 AM, Peter Peltonen wrote

Re: [qmailtoaster] TLS connection failed: ciphersuite wrong

[Eric Broch]

I think it would, but I would try it to see.

On 3/1/2022 12:13 AM, Peter Peltonen wrote:

If I lower MinProtocol to TLSv1.0 would that enable access to those
servers but use the higher protocol version for the rest of the world?


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

Re: [qmailtoaster] TLS connection failed: ciphersuite wrong

[Peter Peltonen]

Any ideas how to solve the TLS connect errors?

A bit of a hack that comes to my mind would be to have a cron job to
switch back to LEGACY, process the queue and then switch back to
DEFAULT?

But a more elegant solution would be preferable :)

Best,
Peter

On Tue, Mar 1, 2022 at 9:13 AM Peter Peltonen  wrote:
>
> Now after monitoring 36h after the change no cipher related errors,
> but a few servers apparently have problems with higher TLS versions:
>
> TLS_connect_failed:_error:1425F102:SSL_routines:ssl_choose_client_version:unsupported_protocol
>
> I assume that this is due to these
> /etc/crypto-policies/back-ends/opensslcnf.config settings:
>
> TLS.MinProtocol = TLSv1.2
> TLS.MaxProtocol = TLSv1.3
> DTLS.MinProtocol = DTLSv1.2
> DTLS.MaxProtocol = DTLSv1.2
>
> If I lower MinProtocol to TLSv1.0 would that enable access to those
> servers but use the higher protocol version for the rest of the world?
>
> Best,
> Peter
>
>
> On Mon, Feb 28, 2022 at 1:44 AM Eric Broch  wrote:
> >
> > I'd like to implement this programmatically so that we can set
> > parameters in a /var/qmail/control/sslconf file
> >
> > On 2/27/2022 2:25 PM, Peter Peltonen wrote:
> > > Hi Eric,
> > >
> > > Okay my crypto-policy is now DEFAULT again and in opensslcnf.config I now 
> > > have:
> > >
> > > CipherString = 
> > > DEFAULT@SECLEVEL=1:kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:-aDSS:-3DES:!DES:!RC4:!RC2:!IDEA:-SEED:!eNULL:!aNULL:!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8
> > >
> > > I am grepping ssl from qmail/send log. Let's see how it goes.
> > >
> > > Best,
> > > Peter
> > >
> > > On Thu, Feb 24, 2022 at 7:36 PM Eric Broch  
> > > wrote:
> > >> Peter,
> > >>
> > >> Can you try something with your server to get mail delivery to normal.
> > >> Run command:
> > >>
> > >> update-crypto-policies --set DEFAULT
> > >>
> > >> Edit file  /etc/crypto-policies/back-ends/opensslcnf.config particularly
> > >> setting
> > >>
> > >> CipherString = @SECLEVEL=2
> > >>
> > >> change to
> > >>
> > >> CipherString = DEFAULT@SECLEVEL=1
> > >>
> > >> Watch logs
> > >>
> > >> Eric
> > >>
> > >> On 2/23/2022 8:53 AM, Peter Peltonen wrote:
> > >>> You mean my server with qmail-1.03-3.3.1.qt.md.el8.x86_64 (not
> > >>> qmail-1.03-2.2.1) with the LEGACY setting?
> > >>>
> > >>> As far as I know the only problem I am having is with the
> > >>> hornetsecurity.com servers. But to be honest I have not really been
> > >>> monitoring the logs that carefully, that's the only server I've
> > >>> received a complain about. I now tried sending them email with
> > >>> unencrypted connection and it failed.
> > >>>
> > >>> So I think I will now leave it to LEGACY, accept that I cannot deliver
> > >>> mail to the hornet serers and keep monitoring now more closely for TLS
> > >>> errors in the logs: if more turn up then I might consider again
> > >>> switching to DEFAULT and then adding those servers to notlshosts/
> > >>> although that looks like a nonendint task.
> > >>>
> > >>> If someone comes up with a solution how I could have the best of both
> > >>> worlds (= support everyone), let me know?
> > >>>
> > >>> Best,
> > >>> Peter
> > >>>
> > >>> On Wed, Feb 23, 2022 at 5:08 PM Eric Broch  
> > >>> wrote:
> >  Does your legacy server qmail-1.03-2.2.1 send to all?
> > 
> >  On 2/23/2022 8:03 AM, Peter Peltonen wrote:
> > > Here is another error I have now seen qmail/send log about 10 times in
> > > the recent hour:
> > >
> > > TLS_connect_failed:_error:141A318A:SSL_routines:tls_process_ske_dhe:dh_key_too_small
> > >
> > > And this has now happened with two pretty big local service provider's
> > > servers as well. I don't think I can continue with the DEFAULT
> > > setting. I will now try to fall back to LEGACY and see if
> > > hornetsecurity.com accepts unencrypted connections. And I really do
> > > not understand the core of this problem: why cannot my server just
> > > have the whole range of ciphers and protocols in use and apply the
> > > most secure / appropriate one that the other party supports?
> > >
> > > Best,
> > > Peter
> > >
> > > On Wed, Feb 23, 2022 at 4:29 PM Eric Broch  
> > > wrote:
> > >> If I remember correctly it had something to do with Dovecot
> > >> On Feb 23, 2022, at 2:25 AM, Peter Peltonen 
> > >>  wrote:
> > >>> Hello,
> > >>>
> > >>> Okay I now tested::
> > >>>
> > >>> With LEGACY (which I had earlier) I get the
> > >>> SSL_routines:set_client_ciphesuite:wrong_cipher_returned error in 
> > >>> qmail/send log:
> > >>>
> > >>> But with DEFAULT I get Remote_host_said:_250_2.0.0_OK_accept as the 
> > >>> result
> > >>>
> > >>> And I did the test without rebooting nor restarting qmail.
> > >>>
> > >>> So apparently this command did the trick like Eric suggested:
> > >>>
> > >>> update-crypto-policies --set DEFAULT
> > >>>
> > >>> Now I wonder if this has some other consequences, what 

Re: [qmailtoaster] TLS connection failed: ciphersuite wrong

[Peter Peltonen]

Now after monitoring 36h after the change no cipher related errors,
but a few servers apparently have problems with higher TLS versions:

TLS_connect_failed:_error:1425F102:SSL_routines:ssl_choose_client_version:unsupported_protocol

I assume that this is due to these
/etc/crypto-policies/back-ends/opensslcnf.config settings:

TLS.MinProtocol = TLSv1.2
TLS.MaxProtocol = TLSv1.3
DTLS.MinProtocol = DTLSv1.2
DTLS.MaxProtocol = DTLSv1.2

If I lower MinProtocol to TLSv1.0 would that enable access to those
servers but use the higher protocol version for the rest of the world?

Best,
Peter


On Mon, Feb 28, 2022 at 1:44 AM Eric Broch  wrote:
>
> I'd like to implement this programmatically so that we can set
> parameters in a /var/qmail/control/sslconf file
>
> On 2/27/2022 2:25 PM, Peter Peltonen wrote:
> > Hi Eric,
> >
> > Okay my crypto-policy is now DEFAULT again and in opensslcnf.config I now 
> > have:
> >
> > CipherString = 
> > DEFAULT@SECLEVEL=1:kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:-aDSS:-3DES:!DES:!RC4:!RC2:!IDEA:-SEED:!eNULL:!aNULL:!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8
> >
> > I am grepping ssl from qmail/send log. Let's see how it goes.
> >
> > Best,
> > Peter
> >
> > On Thu, Feb 24, 2022 at 7:36 PM Eric Broch  wrote:
> >> Peter,
> >>
> >> Can you try something with your server to get mail delivery to normal.
> >> Run command:
> >>
> >> update-crypto-policies --set DEFAULT
> >>
> >> Edit file  /etc/crypto-policies/back-ends/opensslcnf.config particularly
> >> setting
> >>
> >> CipherString = @SECLEVEL=2
> >>
> >> change to
> >>
> >> CipherString = DEFAULT@SECLEVEL=1
> >>
> >> Watch logs
> >>
> >> Eric
> >>
> >> On 2/23/2022 8:53 AM, Peter Peltonen wrote:
> >>> You mean my server with qmail-1.03-3.3.1.qt.md.el8.x86_64 (not
> >>> qmail-1.03-2.2.1) with the LEGACY setting?
> >>>
> >>> As far as I know the only problem I am having is with the
> >>> hornetsecurity.com servers. But to be honest I have not really been
> >>> monitoring the logs that carefully, that's the only server I've
> >>> received a complain about. I now tried sending them email with
> >>> unencrypted connection and it failed.
> >>>
> >>> So I think I will now leave it to LEGACY, accept that I cannot deliver
> >>> mail to the hornet serers and keep monitoring now more closely for TLS
> >>> errors in the logs: if more turn up then I might consider again
> >>> switching to DEFAULT and then adding those servers to notlshosts/
> >>> although that looks like a nonendint task.
> >>>
> >>> If someone comes up with a solution how I could have the best of both
> >>> worlds (= support everyone), let me know?
> >>>
> >>> Best,
> >>> Peter
> >>>
> >>> On Wed, Feb 23, 2022 at 5:08 PM Eric Broch  
> >>> wrote:
>  Does your legacy server qmail-1.03-2.2.1 send to all?
> 
>  On 2/23/2022 8:03 AM, Peter Peltonen wrote:
> > Here is another error I have now seen qmail/send log about 10 times in
> > the recent hour:
> >
> > TLS_connect_failed:_error:141A318A:SSL_routines:tls_process_ske_dhe:dh_key_too_small
> >
> > And this has now happened with two pretty big local service provider's
> > servers as well. I don't think I can continue with the DEFAULT
> > setting. I will now try to fall back to LEGACY and see if
> > hornetsecurity.com accepts unencrypted connections. And I really do
> > not understand the core of this problem: why cannot my server just
> > have the whole range of ciphers and protocols in use and apply the
> > most secure / appropriate one that the other party supports?
> >
> > Best,
> > Peter
> >
> > On Wed, Feb 23, 2022 at 4:29 PM Eric Broch  
> > wrote:
> >> If I remember correctly it had something to do with Dovecot
> >> On Feb 23, 2022, at 2:25 AM, Peter Peltonen  
> >> wrote:
> >>> Hello,
> >>>
> >>> Okay I now tested::
> >>>
> >>> With LEGACY (which I had earlier) I get the
> >>> SSL_routines:set_client_ciphesuite:wrong_cipher_returned error in 
> >>> qmail/send log:
> >>>
> >>> But with DEFAULT I get Remote_host_said:_250_2.0.0_OK_accept as the 
> >>> result
> >>>
> >>> And I did the test without rebooting nor restarting qmail.
> >>>
> >>> So apparently this command did the trick like Eric suggested:
> >>>
> >>> update-crypto-policies --set DEFAULT
> >>>
> >>> Now I wonder if this has some other consequences, what legacy stuff 
> >>> is now incompatible...?
> >>>
> >>> Best,
> >>> Peter
> >>>
> >>>
> >>> ma 21. helmik. 2022 klo 17.55 Eric Broch < ebr...@whitehorsetc.com> 
> >>> kirjoitti:
>  reboot
> 
>  On 2/21/2022 8:30 AM, Peter Peltonen wrote:
> > Thanks Eric for the update. Here is what I see:
> >
> > [root@mail ~]# update-crypto-policies --show
> > LEGACY
> > [root@mail ~]# update-crypto-policies --set DEFAULT
> > Setting system policy to DEFAULT
> > No

Re: [qmailtoaster] TLS connection failed: ciphersuite wrong

[Eric Broch]

I'd like to implement this programmatically so that we can set 
parameters in a /var/qmail/control/sslconf file


On 2/27/2022 2:25 PM, Peter Peltonen wrote:

Hi Eric,

Okay my crypto-policy is now DEFAULT again and in opensslcnf.config I now have:

CipherString = 
DEFAULT@SECLEVEL=1:kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:-aDSS:-3DES:!DES:!RC4:!RC2:!IDEA:-SEED:!eNULL:!aNULL:!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8

I am grepping ssl from qmail/send log. Let's see how it goes.

Best,
Peter

On Thu, Feb 24, 2022 at 7:36 PM Eric Broch  wrote:

Peter,

Can you try something with your server to get mail delivery to normal.
Run command:

update-crypto-policies --set DEFAULT

Edit file  /etc/crypto-policies/back-ends/opensslcnf.config particularly
setting

CipherString = @SECLEVEL=2

change to

CipherString = DEFAULT@SECLEVEL=1

Watch logs

Eric

On 2/23/2022 8:53 AM, Peter Peltonen wrote:

You mean my server with qmail-1.03-3.3.1.qt.md.el8.x86_64 (not
qmail-1.03-2.2.1) with the LEGACY setting?

As far as I know the only problem I am having is with the
hornetsecurity.com servers. But to be honest I have not really been
monitoring the logs that carefully, that's the only server I've
received a complain about. I now tried sending them email with
unencrypted connection and it failed.

So I think I will now leave it to LEGACY, accept that I cannot deliver
mail to the hornet serers and keep monitoring now more closely for TLS
errors in the logs: if more turn up then I might consider again
switching to DEFAULT and then adding those servers to notlshosts/
although that looks like a nonendint task.

If someone comes up with a solution how I could have the best of both
worlds (= support everyone), let me know?

Best,
Peter

On Wed, Feb 23, 2022 at 5:08 PM Eric Broch  wrote:

Does your legacy server qmail-1.03-2.2.1 send to all?

On 2/23/2022 8:03 AM, Peter Peltonen wrote:

Here is another error I have now seen qmail/send log about 10 times in
the recent hour:

TLS_connect_failed:_error:141A318A:SSL_routines:tls_process_ske_dhe:dh_key_too_small

And this has now happened with two pretty big local service provider's
servers as well. I don't think I can continue with the DEFAULT
setting. I will now try to fall back to LEGACY and see if
hornetsecurity.com accepts unencrypted connections. And I really do
not understand the core of this problem: why cannot my server just
have the whole range of ciphers and protocols in use and apply the
most secure / appropriate one that the other party supports?

Best,
Peter

On Wed, Feb 23, 2022 at 4:29 PM Eric Broch  wrote:

If I remember correctly it had something to do with Dovecot
On Feb 23, 2022, at 2:25 AM, Peter Peltonen  wrote:

Hello,

Okay I now tested::

With LEGACY (which I had earlier) I get the
SSL_routines:set_client_ciphesuite:wrong_cipher_returned error in qmail/send 
log:

But with DEFAULT I get Remote_host_said:_250_2.0.0_OK_accept as the result

And I did the test without rebooting nor restarting qmail.

So apparently this command did the trick like Eric suggested:

update-crypto-policies --set DEFAULT

Now I wonder if this has some other consequences, what legacy stuff is now 
incompatible...?

Best,
Peter


ma 21. helmik. 2022 klo 17.55 Eric Broch < ebr...@whitehorsetc.com> kirjoitti:

reboot

On 2/21/2022 8:30 AM, Peter Peltonen wrote:

Thanks Eric for the update. Here is what I see:

[root@mail ~]# update-crypto-policies --show
LEGACY
[root@mail ~]# update-crypto-policies --set DEFAULT
Setting system policy to DEFAULT
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.

Is restarting qmail enough or should I even reboot?

And is there some difference between DEFAULT and FUTURE or are they the same?

Best,
Peter

On Mon, Feb 21, 2022 at 4:39 PM Eric Broch < ebr...@whitehorsetc.com> wrote:

Upon further reflection, at the end of the qt/cos8 install script there
is a command, 'update-crypto-policies --set LEGACY' intended for old
email clients I don't wonder if this change between cos7 and cos8 might
caused the problem. Have a look here:

https://www.redhat.com/en/blog/how-customize-crypto-policies-rhel-82

If you've change it to 'update-crypto-policies --set DEFAULT' or
'update-crypto-policies --set FUTURE' and are still having issue ask
hornet security if we can see the actual smtp transaction.

In my earlier email I was saying that there was not much difference
between the old code and the new code for remote delivery and it was not
immediately obvious why we would be having a problem.

Eric


On 2/21/2022 7:17 AM, Peter Peltonen wrote:

Hi,

Is there something I can test? I didn't quite understand from Eric's
earlier msg what I should try...

One email address producing this error for me is
supp...@hornetsecurity.com -> If you like Eric, you could try emailing
themselves asking for more details (either they reply to you or you
will face the same error). If you don'

Re: [qmailtoaster] TLS connection failed: ciphersuite wrong

[Peter Peltonen]

Hi Eric,

Okay my crypto-policy is now DEFAULT again and in opensslcnf.config I now have:

CipherString = 
DEFAULT@SECLEVEL=1:kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:-aDSS:-3DES:!DES:!RC4:!RC2:!IDEA:-SEED:!eNULL:!aNULL:!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8

I am grepping ssl from qmail/send log. Let's see how it goes.

Best,
Peter

On Thu, Feb 24, 2022 at 7:36 PM Eric Broch  wrote:
>
> Peter,
>
> Can you try something with your server to get mail delivery to normal.
> Run command:
>
> update-crypto-policies --set DEFAULT
>
> Edit file  /etc/crypto-policies/back-ends/opensslcnf.config particularly
> setting
>
> CipherString = @SECLEVEL=2
>
> change to
>
> CipherString = DEFAULT@SECLEVEL=1
>
> Watch logs
>
> Eric
>
> On 2/23/2022 8:53 AM, Peter Peltonen wrote:
> > You mean my server with qmail-1.03-3.3.1.qt.md.el8.x86_64 (not
> > qmail-1.03-2.2.1) with the LEGACY setting?
> >
> > As far as I know the only problem I am having is with the
> > hornetsecurity.com servers. But to be honest I have not really been
> > monitoring the logs that carefully, that's the only server I've
> > received a complain about. I now tried sending them email with
> > unencrypted connection and it failed.
> >
> > So I think I will now leave it to LEGACY, accept that I cannot deliver
> > mail to the hornet serers and keep monitoring now more closely for TLS
> > errors in the logs: if more turn up then I might consider again
> > switching to DEFAULT and then adding those servers to notlshosts/
> > although that looks like a nonendint task.
> >
> > If someone comes up with a solution how I could have the best of both
> > worlds (= support everyone), let me know?
> >
> > Best,
> > Peter
> >
> > On Wed, Feb 23, 2022 at 5:08 PM Eric Broch  wrote:
> >> Does your legacy server qmail-1.03-2.2.1 send to all?
> >>
> >> On 2/23/2022 8:03 AM, Peter Peltonen wrote:
> >>> Here is another error I have now seen qmail/send log about 10 times in
> >>> the recent hour:
> >>>
> >>> TLS_connect_failed:_error:141A318A:SSL_routines:tls_process_ske_dhe:dh_key_too_small
> >>>
> >>> And this has now happened with two pretty big local service provider's
> >>> servers as well. I don't think I can continue with the DEFAULT
> >>> setting. I will now try to fall back to LEGACY and see if
> >>> hornetsecurity.com accepts unencrypted connections. And I really do
> >>> not understand the core of this problem: why cannot my server just
> >>> have the whole range of ciphers and protocols in use and apply the
> >>> most secure / appropriate one that the other party supports?
> >>>
> >>> Best,
> >>> Peter
> >>>
> >>> On Wed, Feb 23, 2022 at 4:29 PM Eric Broch  
> >>> wrote:
>  If I remember correctly it had something to do with Dovecot
>  On Feb 23, 2022, at 2:25 AM, Peter Peltonen  
>  wrote:
> > Hello,
> >
> > Okay I now tested::
> >
> > With LEGACY (which I had earlier) I get the
> > SSL_routines:set_client_ciphesuite:wrong_cipher_returned error in 
> > qmail/send log:
> >
> > But with DEFAULT I get Remote_host_said:_250_2.0.0_OK_accept as the 
> > result
> >
> > And I did the test without rebooting nor restarting qmail.
> >
> > So apparently this command did the trick like Eric suggested:
> >
> > update-crypto-policies --set DEFAULT
> >
> > Now I wonder if this has some other consequences, what legacy stuff is 
> > now incompatible...?
> >
> > Best,
> > Peter
> >
> >
> > ma 21. helmik. 2022 klo 17.55 Eric Broch < ebr...@whitehorsetc.com> 
> > kirjoitti:
> >> reboot
> >>
> >> On 2/21/2022 8:30 AM, Peter Peltonen wrote:
> >>> Thanks Eric for the update. Here is what I see:
> >>>
> >>> [root@mail ~]# update-crypto-policies --show
> >>> LEGACY
> >>> [root@mail ~]# update-crypto-policies --set DEFAULT
> >>> Setting system policy to DEFAULT
> >>> Note: System-wide crypto policies are applied on application start-up.
> >>> It is recommended to restart the system for the change of policies
> >>> to fully take place.
> >>>
> >>> Is restarting qmail enough or should I even reboot?
> >>>
> >>> And is there some difference between DEFAULT and FUTURE or are they 
> >>> the same?
> >>>
> >>> Best,
> >>> Peter
> >>>
> >>> On Mon, Feb 21, 2022 at 4:39 PM Eric Broch < ebr...@whitehorsetc.com> 
> >>> wrote:
>  Upon further reflection, at the end of the qt/cos8 install script 
>  there
>  is a command, 'update-crypto-policies --set LEGACY' intended for old
>  email clients I don't wonder if this change between cos7 and cos8 
>  might
>  caused the problem. Have a look here:
> 
>  https://www.redhat.com/en/blog/how-customize-crypto-policies-rhel-82
> 
>  If you've change it to 'update-crypto-policies --set DEFAULT' or
>  'update-crypto-policies --set FUTURE' and are still having issue ask
> >

Re: [qmailtoaster] TLS connection failed: ciphersuite wrong

[Eric Broch]

Peter,

Can you try something with your server to get mail delivery to normal. 
Run command:


update-crypto-policies --set DEFAULT

Edit file  /etc/crypto-policies/back-ends/opensslcnf.config particularly 
setting


CipherString = @SECLEVEL=2

change to

CipherString = DEFAULT@SECLEVEL=1

Watch logs

Eric

On 2/23/2022 8:53 AM, Peter Peltonen wrote:

You mean my server with qmail-1.03-3.3.1.qt.md.el8.x86_64 (not
qmail-1.03-2.2.1) with the LEGACY setting?

As far as I know the only problem I am having is with the
hornetsecurity.com servers. But to be honest I have not really been
monitoring the logs that carefully, that's the only server I've
received a complain about. I now tried sending them email with
unencrypted connection and it failed.

So I think I will now leave it to LEGACY, accept that I cannot deliver
mail to the hornet serers and keep monitoring now more closely for TLS
errors in the logs: if more turn up then I might consider again
switching to DEFAULT and then adding those servers to notlshosts/
although that looks like a nonendint task.

If someone comes up with a solution how I could have the best of both
worlds (= support everyone), let me know?

Best,
Peter

On Wed, Feb 23, 2022 at 5:08 PM Eric Broch  wrote:

Does your legacy server qmail-1.03-2.2.1 send to all?

On 2/23/2022 8:03 AM, Peter Peltonen wrote:

Here is another error I have now seen qmail/send log about 10 times in
the recent hour:

TLS_connect_failed:_error:141A318A:SSL_routines:tls_process_ske_dhe:dh_key_too_small

And this has now happened with two pretty big local service provider's
servers as well. I don't think I can continue with the DEFAULT
setting. I will now try to fall back to LEGACY and see if
hornetsecurity.com accepts unencrypted connections. And I really do
not understand the core of this problem: why cannot my server just
have the whole range of ciphers and protocols in use and apply the
most secure / appropriate one that the other party supports?

Best,
Peter

On Wed, Feb 23, 2022 at 4:29 PM Eric Broch  wrote:

If I remember correctly it had something to do with Dovecot
On Feb 23, 2022, at 2:25 AM, Peter Peltonen  wrote:

Hello,

Okay I now tested::

With LEGACY (which I had earlier) I get the
SSL_routines:set_client_ciphesuite:wrong_cipher_returned error in qmail/send 
log:

But with DEFAULT I get Remote_host_said:_250_2.0.0_OK_accept as the result

And I did the test without rebooting nor restarting qmail.

So apparently this command did the trick like Eric suggested:

update-crypto-policies --set DEFAULT

Now I wonder if this has some other consequences, what legacy stuff is now 
incompatible...?

Best,
Peter


ma 21. helmik. 2022 klo 17.55 Eric Broch < ebr...@whitehorsetc.com> kirjoitti:

reboot

On 2/21/2022 8:30 AM, Peter Peltonen wrote:

Thanks Eric for the update. Here is what I see:

[root@mail ~]# update-crypto-policies --show
LEGACY
[root@mail ~]# update-crypto-policies --set DEFAULT
Setting system policy to DEFAULT
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.

Is restarting qmail enough or should I even reboot?

And is there some difference between DEFAULT and FUTURE or are they the same?

Best,
Peter

On Mon, Feb 21, 2022 at 4:39 PM Eric Broch < ebr...@whitehorsetc.com> wrote:

Upon further reflection, at the end of the qt/cos8 install script there
is a command, 'update-crypto-policies --set LEGACY' intended for old
email clients I don't wonder if this change between cos7 and cos8 might
caused the problem. Have a look here:

https://www.redhat.com/en/blog/how-customize-crypto-policies-rhel-82

If you've change it to 'update-crypto-policies --set DEFAULT' or
'update-crypto-policies --set FUTURE' and are still having issue ask
hornet security if we can see the actual smtp transaction.

In my earlier email I was saying that there was not much difference
between the old code and the new code for remote delivery and it was not
immediately obvious why we would be having a problem.

Eric


On 2/21/2022 7:17 AM, Peter Peltonen wrote:

Hi,

Is there something I can test? I didn't quite understand from Eric's
earlier msg what I should try...

One email address producing this error for me is
supp...@hornetsecurity.com -> If you like Eric, you could try emailing
themselves asking for more details (either they reply to you or you
will face the same error). If you don't face the same error then we
could try figuring out what is different in our setups?

Best,
Peter




On Sat, Feb 19, 2022 at 6:29 PM Eric Broch < ebr...@whitehorsetc.com> wrote:

Looking through the function tls_init() in the code for qmail-remote.c

I don't see much that it could be, they're almost identical between
2.2.1 and 3.3.5

Will continue looking...

On 2/18/2022 1:54 PM, Andreas Galatis wrote:

Hi Finn,


I have tested with the tlsserverciphers of my older server, completed
with some of the ciphers from the new file and my

Re: [qmailtoaster] TLS connection failed: ciphersuite wrong

[Andreas]

Hi List,

Since having setup the cipher-policy to DEFAULT I had no more failures 
for wrong ciphersuite.
Even the hornetservers can be reached (they told me they accept TLS1.2 
and TLS1.3 only).


Until having changed the policy I routed all mails to domains that 
didn't accept my ciphers via my old server with qmail-1.03-2.2.1 and had 
no issues.


The only issue I actually know off is that my clients cannot 
authenticate with an alias-name.


I thank all developers working on qmailtoaster for this great software 
that I use and appreciate since many years.



Andreas




Am 23.02.22 um 17:07 schrieb Eric Broch:

when you run the command

update-crypto-policies --set 'POLICY'

it actually modifies the file

/etc/crypto-policies/back-ends/opensslcnf.config

If you set to DEFAULT you may be able to modify the file with the 
correct cipher


Eric

On 2/23/2022 9:49 AM, xaf wrote:

Peter Peltonen a écrit le 23/02/2022 à 16:53 :

So I think I will now leave it to LEGACY, accept that I cannot deliver
mail to the hornet serers and keep monitoring now more closely for TLS
errors in the logs: if more turn up then I might consider again
switching to DEFAULT and then adding those servers to notlshosts/
although that looks like a nonendint task.

provides
cat /etc/redhat-release
cat /usr/share/crypto-policies/LEGACY/opensslcnf.txt

xaf


-
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




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

Re: [qmailtoaster] TLS connection failed: ciphersuite wrong

[Eric Broch]

when you run the command

update-crypto-policies --set 'POLICY'

it actually modifies the file

/etc/crypto-policies/back-ends/opensslcnf.config

If you set to DEFAULT you may be able to modify the file with the 
correct cipher


Eric

On 2/23/2022 9:49 AM, xaf wrote:

Peter Peltonen a écrit le 23/02/2022 à 16:53 :

So I think I will now leave it to LEGACY, accept that I cannot deliver
mail to the hornet serers and keep monitoring now more closely for TLS
errors in the logs: if more turn up then I might consider again
switching to DEFAULT and then adding those servers to notlshosts/
although that looks like a nonendint task.

provides
cat /etc/redhat-release
cat /usr/share/crypto-policies/LEGACY/opensslcnf.txt

xaf


-
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] TLS connection failed: ciphersuite wrong

[Eric Broch]

No, I miss spoke, I meant the server you have with qmail-1.03-2.2.1

On 2/23/2022 8:53 AM, Peter Peltonen wrote:

You mean my server with qmail-1.03-3.3.1.qt.md.el8.x86_64 (not
qmail-1.03-2.2.1) with the LEGACY setting?

As far as I know the only problem I am having is with the
hornetsecurity.com servers. But to be honest I have not really been
monitoring the logs that carefully, that's the only server I've
received a complain about. I now tried sending them email with
unencrypted connection and it failed.

So I think I will now leave it to LEGACY, accept that I cannot deliver
mail to the hornet serers and keep monitoring now more closely for TLS
errors in the logs: if more turn up then I might consider again
switching to DEFAULT and then adding those servers to notlshosts/
although that looks like a nonendint task.

If someone comes up with a solution how I could have the best of both
worlds (= support everyone), let me know?

Best,
Peter

On Wed, Feb 23, 2022 at 5:08 PM Eric Broch  wrote:

Does your legacy server qmail-1.03-2.2.1 send to all?

On 2/23/2022 8:03 AM, Peter Peltonen wrote:

Here is another error I have now seen qmail/send log about 10 times in
the recent hour:

TLS_connect_failed:_error:141A318A:SSL_routines:tls_process_ske_dhe:dh_key_too_small

And this has now happened with two pretty big local service provider's
servers as well. I don't think I can continue with the DEFAULT
setting. I will now try to fall back to LEGACY and see if
hornetsecurity.com accepts unencrypted connections. And I really do
not understand the core of this problem: why cannot my server just
have the whole range of ciphers and protocols in use and apply the
most secure / appropriate one that the other party supports?

Best,
Peter

On Wed, Feb 23, 2022 at 4:29 PM Eric Broch  wrote:

If I remember correctly it had something to do with Dovecot
On Feb 23, 2022, at 2:25 AM, Peter Peltonen  wrote:

Hello,

Okay I now tested::

With LEGACY (which I had earlier) I get the
SSL_routines:set_client_ciphesuite:wrong_cipher_returned error in qmail/send 
log:

But with DEFAULT I get Remote_host_said:_250_2.0.0_OK_accept as the result

And I did the test without rebooting nor restarting qmail.

So apparently this command did the trick like Eric suggested:

update-crypto-policies --set DEFAULT

Now I wonder if this has some other consequences, what legacy stuff is now 
incompatible...?

Best,
Peter


ma 21. helmik. 2022 klo 17.55 Eric Broch < ebr...@whitehorsetc.com> kirjoitti:

reboot

On 2/21/2022 8:30 AM, Peter Peltonen wrote:

Thanks Eric for the update. Here is what I see:

[root@mail ~]# update-crypto-policies --show
LEGACY
[root@mail ~]# update-crypto-policies --set DEFAULT
Setting system policy to DEFAULT
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.

Is restarting qmail enough or should I even reboot?

And is there some difference between DEFAULT and FUTURE or are they the same?

Best,
Peter

On Mon, Feb 21, 2022 at 4:39 PM Eric Broch < ebr...@whitehorsetc.com> wrote:

Upon further reflection, at the end of the qt/cos8 install script there
is a command, 'update-crypto-policies --set LEGACY' intended for old
email clients I don't wonder if this change between cos7 and cos8 might
caused the problem. Have a look here:

https://www.redhat.com/en/blog/how-customize-crypto-policies-rhel-82

If you've change it to 'update-crypto-policies --set DEFAULT' or
'update-crypto-policies --set FUTURE' and are still having issue ask
hornet security if we can see the actual smtp transaction.

In my earlier email I was saying that there was not much difference
between the old code and the new code for remote delivery and it was not
immediately obvious why we would be having a problem.

Eric


On 2/21/2022 7:17 AM, Peter Peltonen wrote:

Hi,

Is there something I can test? I didn't quite understand from Eric's
earlier msg what I should try...

One email address producing this error for me is
supp...@hornetsecurity.com -> If you like Eric, you could try emailing
themselves asking for more details (either they reply to you or you
will face the same error). If you don't face the same error then we
could try figuring out what is different in our setups?

Best,
Peter




On Sat, Feb 19, 2022 at 6:29 PM Eric Broch < ebr...@whitehorsetc.com> wrote:

Looking through the function tls_init() in the code for qmail-remote.c

I don't see much that it could be, they're almost identical between
2.2.1 and 3.3.5

Will continue looking...

On 2/18/2022 1:54 PM, Andreas Galatis wrote:

Hi Finn,


I have tested with the tlsserverciphers of my older server, completed
with some of the ciphers from the new file and my mails came through.


Thanks a lot for your tip, Finn, I didn't find it in the code


Andreas


Am 18.02.22 um 16:56 schrieb Qmail:

Hi Andreas.

In qmail You're properly using /var/qmail/control/tlsclientciphers
(that are a link to tlcser

Re: [qmailtoaster] TLS connection failed: ciphersuite wrong

[Peter Peltonen]

You mean my server with qmail-1.03-3.3.1.qt.md.el8.x86_64 (not
qmail-1.03-2.2.1) with the LEGACY setting?

As far as I know the only problem I am having is with the
hornetsecurity.com servers. But to be honest I have not really been
monitoring the logs that carefully, that's the only server I've
received a complain about. I now tried sending them email with
unencrypted connection and it failed.

So I think I will now leave it to LEGACY, accept that I cannot deliver
mail to the hornet serers and keep monitoring now more closely for TLS
errors in the logs: if more turn up then I might consider again
switching to DEFAULT and then adding those servers to notlshosts/
although that looks like a nonendint task.

If someone comes up with a solution how I could have the best of both
worlds (= support everyone), let me know?

Best,
Peter

On Wed, Feb 23, 2022 at 5:08 PM Eric Broch  wrote:
>
> Does your legacy server qmail-1.03-2.2.1 send to all?
>
> On 2/23/2022 8:03 AM, Peter Peltonen wrote:
> > Here is another error I have now seen qmail/send log about 10 times in
> > the recent hour:
> >
> > TLS_connect_failed:_error:141A318A:SSL_routines:tls_process_ske_dhe:dh_key_too_small
> >
> > And this has now happened with two pretty big local service provider's
> > servers as well. I don't think I can continue with the DEFAULT
> > setting. I will now try to fall back to LEGACY and see if
> > hornetsecurity.com accepts unencrypted connections. And I really do
> > not understand the core of this problem: why cannot my server just
> > have the whole range of ciphers and protocols in use and apply the
> > most secure / appropriate one that the other party supports?
> >
> > Best,
> > Peter
> >
> > On Wed, Feb 23, 2022 at 4:29 PM Eric Broch  wrote:
> >> If I remember correctly it had something to do with Dovecot
> >> On Feb 23, 2022, at 2:25 AM, Peter Peltonen  
> >> wrote:
> >>> Hello,
> >>>
> >>> Okay I now tested::
> >>>
> >>> With LEGACY (which I had earlier) I get the
> >>> SSL_routines:set_client_ciphesuite:wrong_cipher_returned error in 
> >>> qmail/send log:
> >>>
> >>> But with DEFAULT I get Remote_host_said:_250_2.0.0_OK_accept as the result
> >>>
> >>> And I did the test without rebooting nor restarting qmail.
> >>>
> >>> So apparently this command did the trick like Eric suggested:
> >>>
> >>> update-crypto-policies --set DEFAULT
> >>>
> >>> Now I wonder if this has some other consequences, what legacy stuff is 
> >>> now incompatible...?
> >>>
> >>> Best,
> >>> Peter
> >>>
> >>>
> >>> ma 21. helmik. 2022 klo 17.55 Eric Broch < ebr...@whitehorsetc.com> 
> >>> kirjoitti:
>  reboot
> 
>  On 2/21/2022 8:30 AM, Peter Peltonen wrote:
> > Thanks Eric for the update. Here is what I see:
> >
> > [root@mail ~]# update-crypto-policies --show
> > LEGACY
> > [root@mail ~]# update-crypto-policies --set DEFAULT
> > Setting system policy to DEFAULT
> > Note: System-wide crypto policies are applied on application start-up.
> > It is recommended to restart the system for the change of policies
> > to fully take place.
> >
> > Is restarting qmail enough or should I even reboot?
> >
> > And is there some difference between DEFAULT and FUTURE or are they the 
> > same?
> >
> > Best,
> > Peter
> >
> > On Mon, Feb 21, 2022 at 4:39 PM Eric Broch < ebr...@whitehorsetc.com> 
> > wrote:
> >> Upon further reflection, at the end of the qt/cos8 install script there
> >> is a command, 'update-crypto-policies --set LEGACY' intended for old
> >> email clients I don't wonder if this change between cos7 and cos8 might
> >> caused the problem. Have a look here:
> >>
> >> https://www.redhat.com/en/blog/how-customize-crypto-policies-rhel-82
> >>
> >> If you've change it to 'update-crypto-policies --set DEFAULT' or
> >> 'update-crypto-policies --set FUTURE' and are still having issue ask
> >> hornet security if we can see the actual smtp transaction.
> >>
> >> In my earlier email I was saying that there was not much difference
> >> between the old code and the new code for remote delivery and it was 
> >> not
> >> immediately obvious why we would be having a problem.
> >>
> >> Eric
> >>
> >>
> >> On 2/21/2022 7:17 AM, Peter Peltonen wrote:
> >>> Hi,
> >>>
> >>> Is there something I can test? I didn't quite understand from Eric's
> >>> earlier msg what I should try...
> >>>
> >>> One email address producing this error for me is
> >>> supp...@hornetsecurity.com -> If you like Eric, you could try emailing
> >>> themselves asking for more details (either they reply to you or you
> >>> will face the same error). If you don't face the same error then we
> >>> could try figuring out what is different in our setups?
> >>>
> >>> Best,
> >>> Peter
> >>>
> >>>
> >>>
> >>>
> >>> On Sat, Feb 19, 2022 at 6:29 PM Eric Broch < eb

Re: [qmailtoaster] TLS connection failed: ciphersuite wrong

[Eric Broch]

Does your legacy server qmail-1.03-2.2.1 send to all?

On 2/23/2022 8:03 AM, Peter Peltonen wrote:

Here is another error I have now seen qmail/send log about 10 times in
the recent hour:

TLS_connect_failed:_error:141A318A:SSL_routines:tls_process_ske_dhe:dh_key_too_small

And this has now happened with two pretty big local service provider's
servers as well. I don't think I can continue with the DEFAULT
setting. I will now try to fall back to LEGACY and see if
hornetsecurity.com accepts unencrypted connections. And I really do
not understand the core of this problem: why cannot my server just
have the whole range of ciphers and protocols in use and apply the
most secure / appropriate one that the other party supports?

Best,
Peter

On Wed, Feb 23, 2022 at 4:29 PM Eric Broch  wrote:

If I remember correctly it had something to do with Dovecot
On Feb 23, 2022, at 2:25 AM, Peter Peltonen  wrote:

Hello,

Okay I now tested::

With LEGACY (which I had earlier) I get the
SSL_routines:set_client_ciphesuite:wrong_cipher_returned error in qmail/send 
log:

But with DEFAULT I get Remote_host_said:_250_2.0.0_OK_accept as the result

And I did the test without rebooting nor restarting qmail.

So apparently this command did the trick like Eric suggested:

update-crypto-policies --set DEFAULT

Now I wonder if this has some other consequences, what legacy stuff is now 
incompatible...?

Best,
Peter


ma 21. helmik. 2022 klo 17.55 Eric Broch < ebr...@whitehorsetc.com> kirjoitti:

reboot

On 2/21/2022 8:30 AM, Peter Peltonen wrote:

Thanks Eric for the update. Here is what I see:

[root@mail ~]# update-crypto-policies --show
LEGACY
[root@mail ~]# update-crypto-policies --set DEFAULT
Setting system policy to DEFAULT
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.

Is restarting qmail enough or should I even reboot?

And is there some difference between DEFAULT and FUTURE or are they the same?

Best,
Peter

On Mon, Feb 21, 2022 at 4:39 PM Eric Broch < ebr...@whitehorsetc.com> wrote:

Upon further reflection, at the end of the qt/cos8 install script there
is a command, 'update-crypto-policies --set LEGACY' intended for old
email clients I don't wonder if this change between cos7 and cos8 might
caused the problem. Have a look here:

https://www.redhat.com/en/blog/how-customize-crypto-policies-rhel-82

If you've change it to 'update-crypto-policies --set DEFAULT' or
'update-crypto-policies --set FUTURE' and are still having issue ask
hornet security if we can see the actual smtp transaction.

In my earlier email I was saying that there was not much difference
between the old code and the new code for remote delivery and it was not
immediately obvious why we would be having a problem.

Eric


On 2/21/2022 7:17 AM, Peter Peltonen wrote:

Hi,

Is there something I can test? I didn't quite understand from Eric's
earlier msg what I should try...

One email address producing this error for me is
supp...@hornetsecurity.com -> If you like Eric, you could try emailing
themselves asking for more details (either they reply to you or you
will face the same error). If you don't face the same error then we
could try figuring out what is different in our setups?

Best,
Peter




On Sat, Feb 19, 2022 at 6:29 PM Eric Broch < ebr...@whitehorsetc.com> wrote:

Looking through the function tls_init() in the code for qmail-remote.c

I don't see much that it could be, they're almost identical between
2.2.1 and 3.3.5

Will continue looking...

On 2/18/2022 1:54 PM, Andreas Galatis wrote:

Hi Finn,


I have tested with the tlsserverciphers of my older server, completed
with some of the ciphers from the new file and my mails came through.


Thanks a lot for your tip, Finn, I didn't find it in the code


Andreas


Am 18.02.22 um 16:56 schrieb Qmail:

Hi Andreas.

In qmail You're properly using /var/qmail/control/tlsclientciphers
(that are a link to tlcserverciphers)

According to what I read at the Nginx forum, the problem there is
because some of the included ciphers are with underscore '_' and not
hyphen '-' - I don't know if changing that in the tlsservercipher
file will solve the problem.


/Finn

Den 18-02-2022 kl. 16:29 skrev Andreas:

I cannot find any file where those ciphers could be adjust.
Is that compiled in?

Me too, I have clients not beeing reachable with the new server
(qmail-1.03-3.3.5), but my old server running qmail-1.03.2.2.1.qt.
Did anyone find a solution?

Andreas

Am 17.02.22 um 20:28 schrieb Qmail:

Hi.

Not sure it is related, but I just read in the Nginx forum that
some have issues (failed (SSL: error:0AB9:SSL routines::no
cipher match)) using Mozillas 'modern' 5.5 ciphers,  but everything
works with Mozillas 'modern' ciphers 4.0.
(found testing the Nginx config)

The 5.5 list contains :

ssl_ciphers'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256';


The 4.0 list contains:

ssl_cipher

Re: [qmailtoaster] TLS connection failed: ciphersuite wrong

[Peter Peltonen]

Here is another error I have now seen qmail/send log about 10 times in
the recent hour:

TLS_connect_failed:_error:141A318A:SSL_routines:tls_process_ske_dhe:dh_key_too_small

And this has now happened with two pretty big local service provider's
servers as well. I don't think I can continue with the DEFAULT
setting. I will now try to fall back to LEGACY and see if
hornetsecurity.com accepts unencrypted connections. And I really do
not understand the core of this problem: why cannot my server just
have the whole range of ciphers and protocols in use and apply the
most secure / appropriate one that the other party supports?

Best,
Peter

On Wed, Feb 23, 2022 at 4:29 PM Eric Broch  wrote:
>
> If I remember correctly it had something to do with Dovecot
> On Feb 23, 2022, at 2:25 AM, Peter Peltonen  wrote:
>>
>> Hello,
>>
>> Okay I now tested::
>>
>> With LEGACY (which I had earlier) I get the
>> SSL_routines:set_client_ciphesuite:wrong_cipher_returned error in qmail/send 
>> log:
>>
>> But with DEFAULT I get Remote_host_said:_250_2.0.0_OK_accept as the result
>>
>> And I did the test without rebooting nor restarting qmail.
>>
>> So apparently this command did the trick like Eric suggested:
>>
>> update-crypto-policies --set DEFAULT
>>
>> Now I wonder if this has some other consequences, what legacy stuff is now 
>> incompatible...?
>>
>> Best,
>> Peter
>>
>>
>> ma 21. helmik. 2022 klo 17.55 Eric Broch < ebr...@whitehorsetc.com> 
>> kirjoitti:
>>>
>>> reboot
>>>
>>> On 2/21/2022 8:30 AM, Peter Peltonen wrote:
>>> > Thanks Eric for the update. Here is what I see:
>>> >
>>> > [root@mail ~]# update-crypto-policies --show
>>> > LEGACY
>>> > [root@mail ~]# update-crypto-policies --set DEFAULT
>>> > Setting system policy to DEFAULT
>>> > Note: System-wide crypto policies are applied on application start-up.
>>> > It is recommended to restart the system for the change of policies
>>> > to fully take place.
>>> >
>>> > Is restarting qmail enough or should I even reboot?
>>> >
>>> > And is there some difference between DEFAULT and FUTURE or are they the 
>>> > same?
>>> >
>>> > Best,
>>> > Peter
>>> >
>>> > On Mon, Feb 21, 2022 at 4:39 PM Eric Broch < ebr...@whitehorsetc.com> 
>>> > wrote:
>>> >> Upon further reflection, at the end of the qt/cos8 install script there
>>> >> is a command, 'update-crypto-policies --set LEGACY' intended for old
>>> >> email clients I don't wonder if this change between cos7 and cos8 might
>>> >> caused the problem. Have a look here:
>>> >>
>>> >> https://www.redhat.com/en/blog/how-customize-crypto-policies-rhel-82
>>> >>
>>> >> If you've change it to 'update-crypto-policies --set DEFAULT' or
>>> >> 'update-crypto-policies --set FUTURE' and are still having issue ask
>>> >> hornet security if we can see the actual smtp transaction.
>>> >>
>>> >> In my earlier email I was saying that there was not much difference
>>> >> between the old code and the new code for remote delivery and it was not
>>> >> immediately obvious why we would be having a problem.
>>> >>
>>> >> Eric
>>> >>
>>> >>
>>> >> On 2/21/2022 7:17 AM, Peter Peltonen wrote:
>>> >>> Hi,
>>> >>>
>>> >>> Is there something I can test? I didn't quite understand from Eric's
>>> >>> earlier msg what I should try...
>>> >>>
>>> >>> One email address producing this error for me is
>>> >>> supp...@hornetsecurity.com -> If you like Eric, you could try emailing
>>> >>> themselves asking for more details (either they reply to you or you
>>> >>> will face the same error). If you don't face the same error then we
>>> >>> could try figuring out what is different in our setups?
>>> >>>
>>> >>> Best,
>>> >>> Peter
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Sat, Feb 19, 2022 at 6:29 PM Eric Broch < ebr...@whitehorsetc.com> 
>>> >>> wrote:
>>>  Looking through the function tls_init() in the code for qmail-remote.c
>>> 
>>>  I don't see much that it could be, they're almost identical between
>>>  2.2.1 and 3.3.5
>>> 
>>>  Will continue looking...
>>> 
>>>  On 2/18/2022 1:54 PM, Andreas Galatis wrote:
>>> > Hi Finn,
>>> >
>>> >
>>> > I have tested with the tlsserverciphers of my older server, completed
>>> > with some of the ciphers from the new file and my mails came through.
>>> >
>>> >
>>> > Thanks a lot for your tip, Finn, I didn't find it in the code
>>> >
>>> >
>>> > Andreas
>>> >
>>> >
>>> > Am 18.02.22 um 16:56 schrieb Qmail:
>>> >> Hi Andreas.
>>> >>
>>> >> In qmail You're properly using /var/qmail/control/tlsclientciphers
>>> >> (that are a link to tlcserverciphers)
>>> >>
>>> >> According to what I read at the Nginx forum, the problem there is
>>> >> because some of the included ciphers are with underscore '_' and not
>>> >> hyphen '-' - I don't know if changing that in the tlsservercipher
>>> >> file will solve the problem.
>>> >>
>>> >>
>>> >> /Finn
>>> >>
>>> >> Den 18-02-2022 kl. 16:29 skrev Andr

Re: [qmailtoaster] TLS connection failed: ciphersuite wrong

[Eric Broch]

If I remember correctly it had something to do with Dovecot

On Feb 23, 2022, 2:25 AM, at 2:25 AM, Peter Peltonen  
wrote:
>Hello,
>
>Okay I now tested::
>
>With LEGACY (which I had earlier) I get the
>SSL_routines:set_client_ciphesuite:wrong_cipher_returned error in
>qmail/send log:
>
>But with DEFAULT I get Remote_host_said:_250_2.0.0_OK_accept as the
>result
>
>And I did the test without rebooting nor restarting qmail.
>
>So apparently this command did the trick like Eric suggested:
>
>update-crypto-policies --set DEFAULT
>
>Now I wonder if this has some other consequences, what legacy stuff is
>now
>incompatible...?
>
>Best,
>Peter
>
>
>ma 21. helmik. 2022 klo 17.55 Eric Broch 
>kirjoitti:
>
>> reboot
>>
>> On 2/21/2022 8:30 AM, Peter Peltonen wrote:
>> > Thanks Eric for the update. Here is what I see:
>> >
>> > [root@mail ~]# update-crypto-policies --show
>> > LEGACY
>> > [root@mail ~]# update-crypto-policies --set DEFAULT
>> > Setting system policy to DEFAULT
>> > Note: System-wide crypto policies are applied on application
>start-up.
>> > It is recommended to restart the system for the change of policies
>> > to fully take place.
>> >
>> > Is restarting qmail enough or should I even reboot?
>> >
>> > And is there some difference between DEFAULT and FUTURE or are they
>the
>> same?
>> >
>> > Best,
>> > Peter
>> >
>> > On Mon, Feb 21, 2022 at 4:39 PM Eric Broch
>
>> wrote:
>> >> Upon further reflection, at the end of the qt/cos8 install script
>there
>> >> is a command, 'update-crypto-policies --set LEGACY' intended for
>old
>> >> email clients I don't wonder if this change between cos7 and cos8
>might
>> >> caused the problem. Have a look here:
>> >>
>> >>
>https://www.redhat.com/en/blog/how-customize-crypto-policies-rhel-82
>> >>
>> >> If you've change it to 'update-crypto-policies --set DEFAULT' or
>> >> 'update-crypto-policies --set FUTURE' and are still having issue
>ask
>> >> hornet security if we can see the actual smtp transaction.
>> >>
>> >> In my earlier email I was saying that there was not much
>difference
>> >> between the old code and the new code for remote delivery and it
>was not
>> >> immediately obvious why we would be having a problem.
>> >>
>> >> Eric
>> >>
>> >>
>> >> On 2/21/2022 7:17 AM, Peter Peltonen wrote:
>> >>> Hi,
>> >>>
>> >>> Is there something I can test? I didn't quite understand from
>Eric's
>> >>> earlier msg what I should try...
>> >>>
>> >>> One email address producing this error for me is
>> >>> supp...@hornetsecurity.com -> If you like Eric, you could try
>emailing
>> >>> themselves asking for more details (either they reply to you or
>you
>> >>> will face the same error). If you don't face the same error then
>we
>> >>> could try figuring out what is different in our setups?
>> >>>
>> >>> Best,
>> >>> Peter
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On Sat, Feb 19, 2022 at 6:29 PM Eric Broch
>
>> wrote:
>>  Looking through the function tls_init() in the code for
>qmail-remote.c
>> 
>>  I don't see much that it could be, they're almost identical
>between
>>  2.2.1 and 3.3.5
>> 
>>  Will continue looking...
>> 
>>  On 2/18/2022 1:54 PM, Andreas Galatis wrote:
>> > Hi Finn,
>> >
>> >
>> > I have tested with the tlsserverciphers of my older server,
>completed
>> > with some of the ciphers from the new file and my mails came
>through.
>> >
>> >
>> > Thanks a lot for your tip, Finn, I didn't find it in the code
>> >
>> >
>> > Andreas
>> >
>> >
>> > Am 18.02.22 um 16:56 schrieb Qmail:
>> >> Hi Andreas.
>> >>
>> >> In qmail You're properly using
>/var/qmail/control/tlsclientciphers
>> >> (that are a link to tlcserverciphers)
>> >>
>> >> According to what I read at the Nginx forum, the problem there
>is
>> >> because some of the included ciphers are with underscore '_'
>and not
>> >> hyphen '-' - I don't know if changing that in the
>tlsservercipher
>> >> file will solve the problem.
>> >>
>> >>
>> >> /Finn
>> >>
>> >> Den 18-02-2022 kl. 16:29 skrev Andreas:
>> >>> I cannot find any file where those ciphers could be adjust.
>> >>> Is that compiled in?
>> >>>
>> >>> Me too, I have clients not beeing reachable with the new
>server
>> >>> (qmail-1.03-3.3.5), but my old server running
>qmail-1.03.2.2.1.qt.
>> >>> Did anyone find a solution?
>> >>>
>> >>> Andreas
>> >>>
>> >>> Am 17.02.22 um 20:28 schrieb Qmail:
>>  Hi.
>> 
>>  Not sure it is related, but I just read in the Nginx forum
>that
>>  some have issues (failed (SSL: error:0AB9:SSL
>routines::no
>>  cipher match)) using Mozillas 'modern' 5.5 ciphers,  but
>> everything
>>  works with Mozillas 'modern' ciphers 4.0.
>>  (found testing the Nginx config)
>> 
>>  The 5.5 list contains :
>> 
>> 
>>
>ssl_ciphers'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:T

Re: [qmailtoaster] TLS connection failed: ciphersuite wrong

[Peter Peltonen]

I've been now monitoring my qmail/send log and there has been now two
instances of a new error:

TLS_connect_failed:_error:1425F102:SSL_routines:ssl_choose_client_version:unsupported_protocol

The other one was my own very old qmail box that can do only
TLSv1.0/TLSv1.1. So apparently the new setting will break
compatibility with the older servers, but I guess that is the expected
behaviour with the DEFAULT setting.

For now I will just monitor the send log and if I see problematic
behaviour I will just add the hostnames to
/var/qmail/control/notlshosts/

Best,
Peter

On Wed, Feb 23, 2022 at 11:25 AM Peter Peltonen
 wrote:
>
> Hello,
>
> Okay I now tested::
>
> With LEGACY (which I had earlier) I get the
> SSL_routines:set_client_ciphesuite:wrong_cipher_returned error in qmail/send 
> log:
>
> But with DEFAULT I get Remote_host_said:_250_2.0.0_OK_accept as the result
>
> And I did the test without rebooting nor restarting qmail.
>
> So apparently this command did the trick like Eric suggested:
>
> update-crypto-policies --set DEFAULT
>
> Now I wonder if this has some other consequences, what legacy stuff is now 
> incompatible...?
>
> Best,
> Peter
>
>
> ma 21. helmik. 2022 klo 17.55 Eric Broch  kirjoitti:
>>
>> reboot
>>
>> On 2/21/2022 8:30 AM, Peter Peltonen wrote:
>> > Thanks Eric for the update. Here is what I see:
>> >
>> > [root@mail ~]# update-crypto-policies --show
>> > LEGACY
>> > [root@mail ~]# update-crypto-policies --set DEFAULT
>> > Setting system policy to DEFAULT
>> > Note: System-wide crypto policies are applied on application start-up.
>> > It is recommended to restart the system for the change of policies
>> > to fully take place.
>> >
>> > Is restarting qmail enough or should I even reboot?
>> >
>> > And is there some difference between DEFAULT and FUTURE or are they the 
>> > same?
>> >
>> > Best,
>> > Peter
>> >
>> > On Mon, Feb 21, 2022 at 4:39 PM Eric Broch  wrote:
>> >> Upon further reflection, at the end of the qt/cos8 install script there
>> >> is a command, 'update-crypto-policies --set LEGACY' intended for old
>> >> email clients I don't wonder if this change between cos7 and cos8 might
>> >> caused the problem. Have a look here:
>> >>
>> >> https://www.redhat.com/en/blog/how-customize-crypto-policies-rhel-82
>> >>
>> >> If you've change it to 'update-crypto-policies --set DEFAULT' or
>> >> 'update-crypto-policies --set FUTURE' and are still having issue ask
>> >> hornet security if we can see the actual smtp transaction.
>> >>
>> >> In my earlier email I was saying that there was not much difference
>> >> between the old code and the new code for remote delivery and it was not
>> >> immediately obvious why we would be having a problem.
>> >>
>> >> Eric
>> >>
>> >>
>> >> On 2/21/2022 7:17 AM, Peter Peltonen wrote:
>> >>> Hi,
>> >>>
>> >>> Is there something I can test? I didn't quite understand from Eric's
>> >>> earlier msg what I should try...
>> >>>
>> >>> One email address producing this error for me is
>> >>> supp...@hornetsecurity.com -> If you like Eric, you could try emailing
>> >>> themselves asking for more details (either they reply to you or you
>> >>> will face the same error). If you don't face the same error then we
>> >>> could try figuring out what is different in our setups?
>> >>>
>> >>> Best,
>> >>> Peter
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On Sat, Feb 19, 2022 at 6:29 PM Eric Broch  
>> >>> wrote:
>>  Looking through the function tls_init() in the code for qmail-remote.c
>> 
>>  I don't see much that it could be, they're almost identical between
>>  2.2.1 and 3.3.5
>> 
>>  Will continue looking...
>> 
>>  On 2/18/2022 1:54 PM, Andreas Galatis wrote:
>> > Hi Finn,
>> >
>> >
>> > I have tested with the tlsserverciphers of my older server, completed
>> > with some of the ciphers from the new file and my mails came through.
>> >
>> >
>> > Thanks a lot for your tip, Finn, I didn't find it in the code
>> >
>> >
>> > Andreas
>> >
>> >
>> > Am 18.02.22 um 16:56 schrieb Qmail:
>> >> Hi Andreas.
>> >>
>> >> In qmail You're properly using /var/qmail/control/tlsclientciphers
>> >> (that are a link to tlcserverciphers)
>> >>
>> >> According to what I read at the Nginx forum, the problem there is
>> >> because some of the included ciphers are with underscore '_' and not
>> >> hyphen '-' - I don't know if changing that in the tlsservercipher
>> >> file will solve the problem.
>> >>
>> >>
>> >> /Finn
>> >>
>> >> Den 18-02-2022 kl. 16:29 skrev Andreas:
>> >>> I cannot find any file where those ciphers could be adjust.
>> >>> Is that compiled in?
>> >>>
>> >>> Me too, I have clients not beeing reachable with the new server
>> >>> (qmail-1.03-3.3.5), but my old server running qmail-1.03.2.2.1.qt.
>> >>> Did anyone find a solution?
>> >>>
>> >>> Andreas
>> >>>
>> >>> Am 17.02.22 um 20:28 schrieb Qm

Re: [qmailtoaster] TLS connection failed: ciphersuite wrong

[Peter Peltonen]

Hello,

Okay I now tested::

With LEGACY (which I had earlier) I get the
SSL_routines:set_client_ciphesuite:wrong_cipher_returned error in
qmail/send log:

But with DEFAULT I get Remote_host_said:_250_2.0.0_OK_accept as the result

And I did the test without rebooting nor restarting qmail.

So apparently this command did the trick like Eric suggested:

update-crypto-policies --set DEFAULT

Now I wonder if this has some other consequences, what legacy stuff is now
incompatible...?

Best,
Peter


ma 21. helmik. 2022 klo 17.55 Eric Broch 
kirjoitti:

> reboot
>
> On 2/21/2022 8:30 AM, Peter Peltonen wrote:
> > Thanks Eric for the update. Here is what I see:
> >
> > [root@mail ~]# update-crypto-policies --show
> > LEGACY
> > [root@mail ~]# update-crypto-policies --set DEFAULT
> > Setting system policy to DEFAULT
> > Note: System-wide crypto policies are applied on application start-up.
> > It is recommended to restart the system for the change of policies
> > to fully take place.
> >
> > Is restarting qmail enough or should I even reboot?
> >
> > And is there some difference between DEFAULT and FUTURE or are they the
> same?
> >
> > Best,
> > Peter
> >
> > On Mon, Feb 21, 2022 at 4:39 PM Eric Broch 
> wrote:
> >> Upon further reflection, at the end of the qt/cos8 install script there
> >> is a command, 'update-crypto-policies --set LEGACY' intended for old
> >> email clients I don't wonder if this change between cos7 and cos8 might
> >> caused the problem. Have a look here:
> >>
> >> https://www.redhat.com/en/blog/how-customize-crypto-policies-rhel-82
> >>
> >> If you've change it to 'update-crypto-policies --set DEFAULT' or
> >> 'update-crypto-policies --set FUTURE' and are still having issue ask
> >> hornet security if we can see the actual smtp transaction.
> >>
> >> In my earlier email I was saying that there was not much difference
> >> between the old code and the new code for remote delivery and it was not
> >> immediately obvious why we would be having a problem.
> >>
> >> Eric
> >>
> >>
> >> On 2/21/2022 7:17 AM, Peter Peltonen wrote:
> >>> Hi,
> >>>
> >>> Is there something I can test? I didn't quite understand from Eric's
> >>> earlier msg what I should try...
> >>>
> >>> One email address producing this error for me is
> >>> supp...@hornetsecurity.com -> If you like Eric, you could try emailing
> >>> themselves asking for more details (either they reply to you or you
> >>> will face the same error). If you don't face the same error then we
> >>> could try figuring out what is different in our setups?
> >>>
> >>> Best,
> >>> Peter
> >>>
> >>>
> >>>
> >>>
> >>> On Sat, Feb 19, 2022 at 6:29 PM Eric Broch 
> wrote:
>  Looking through the function tls_init() in the code for qmail-remote.c
> 
>  I don't see much that it could be, they're almost identical between
>  2.2.1 and 3.3.5
> 
>  Will continue looking...
> 
>  On 2/18/2022 1:54 PM, Andreas Galatis wrote:
> > Hi Finn,
> >
> >
> > I have tested with the tlsserverciphers of my older server, completed
> > with some of the ciphers from the new file and my mails came through.
> >
> >
> > Thanks a lot for your tip, Finn, I didn't find it in the code
> >
> >
> > Andreas
> >
> >
> > Am 18.02.22 um 16:56 schrieb Qmail:
> >> Hi Andreas.
> >>
> >> In qmail You're properly using /var/qmail/control/tlsclientciphers
> >> (that are a link to tlcserverciphers)
> >>
> >> According to what I read at the Nginx forum, the problem there is
> >> because some of the included ciphers are with underscore '_' and not
> >> hyphen '-' - I don't know if changing that in the tlsservercipher
> >> file will solve the problem.
> >>
> >>
> >> /Finn
> >>
> >> Den 18-02-2022 kl. 16:29 skrev Andreas:
> >>> I cannot find any file where those ciphers could be adjust.
> >>> Is that compiled in?
> >>>
> >>> Me too, I have clients not beeing reachable with the new server
> >>> (qmail-1.03-3.3.5), but my old server running qmail-1.03.2.2.1.qt.
> >>> Did anyone find a solution?
> >>>
> >>> Andreas
> >>>
> >>> Am 17.02.22 um 20:28 schrieb Qmail:
>  Hi.
> 
>  Not sure it is related, but I just read in the Nginx forum that
>  some have issues (failed (SSL: error:0AB9:SSL routines::no
>  cipher match)) using Mozillas 'modern' 5.5 ciphers,  but
> everything
>  works with Mozillas 'modern' ciphers 4.0.
>  (found testing the Nginx config)
> 
>  The 5.5 list contains :
> 
> 
> ssl_ciphers'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256';
> 
> 
>  The 4.0 list contains:
> 
> 
> ssl_ciphers'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECD

Re: [qmailtoaster] TLS connection failed: ciphersuite wrong

[Eric Broch]

reboot

On 2/21/2022 8:30 AM, Peter Peltonen wrote:

Thanks Eric for the update. Here is what I see:

[root@mail ~]# update-crypto-policies --show
LEGACY
[root@mail ~]# update-crypto-policies --set DEFAULT
Setting system policy to DEFAULT
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.

Is restarting qmail enough or should I even reboot?

And is there some difference between DEFAULT and FUTURE or are they the same?

Best,
Peter

On Mon, Feb 21, 2022 at 4:39 PM Eric Broch  wrote:

Upon further reflection, at the end of the qt/cos8 install script there
is a command, 'update-crypto-policies --set LEGACY' intended for old
email clients I don't wonder if this change between cos7 and cos8 might
caused the problem. Have a look here:

https://www.redhat.com/en/blog/how-customize-crypto-policies-rhel-82

If you've change it to 'update-crypto-policies --set DEFAULT' or
'update-crypto-policies --set FUTURE' and are still having issue ask
hornet security if we can see the actual smtp transaction.

In my earlier email I was saying that there was not much difference
between the old code and the new code for remote delivery and it was not
immediately obvious why we would be having a problem.

Eric


On 2/21/2022 7:17 AM, Peter Peltonen wrote:

Hi,

Is there something I can test? I didn't quite understand from Eric's
earlier msg what I should try...

One email address producing this error for me is
supp...@hornetsecurity.com -> If you like Eric, you could try emailing
themselves asking for more details (either they reply to you or you
will face the same error). If you don't face the same error then we
could try figuring out what is different in our setups?

Best,
Peter




On Sat, Feb 19, 2022 at 6:29 PM Eric Broch  wrote:

Looking through the function tls_init() in the code for qmail-remote.c

I don't see much that it could be, they're almost identical between
2.2.1 and 3.3.5

Will continue looking...

On 2/18/2022 1:54 PM, Andreas Galatis wrote:

Hi Finn,


I have tested with the tlsserverciphers of my older server, completed
with some of the ciphers from the new file and my mails came through.


Thanks a lot for your tip, Finn, I didn't find it in the code


Andreas


Am 18.02.22 um 16:56 schrieb Qmail:

Hi Andreas.

In qmail You're properly using /var/qmail/control/tlsclientciphers
(that are a link to tlcserverciphers)

According to what I read at the Nginx forum, the problem there is
because some of the included ciphers are with underscore '_' and not
hyphen '-' - I don't know if changing that in the tlsservercipher
file will solve the problem.


/Finn

Den 18-02-2022 kl. 16:29 skrev Andreas:

I cannot find any file where those ciphers could be adjust.
Is that compiled in?

Me too, I have clients not beeing reachable with the new server
(qmail-1.03-3.3.5), but my old server running qmail-1.03.2.2.1.qt.
Did anyone find a solution?

Andreas

Am 17.02.22 um 20:28 schrieb Qmail:

Hi.

Not sure it is related, but I just read in the Nginx forum that
some have issues (failed (SSL: error:0AB9:SSL routines::no
cipher match)) using Mozillas 'modern' 5.5 ciphers,  but everything
works with Mozillas 'modern' ciphers 4.0.
(found testing the Nginx config)

The 5.5 list contains :

ssl_ciphers'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256';


The 4.0 list contains:

ssl_ciphers'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';



These are matched against the openssl ciphers that are located on
the server but are more or less same as the tlsclientciphers used
in qmail.

Nginx can be setup as a MAIL proxy and therefore may be the reason
for Your issue ??

or maybe it's just a coincidence ?

Regards,
Finn



Den 17-02-2022 kl. 08:14 skrev Andreas:

Hi list,
I have the same failure-mails with some servers, my version of
qmail is
qmail-1.03-3.3.5.qt.md.el8.x86_64

TLS connect failed: error:1421C105:SSL
routines:set_client_ciphersuite:wrong
cipher returnedZConnected to 83.246.65.85 but connection died.

With my old server (qmail-1.03-2.2.1.qt.el7.x86_64) I can send
emails to the same recipients.
Andreas

Am 15.02.22 um 09:39 schrieb Peter Peltonen:

What I have installed is qmail-1.03-3.3.1.qt.md.el8.x86_64

Any reason to update?

Best,
Peter

On Sun, Feb 13, 2022 at 5:15 PM Eric Broch
 wrote:

What version of qmail ?

On 2/12/2022 12:56 PM, Peter Peltonen wrote:

Finally got an answer from them (see list below). I see some
matching
siphers on their and on my own list. Any idea how I could debug
this
more so I can find out why mail is not being delivered to their
server?

best,
Peter

"
OPTON
All ciphers

DESCRIPTION
TLS encryption is only possible with ciphers that are
co

Re: [qmailtoaster] TLS connection failed: ciphersuite wrong

[Peter Peltonen]

Thanks Eric for the update. Here is what I see:

[root@mail ~]# update-crypto-policies --show
LEGACY
[root@mail ~]# update-crypto-policies --set DEFAULT
Setting system policy to DEFAULT
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.

Is restarting qmail enough or should I even reboot?

And is there some difference between DEFAULT and FUTURE or are they the same?

Best,
Peter

On Mon, Feb 21, 2022 at 4:39 PM Eric Broch  wrote:
>
> Upon further reflection, at the end of the qt/cos8 install script there
> is a command, 'update-crypto-policies --set LEGACY' intended for old
> email clients I don't wonder if this change between cos7 and cos8 might
> caused the problem. Have a look here:
>
> https://www.redhat.com/en/blog/how-customize-crypto-policies-rhel-82
>
> If you've change it to 'update-crypto-policies --set DEFAULT' or
> 'update-crypto-policies --set FUTURE' and are still having issue ask
> hornet security if we can see the actual smtp transaction.
>
> In my earlier email I was saying that there was not much difference
> between the old code and the new code for remote delivery and it was not
> immediately obvious why we would be having a problem.
>
> Eric
>
>
> On 2/21/2022 7:17 AM, Peter Peltonen wrote:
> > Hi,
> >
> > Is there something I can test? I didn't quite understand from Eric's
> > earlier msg what I should try...
> >
> > One email address producing this error for me is
> > supp...@hornetsecurity.com -> If you like Eric, you could try emailing
> > themselves asking for more details (either they reply to you or you
> > will face the same error). If you don't face the same error then we
> > could try figuring out what is different in our setups?
> >
> > Best,
> > Peter
> >
> >
> >
> >
> > On Sat, Feb 19, 2022 at 6:29 PM Eric Broch  wrote:
> >> Looking through the function tls_init() in the code for qmail-remote.c
> >>
> >> I don't see much that it could be, they're almost identical between
> >> 2.2.1 and 3.3.5
> >>
> >> Will continue looking...
> >>
> >> On 2/18/2022 1:54 PM, Andreas Galatis wrote:
> >>> Hi Finn,
> >>>
> >>>
> >>> I have tested with the tlsserverciphers of my older server, completed
> >>> with some of the ciphers from the new file and my mails came through.
> >>>
> >>>
> >>> Thanks a lot for your tip, Finn, I didn't find it in the code
> >>>
> >>>
> >>> Andreas
> >>>
> >>>
> >>> Am 18.02.22 um 16:56 schrieb Qmail:
>  Hi Andreas.
> 
>  In qmail You're properly using /var/qmail/control/tlsclientciphers
>  (that are a link to tlcserverciphers)
> 
>  According to what I read at the Nginx forum, the problem there is
>  because some of the included ciphers are with underscore '_' and not
>  hyphen '-' - I don't know if changing that in the tlsservercipher
>  file will solve the problem.
> 
> 
>  /Finn
> 
>  Den 18-02-2022 kl. 16:29 skrev Andreas:
> > I cannot find any file where those ciphers could be adjust.
> > Is that compiled in?
> >
> > Me too, I have clients not beeing reachable with the new server
> > (qmail-1.03-3.3.5), but my old server running qmail-1.03.2.2.1.qt.
> > Did anyone find a solution?
> >
> > Andreas
> >
> > Am 17.02.22 um 20:28 schrieb Qmail:
> >> Hi.
> >>
> >> Not sure it is related, but I just read in the Nginx forum that
> >> some have issues (failed (SSL: error:0AB9:SSL routines::no
> >> cipher match)) using Mozillas 'modern' 5.5 ciphers,  but everything
> >> works with Mozillas 'modern' ciphers 4.0.
> >> (found testing the Nginx config)
> >>
> >> The 5.5 list contains :
> >>
> >> ssl_ciphers'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256';
> >>
> >>
> >> The 4.0 list contains:
> >>
> >> ssl_ciphers'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
> >>
> >>
> >>
> >> These are matched against the openssl ciphers that are located on
> >> the server but are more or less same as the tlsclientciphers used
> >> in qmail.
> >>
> >> Nginx can be setup as a MAIL proxy and therefore may be the reason
> >> for Your issue ??
> >>
> >> or maybe it's just a coincidence ?
> >>
> >> Regards,
> >> Finn
> >>
> >>
> >>
> >> Den 17-02-2022 kl. 08:14 skrev Andreas:
> >>> Hi list,
> >>> I have the same failure-mails with some servers, my version of
> >>> qmail is
> >>> qmail-1.03-3.3.5.qt.md.el8.x86_64
> >>>
> >>> TLS connect failed: error:1421C105:SSL
> >>> routines:set_client_ciphersuite:wrong
> >>> cipher returnedZConnected to 83.246.65.85 but connection

Re: [qmailtoaster] TLS connection failed: ciphersuite wrong

[Eric Broch]

Upon further reflection, at the end of the qt/cos8 install script there 
is a command, 'update-crypto-policies --set LEGACY' intended for old 
email clients I don't wonder if this change between cos7 and cos8 might 
caused the problem. Have a look here:


https://www.redhat.com/en/blog/how-customize-crypto-policies-rhel-82

If you've change it to 'update-crypto-policies --set DEFAULT' or 
'update-crypto-policies --set FUTURE' and are still having issue ask 
hornet security if we can see the actual smtp transaction.


In my earlier email I was saying that there was not much difference 
between the old code and the new code for remote delivery and it was not 
immediately obvious why we would be having a problem.


Eric


On 2/21/2022 7:17 AM, Peter Peltonen wrote:

Hi,

Is there something I can test? I didn't quite understand from Eric's
earlier msg what I should try...

One email address producing this error for me is
supp...@hornetsecurity.com -> If you like Eric, you could try emailing
themselves asking for more details (either they reply to you or you
will face the same error). If you don't face the same error then we
could try figuring out what is different in our setups?

Best,
Peter




On Sat, Feb 19, 2022 at 6:29 PM Eric Broch  wrote:

Looking through the function tls_init() in the code for qmail-remote.c

I don't see much that it could be, they're almost identical between
2.2.1 and 3.3.5

Will continue looking...

On 2/18/2022 1:54 PM, Andreas Galatis wrote:

Hi Finn,


I have tested with the tlsserverciphers of my older server, completed
with some of the ciphers from the new file and my mails came through.


Thanks a lot for your tip, Finn, I didn't find it in the code


Andreas


Am 18.02.22 um 16:56 schrieb Qmail:

Hi Andreas.

In qmail You're properly using /var/qmail/control/tlsclientciphers
(that are a link to tlcserverciphers)

According to what I read at the Nginx forum, the problem there is
because some of the included ciphers are with underscore '_' and not
hyphen '-' - I don't know if changing that in the tlsservercipher
file will solve the problem.


/Finn

Den 18-02-2022 kl. 16:29 skrev Andreas:

I cannot find any file where those ciphers could be adjust.
Is that compiled in?

Me too, I have clients not beeing reachable with the new server
(qmail-1.03-3.3.5), but my old server running qmail-1.03.2.2.1.qt.
Did anyone find a solution?

Andreas

Am 17.02.22 um 20:28 schrieb Qmail:

Hi.

Not sure it is related, but I just read in the Nginx forum that
some have issues (failed (SSL: error:0AB9:SSL routines::no
cipher match)) using Mozillas 'modern' 5.5 ciphers,  but everything
works with Mozillas 'modern' ciphers 4.0.
(found testing the Nginx config)

The 5.5 list contains :

ssl_ciphers'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256';


The 4.0 list contains:

ssl_ciphers'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';



These are matched against the openssl ciphers that are located on
the server but are more or less same as the tlsclientciphers used
in qmail.

Nginx can be setup as a MAIL proxy and therefore may be the reason
for Your issue ??

or maybe it's just a coincidence ?

Regards,
Finn



Den 17-02-2022 kl. 08:14 skrev Andreas:

Hi list,
I have the same failure-mails with some servers, my version of
qmail is
qmail-1.03-3.3.5.qt.md.el8.x86_64

TLS connect failed: error:1421C105:SSL
routines:set_client_ciphersuite:wrong
cipher returnedZConnected to 83.246.65.85 but connection died.

With my old server (qmail-1.03-2.2.1.qt.el7.x86_64) I can send
emails to the same recipients.
Andreas

Am 15.02.22 um 09:39 schrieb Peter Peltonen:

What I have installed is qmail-1.03-3.3.1.qt.md.el8.x86_64

Any reason to update?

Best,
Peter

On Sun, Feb 13, 2022 at 5:15 PM Eric Broch
 wrote:

What version of qmail ?

On 2/12/2022 12:56 PM, Peter Peltonen wrote:

Finally got an answer from them (see list below). I see some
matching
siphers on their and on my own list. Any idea how I could debug
this
more so I can find out why mail is not being delivered to their
server?

best,
Peter

"
OPTON
All ciphers

DESCRIPTION
TLS encryption is only possible with ciphers that are
considered as
secure by the German Federal Office for Information Security. A
TLS
connection is only established if the email server of the
communication partner supports one of the following ciphers:

• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-RSA-AES256-SHA384
• ECDHE-RSA-AES256-SHA
• DHE-RSA-AES256-GCM-SHA384
• DHE-RSA-AES256-SHA256
• DHE-RSA-AES256-SHA
• AES256-GCM-SHA384
• AES256-SHA256
• AES256-SHA
• ECDHE-RSA-DES-CBC3-SHA
• EDH-RSA-DES-CBC3-SHA
• DES-CBC3-SHA

OPTION
Secure ciphers

DESCRIPTION
Secure ciphers TLS encryption is only possible with ciphers
that are
considered as secu

Re: [qmailtoaster] TLS connection failed: ciphersuite wrong

[Peter Peltonen]

Hi,

Is there something I can test? I didn't quite understand from Eric's
earlier msg what I should try...

One email address producing this error for me is
supp...@hornetsecurity.com -> If you like Eric, you could try emailing
themselves asking for more details (either they reply to you or you
will face the same error). If you don't face the same error then we
could try figuring out what is different in our setups?

Best,
Peter




On Sat, Feb 19, 2022 at 6:29 PM Eric Broch  wrote:
>
> Looking through the function tls_init() in the code for qmail-remote.c
>
> I don't see much that it could be, they're almost identical between
> 2.2.1 and 3.3.5
>
> Will continue looking...
>
> On 2/18/2022 1:54 PM, Andreas Galatis wrote:
> > Hi Finn,
> >
> >
> > I have tested with the tlsserverciphers of my older server, completed
> > with some of the ciphers from the new file and my mails came through.
> >
> >
> > Thanks a lot for your tip, Finn, I didn't find it in the code
> >
> >
> > Andreas
> >
> >
> > Am 18.02.22 um 16:56 schrieb Qmail:
> >> Hi Andreas.
> >>
> >> In qmail You're properly using /var/qmail/control/tlsclientciphers
> >> (that are a link to tlcserverciphers)
> >>
> >> According to what I read at the Nginx forum, the problem there is
> >> because some of the included ciphers are with underscore '_' and not
> >> hyphen '-' - I don't know if changing that in the tlsservercipher
> >> file will solve the problem.
> >>
> >>
> >> /Finn
> >>
> >> Den 18-02-2022 kl. 16:29 skrev Andreas:
> >>> I cannot find any file where those ciphers could be adjust.
> >>> Is that compiled in?
> >>>
> >>> Me too, I have clients not beeing reachable with the new server
> >>> (qmail-1.03-3.3.5), but my old server running qmail-1.03.2.2.1.qt.
> >>> Did anyone find a solution?
> >>>
> >>> Andreas
> >>>
> >>> Am 17.02.22 um 20:28 schrieb Qmail:
>  Hi.
> 
>  Not sure it is related, but I just read in the Nginx forum that
>  some have issues (failed (SSL: error:0AB9:SSL routines::no
>  cipher match)) using Mozillas 'modern' 5.5 ciphers,  but everything
>  works with Mozillas 'modern' ciphers 4.0.
>  (found testing the Nginx config)
> 
>  The 5.5 list contains :
> 
>  ssl_ciphers'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256';
> 
> 
>  The 4.0 list contains:
> 
>  ssl_ciphers'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
> 
> 
> 
>  These are matched against the openssl ciphers that are located on
>  the server but are more or less same as the tlsclientciphers used
>  in qmail.
> 
>  Nginx can be setup as a MAIL proxy and therefore may be the reason
>  for Your issue ??
> 
>  or maybe it's just a coincidence ?
> 
>  Regards,
>  Finn
> 
> 
> 
>  Den 17-02-2022 kl. 08:14 skrev Andreas:
> > Hi list,
> > I have the same failure-mails with some servers, my version of
> > qmail is
> > qmail-1.03-3.3.5.qt.md.el8.x86_64
> >
> > TLS connect failed: error:1421C105:SSL
> > routines:set_client_ciphersuite:wrong
> > cipher returnedZConnected to 83.246.65.85 but connection died.
> >
> > With my old server (qmail-1.03-2.2.1.qt.el7.x86_64) I can send
> > emails to the same recipients.
> > Andreas
> >
> > Am 15.02.22 um 09:39 schrieb Peter Peltonen:
> >> What I have installed is qmail-1.03-3.3.1.qt.md.el8.x86_64
> >>
> >> Any reason to update?
> >>
> >> Best,
> >> Peter
> >>
> >> On Sun, Feb 13, 2022 at 5:15 PM Eric Broch
> >>  wrote:
> >>> What version of qmail ?
> >>>
> >>> On 2/12/2022 12:56 PM, Peter Peltonen wrote:
>  Finally got an answer from them (see list below). I see some
>  matching
>  siphers on their and on my own list. Any idea how I could debug
>  this
>  more so I can find out why mail is not being delivered to their
>  server?
> 
>  best,
>  Peter
> 
>  "
>  OPTON
>  All ciphers
> 
>  DESCRIPTION
>  TLS encryption is only possible with ciphers that are
>  considered as
>  secure by the German Federal Office for Information Security. A
>  TLS
>  connection is only established if the email server of the
>  communication partner supports one of the following ciphers:
> 
>  • ECDHE-RSA-AES256-GCM-SHA384
>  • ECDHE-RSA-AES256-SHA384
>  • ECDHE-RSA-AES256-SHA
>  • DHE-RSA-AES256-GCM-SHA384
>  • DHE-RSA-AES256-SHA256
>  • DHE-RSA-AES256-SHA
>  • AES256-GCM-SHA384
>  • AES256-SHA256
>  • AES256-SHA
> >>

Re: [qmailtoaster] TLS connection failed: ciphersuite wrong

[Eric Broch]

Looking through the function tls_init() in the code for qmail-remote.c

I don't see much that it could be, they're almost identical between 
2.2.1 and 3.3.5


Will continue looking...

On 2/18/2022 1:54 PM, Andreas Galatis wrote:

Hi Finn,


I have tested with the tlsserverciphers of my older server, completed 
with some of the ciphers from the new file and my mails came through.



Thanks a lot for your tip, Finn, I didn't find it in the code


Andreas


Am 18.02.22 um 16:56 schrieb Qmail:

Hi Andreas.

In qmail You're properly using /var/qmail/control/tlsclientciphers
(that are a link to tlcserverciphers)

According to what I read at the Nginx forum, the problem there is 
because some of the included ciphers are with underscore '_' and not 
hyphen '-' - I don't know if changing that in the tlsservercipher 
file will solve the problem.



/Finn

Den 18-02-2022 kl. 16:29 skrev Andreas:

I cannot find any file where those ciphers could be adjust.
Is that compiled in?

Me too, I have clients not beeing reachable with the new server 
(qmail-1.03-3.3.5), but my old server running qmail-1.03.2.2.1.qt.

Did anyone find a solution?

Andreas

Am 17.02.22 um 20:28 schrieb Qmail:

Hi.

Not sure it is related, but I just read in the Nginx forum that 
some have issues (failed (SSL: error:0AB9:SSL routines::no 
cipher match)) using Mozillas 'modern' 5.5 ciphers,  but everything 
works with Mozillas 'modern' ciphers 4.0.

(found testing the Nginx config)

The 5.5 list contains :

ssl_ciphers'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256'; 



The 4.0 list contains:

ssl_ciphers'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256'; 




These are matched against the openssl ciphers that are located on 
the server but are more or less same as the tlsclientciphers used 
in qmail.


Nginx can be setup as a MAIL proxy and therefore may be the reason 
for Your issue ??


or maybe it's just a coincidence ?

Regards,
Finn



Den 17-02-2022 kl. 08:14 skrev Andreas:

Hi list,
I have the same failure-mails with some servers, my version of 
qmail is

qmail-1.03-3.3.5.qt.md.el8.x86_64

TLS connect failed: error:1421C105:SSL 
routines:set_client_ciphersuite:wrong

cipher returnedZConnected to 83.246.65.85 but connection died.

With my old server (qmail-1.03-2.2.1.qt.el7.x86_64) I can send 
emails to the same recipients.

Andreas

Am 15.02.22 um 09:39 schrieb Peter Peltonen:

What I have installed is qmail-1.03-3.3.1.qt.md.el8.x86_64

Any reason to update?

Best,
Peter

On Sun, Feb 13, 2022 at 5:15 PM Eric Broch 
 wrote:

What version of qmail ?

On 2/12/2022 12:56 PM, Peter Peltonen wrote:
Finally got an answer from them (see list below). I see some 
matching
siphers on their and on my own list. Any idea how I could debug 
this

more so I can find out why mail is not being delivered to their
server?

best,
Peter

"
OPTON
All ciphers

DESCRIPTION
TLS encryption is only possible with ciphers that are 
considered as
secure by the German Federal Office for Information Security. A 
TLS

connection is only established if the email server of the
communication partner supports one of the following ciphers:

• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-RSA-AES256-SHA384
• ECDHE-RSA-AES256-SHA
• DHE-RSA-AES256-GCM-SHA384
• DHE-RSA-AES256-SHA256
• DHE-RSA-AES256-SHA
• AES256-GCM-SHA384
• AES256-SHA256
• AES256-SHA
• ECDHE-RSA-DES-CBC3-SHA
• EDH-RSA-DES-CBC3-SHA
• DES-CBC3-SHA

OPTION
Secure ciphers

DESCRIPTION
Secure ciphers TLS encryption is only possible with ciphers 
that are

considered as secure by the German Federal Office for Information
Security. A TLS connection is only established if the email
server of the communication partner supports one of the 
following ciphers:


• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-RSA-AES256-SHA384
• DHE-RSA-AES256-GCM-SHA384
• DHE-RSA-AES256-SHA256
• ECDHE-RSA-AES128-GCM-SHA256
• ECDHE-RSA-AES128-SHA256
• DHE-RSA-AES128-GCM-SHA256
• DHE-RSA-AES128-SHA256
"


On Mon, Feb 7, 2022 at 4:08 PM Eric Broch 
 wrote:
Is there a way to contact them and find out what obscure B.S. 
they want?


On 2/7/2022 12:26 AM, Peter Peltonen wrote:
When trying to deliver email to a domain that is using spam 
protection

from antispameurope.com I get the following error:

deferral: 
TLS_connect_failed:_error:1421C105:SSL_routines:set_client_ciphersuite:wrong_cipher_returnedZConnected_to_83.246.65.85_but_connection_died._(#4.4.2)/ 



So am I missing something here:

[root@mail ~]# cat /var/qmail/control/tlsclientciphers
TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:ADH-SEED-SHA:SEED-SHA:IDEA-CBC-SHA:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-

Re: [qmailtoaster] TLS connection failed: ciphersuite wrong

[Andreas Galatis]

Hi Finn,


I have tested with the tlsserverciphers of my older server, completed 
with some of the ciphers from the new file and my mails came through.



Thanks a lot for your tip, Finn, I didn't find it in the code


Andreas


Am 18.02.22 um 16:56 schrieb Qmail:

Hi Andreas.

In qmail You're properly using /var/qmail/control/tlsclientciphers
(that are a link to tlcserverciphers)

According to what I read at the Nginx forum, the problem there is 
because some of the included ciphers are with underscore '_' and not 
hyphen '-' - I don't know if changing that in the tlsservercipher file 
will solve the problem.



/Finn

Den 18-02-2022 kl. 16:29 skrev Andreas:

I cannot find any file where those ciphers could be adjust.
Is that compiled in?

Me too, I have clients not beeing reachable with the new server 
(qmail-1.03-3.3.5), but my old server running qmail-1.03.2.2.1.qt.

Did anyone find a solution?

Andreas

Am 17.02.22 um 20:28 schrieb Qmail:

Hi.

Not sure it is related, but I just read in the Nginx forum that some 
have issues (failed (SSL: error:0AB9:SSL routines::no cipher 
match)) using Mozillas 'modern' 5.5 ciphers,  but everything works 
with Mozillas 'modern' ciphers 4.0.

(found testing the Nginx config)

The 5.5 list contains :

ssl_ciphers'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256'; 



The 4.0 list contains:

ssl_ciphers'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256'; 




These are matched against the openssl ciphers that are located on 
the server but are more or less same as the tlsclientciphers used in 
qmail.


Nginx can be setup as a MAIL proxy and therefore may be the reason 
for Your issue ??


or maybe it's just a coincidence ?

Regards,
Finn



Den 17-02-2022 kl. 08:14 skrev Andreas:

Hi list,
I have the same failure-mails with some servers, my version of 
qmail is

qmail-1.03-3.3.5.qt.md.el8.x86_64

TLS connect failed: error:1421C105:SSL 
routines:set_client_ciphersuite:wrong

cipher returnedZConnected to 83.246.65.85 but connection died.

With my old server (qmail-1.03-2.2.1.qt.el7.x86_64) I can send 
emails to the same recipients.

Andreas

Am 15.02.22 um 09:39 schrieb Peter Peltonen:

What I have installed is qmail-1.03-3.3.1.qt.md.el8.x86_64

Any reason to update?

Best,
Peter

On Sun, Feb 13, 2022 at 5:15 PM Eric Broch 
 wrote:

What version of qmail ?

On 2/12/2022 12:56 PM, Peter Peltonen wrote:
Finally got an answer from them (see list below). I see some 
matching
siphers on their and on my own list. Any idea how I could debug 
this

more so I can find out why mail is not being delivered to their
server?

best,
Peter

"
OPTON
All ciphers

DESCRIPTION
TLS encryption is only possible with ciphers that are considered as
secure by the German Federal Office for Information Security. A TLS
connection is only established if the email server of the
communication partner supports one of the following ciphers:

• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-RSA-AES256-SHA384
• ECDHE-RSA-AES256-SHA
• DHE-RSA-AES256-GCM-SHA384
• DHE-RSA-AES256-SHA256
• DHE-RSA-AES256-SHA
• AES256-GCM-SHA384
• AES256-SHA256
• AES256-SHA
• ECDHE-RSA-DES-CBC3-SHA
• EDH-RSA-DES-CBC3-SHA
• DES-CBC3-SHA

OPTION
Secure ciphers

DESCRIPTION
Secure ciphers TLS encryption is only possible with ciphers that 
are

considered as secure by the German Federal Office for Information
Security. A TLS connection is only established if the email
server of the communication partner supports one of the 
following ciphers:


• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-RSA-AES256-SHA384
• DHE-RSA-AES256-GCM-SHA384
• DHE-RSA-AES256-SHA256
• ECDHE-RSA-AES128-GCM-SHA256
• ECDHE-RSA-AES128-SHA256
• DHE-RSA-AES128-GCM-SHA256
• DHE-RSA-AES128-SHA256
"


On Mon, Feb 7, 2022 at 4:08 PM Eric Broch 
 wrote:
Is there a way to contact them and find out what obscure B.S. 
they want?


On 2/7/2022 12:26 AM, Peter Peltonen wrote:
When trying to deliver email to a domain that is using spam 
protection

from antispameurope.com I get the following error:

deferral: 
TLS_connect_failed:_error:1421C105:SSL_routines:set_client_ciphersuite:wrong_cipher_returnedZConnected_to_83.246.65.85_but_connection_died._(#4.4.2)/ 



So am I missing something here:

[root@mail ~]# cat /var/qmail/control/tlsclientciphers
TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:ADH-SEED-SHA:SEED-SHA:IDEA-CBC-SHA:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-CCM8:ECDHE-ECDSA-AES256-CCM:DHE-RSA-AES256-CCM8:DHE-RSA-AES256-CCM:ECDHE-ECDSA-ARIA256-GCM-SHA384:ECDHE-ARIA256-GCM-SHA384:D

Re: [qmailtoaster] TLS connection failed: ciphersuite wrong

[Andreas]

Hi list,
I have the same failure-mails with some servers, my version of qmail is
qmail-1.03-3.3.5.qt.md.el8.x86_64

TLS connect failed: error:1421C105:SSL routines:set_client_ciphersuite:wrong
cipher returnedZConnected to 83.246.65.85 but connection died.

With my old server (qmail-1.03-2.2.1.qt.el7.x86_64) I can send emails to 
the same recipients.

Andreas

Am 15.02.22 um 09:39 schrieb Peter Peltonen:

What I have installed is qmail-1.03-3.3.1.qt.md.el8.x86_64

Any reason to update?

Best,
Peter

On Sun, Feb 13, 2022 at 5:15 PM Eric Broch  wrote:

What version of qmail ?

On 2/12/2022 12:56 PM, Peter Peltonen wrote:

Finally got an answer from them (see list below). I see some matching
siphers on their and on my own list. Any idea how I could debug this
more so I can find out why mail is not being delivered to their
server?

best,
Peter

"
OPTON
All ciphers

DESCRIPTION
TLS encryption is only possible with ciphers that are considered as
secure by the German Federal Office for Information Security. A TLS
connection is only established if the email server of the
communication partner supports one of the following ciphers:

• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-RSA-AES256-SHA384
• ECDHE-RSA-AES256-SHA
• DHE-RSA-AES256-GCM-SHA384
• DHE-RSA-AES256-SHA256
• DHE-RSA-AES256-SHA
• AES256-GCM-SHA384
• AES256-SHA256
• AES256-SHA
• ECDHE-RSA-DES-CBC3-SHA
• EDH-RSA-DES-CBC3-SHA
• DES-CBC3-SHA

OPTION
Secure ciphers

DESCRIPTION
Secure ciphers TLS encryption is only possible with ciphers that are
considered as secure by the German Federal Office for Information
Security. A TLS connection is only established if the email
server of the communication partner supports one of the following ciphers:

• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-RSA-AES256-SHA384
• DHE-RSA-AES256-GCM-SHA384
• DHE-RSA-AES256-SHA256
• ECDHE-RSA-AES128-GCM-SHA256
• ECDHE-RSA-AES128-SHA256
• DHE-RSA-AES128-GCM-SHA256
• DHE-RSA-AES128-SHA256
"


On Mon, Feb 7, 2022 at 4:08 PM Eric Broch  wrote:

Is there a way to contact them and find out what obscure B.S. they want?

On 2/7/2022 12:26 AM, Peter Peltonen wrote:

When trying to deliver email to a domain that is using spam protection
from antispameurope.com I get the following error:

deferral: 
TLS_connect_failed:_error:1421C105:SSL_routines:set_client_ciphersuite:wrong_cipher_returnedZConnected_to_83.246.65.85_but_connection_died._(#4.4.2)/

So am I missing something here:

[root@mail ~]# cat /var/qmail/control/tlsclientciphers
TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:ADH-SEED-SHA:SEED-SHA:IDEA-CBC-SHA:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-CCM8:ECDHE-ECDSA-AES256-CCM:DHE-RSA-AES256-CCM8:DHE-RSA-AES256-CCM:ECDHE-ECDSA-ARIA256-GCM-SHA384:ECDHE-ARIA256-GCM-SHA384:DHE-DSS-ARIA256-GCM-SHA384:DHE-RSA-ARIA256-GCM-SHA384:ADH-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-CCM8:ECDHE-ECDSA-AES128-CCM:DHE-RSA-AES128-CCM8:DHE-RSA-AES128-CCM:ECDHE-ECDSA-ARIA128-GCM-SHA256:ECDHE-ARIA128-GCM-SHA256:DHE-DSS-ARIA128-GCM-SHA256:DHE-RSA-ARIA128-GCM-SHA256:ADH-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:ECDHE-ECDSA-CAMELLIA256-SHA384:ECDHE-RSA-CAMELLIA256-SHA384:DHE-RSA-CAMELLIA256-SHA256:DHE-DSS-CAMELLIA256-SHA256:ADH-AES256-SHA256:ADH-CAMELLIA256-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:ECDHE-ECDSA-CAMELLIA128-SHA256:ECDHE-RSA-CAMELLIA128-SHA256:DHE-RSA-CAMELLIA128-SHA256:DHE-DSS-CAMELLIA128-SHA256:ADH-AES128-SHA256:ADH-CAMELLIA128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:AECDH-AES256-SHA:ADH-AES256-SHA:ADH-CAMELLIA256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:AECDH-AES128-SHA:ADH-AES128-SHA:ADH-CAMELLIA128-SHA:RSA-PSK-AES256-GCM-SHA384:DHE-PSK-AES256-GCM-SHA384:RSA-PSK-CHACHA20-POLY1305:DHE-PSK-CHACHA20-POLY1305:ECDHE-PSK-CHACHA20-POLY1305:DHE-PSK-AES256-CCM8:DHE-PSK-AES256-CCM:RSA-PSK-ARIA256-GCM-SHA384:DHE-PSK-ARIA256-GCM-SHA384:AES256-GCM-SHA384:AES256-CCM8:AES256-CCM:ARIA256-GCM-SHA384:PSK-AES256-GCM-SHA384:PSK-CHACHA20-POLY1305:PSK-AES256-CCM8:PSK-AES256-CCM:PSK-ARIA256-GCM-SHA384:RSA-PSK-AES128-GCM-SHA256:DHE-PSK-AES128-GCM-SHA256:DHE-PSK-AES128-CCM8:DHE-PSK-AES128-CCM:RSA-PSK-ARIA128-GCM-SHA256:DHE-PSK-ARIA128-GCM-SHA256:AES128-GCM-SHA256:AES128-CCM8:AES128-CCM:ARIA128-GCM-SHA256:PSK-AES128-GCM-SHA256:PSK-AES128-CCM8:PSK-AES128-CCM:PSK-ARIA128-GCM-SHA256:AES256-SHA256:CAMELLIA256-SHA256:AES128-SHA256:CAMELLIA128-SHA256:ECDHE-PSK-AES256-CBC-SHA

Re: [qmailtoaster] TLS connection failed: ciphersuite wrong

[Eric Broch]

No update necessary.

No difference in TLS, it is the same in 3.3.1 and 3.3.5.

What about a shot in the dark as I'm at a loss (right now) as to what 
they want:


Since tlsclientciphers is a link to tlsserverciphers I'm wondering if 
copying tlsserverciphers to tlsserverciphers.bak and only putting those 
allowable ciphers in tlsserverciphers.


I'm not sure why it is a problem since all ciphers are being passed to 
the server host and it is indicating that the ones they want aren't 
among them.


Eric

On 2/15/2022 1:39 AM, Peter Peltonen wrote:

What I have installed is qmail-1.03-3.3.1.qt.md.el8.x86_64

Any reason to update?

Best,
Peter

On Sun, Feb 13, 2022 at 5:15 PM Eric Broch  wrote:

What version of qmail ?

On 2/12/2022 12:56 PM, Peter Peltonen wrote:

Finally got an answer from them (see list below). I see some matching
siphers on their and on my own list. Any idea how I could debug this
more so I can find out why mail is not being delivered to their
server?

best,
Peter

"
OPTON
All ciphers

DESCRIPTION
TLS encryption is only possible with ciphers that are considered as
secure by the German Federal Office for Information Security. A TLS
connection is only established if the email server of the
communication partner supports one of the following ciphers:

• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-RSA-AES256-SHA384
• ECDHE-RSA-AES256-SHA
• DHE-RSA-AES256-GCM-SHA384
• DHE-RSA-AES256-SHA256
• DHE-RSA-AES256-SHA
• AES256-GCM-SHA384
• AES256-SHA256
• AES256-SHA
• ECDHE-RSA-DES-CBC3-SHA
• EDH-RSA-DES-CBC3-SHA
• DES-CBC3-SHA

OPTION
Secure ciphers

DESCRIPTION
Secure ciphers TLS encryption is only possible with ciphers that are
considered as secure by the German Federal Office for Information
Security. A TLS connection is only established if the email
server of the communication partner supports one of the following ciphers:

• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-RSA-AES256-SHA384
• DHE-RSA-AES256-GCM-SHA384
• DHE-RSA-AES256-SHA256
• ECDHE-RSA-AES128-GCM-SHA256
• ECDHE-RSA-AES128-SHA256
• DHE-RSA-AES128-GCM-SHA256
• DHE-RSA-AES128-SHA256
"


On Mon, Feb 7, 2022 at 4:08 PM Eric Broch  wrote:

Is there a way to contact them and find out what obscure B.S. they want?

On 2/7/2022 12:26 AM, Peter Peltonen wrote:

When trying to deliver email to a domain that is using spam protection
from antispameurope.com I get the following error:

deferral: 
TLS_connect_failed:_error:1421C105:SSL_routines:set_client_ciphersuite:wrong_cipher_returnedZConnected_to_83.246.65.85_but_connection_died._(#4.4.2)/

So am I missing something here:

[root@mail ~]# cat /var/qmail/control/tlsclientciphers
TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:ADH-SEED-SHA:SEED-SHA:IDEA-CBC-SHA:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-CCM8:ECDHE-ECDSA-AES256-CCM:DHE-RSA-AES256-CCM8:DHE-RSA-AES256-CCM:ECDHE-ECDSA-ARIA256-GCM-SHA384:ECDHE-ARIA256-GCM-SHA384:DHE-DSS-ARIA256-GCM-SHA384:DHE-RSA-ARIA256-GCM-SHA384:ADH-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-CCM8:ECDHE-ECDSA-AES128-CCM:DHE-RSA-AES128-CCM8:DHE-RSA-AES128-CCM:ECDHE-ECDSA-ARIA128-GCM-SHA256:ECDHE-ARIA128-GCM-SHA256:DHE-DSS-ARIA128-GCM-SHA256:DHE-RSA-ARIA128-GCM-SHA256:ADH-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:ECDHE-ECDSA-CAMELLIA256-SHA384:ECDHE-RSA-CAMELLIA256-SHA384:DHE-RSA-CAMELLIA256-SHA256:DHE-DSS-CAMELLIA256-SHA256:ADH-AES256-SHA256:ADH-CAMELLIA256-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:ECDHE-ECDSA-CAMELLIA128-SHA256:ECDHE-RSA-CAMELLIA128-SHA256:DHE-RSA-CAMELLIA128-SHA256:DHE-DSS-CAMELLIA128-SHA256:ADH-AES128-SHA256:ADH-CAMELLIA128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:AECDH-AES256-SHA:ADH-AES256-SHA:ADH-CAMELLIA256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:AECDH-AES128-SHA:ADH-AES128-SHA:ADH-CAMELLIA128-SHA:RSA-PSK-AES256-GCM-SHA384:DHE-PSK-AES256-GCM-SHA384:RSA-PSK-CHACHA20-POLY1305:DHE-PSK-CHACHA20-POLY1305:ECDHE-PSK-CHACHA20-POLY1305:DHE-PSK-AES256-CCM8:DHE-PSK-AES256-CCM:RSA-PSK-ARIA256-GCM-SHA384:DHE-PSK-ARIA256-GCM-SHA384:AES256-GCM-SHA384:AES256-CCM8:AES256-CCM:ARIA256-GCM-SHA384:PSK-AES256-GCM-SHA384:PSK-CHACHA20-POLY1305:PSK-AES256-CCM8:PSK-AES256-CCM:PSK-ARIA256-GCM-SHA384:RSA-PSK-AES128-GCM-SHA256:DHE-PSK-AES128-GCM-SHA256:DHE-PSK-AES128-CCM8:DHE-PSK-AES128-CCM:RSA-PSK-ARIA128-GCM-SHA256:DHE-PSK-ARIA128-GCM-SHA256:AES128-GCM-SHA256:AES128-CCM8:AES128-CCM:ARIA128-GCM-SHA256:PSK-AES128-GCM-SHA2

Re: [qmailtoaster] TLS connection failed: ciphersuite wrong

[Peter Peltonen]

What I have installed is qmail-1.03-3.3.1.qt.md.el8.x86_64

Any reason to update?

Best,
Peter

On Sun, Feb 13, 2022 at 5:15 PM Eric Broch  wrote:
>
> What version of qmail ?
>
> On 2/12/2022 12:56 PM, Peter Peltonen wrote:
> > Finally got an answer from them (see list below). I see some matching
> > siphers on their and on my own list. Any idea how I could debug this
> > more so I can find out why mail is not being delivered to their
> > server?
> >
> > best,
> > Peter
> >
> > "
> > OPTON
> > All ciphers
> >
> > DESCRIPTION
> > TLS encryption is only possible with ciphers that are considered as
> > secure by the German Federal Office for Information Security. A TLS
> > connection is only established if the email server of the
> > communication partner supports one of the following ciphers:
> >
> > • ECDHE-RSA-AES256-GCM-SHA384
> > • ECDHE-RSA-AES256-SHA384
> > • ECDHE-RSA-AES256-SHA
> > • DHE-RSA-AES256-GCM-SHA384
> > • DHE-RSA-AES256-SHA256
> > • DHE-RSA-AES256-SHA
> > • AES256-GCM-SHA384
> > • AES256-SHA256
> > • AES256-SHA
> > • ECDHE-RSA-DES-CBC3-SHA
> > • EDH-RSA-DES-CBC3-SHA
> > • DES-CBC3-SHA
> >
> > OPTION
> > Secure ciphers
> >
> > DESCRIPTION
> > Secure ciphers TLS encryption is only possible with ciphers that are
> > considered as secure by the German Federal Office for Information
> > Security. A TLS connection is only established if the email
> > server of the communication partner supports one of the following ciphers:
> >
> > • ECDHE-RSA-AES256-GCM-SHA384
> > • ECDHE-RSA-AES256-SHA384
> > • DHE-RSA-AES256-GCM-SHA384
> > • DHE-RSA-AES256-SHA256
> > • ECDHE-RSA-AES128-GCM-SHA256
> > • ECDHE-RSA-AES128-SHA256
> > • DHE-RSA-AES128-GCM-SHA256
> > • DHE-RSA-AES128-SHA256
> > "
> >
> >
> > On Mon, Feb 7, 2022 at 4:08 PM Eric Broch  wrote:
> >> Is there a way to contact them and find out what obscure B.S. they want?
> >>
> >> On 2/7/2022 12:26 AM, Peter Peltonen wrote:
> >>> When trying to deliver email to a domain that is using spam protection
> >>> from antispameurope.com I get the following error:
> >>>
> >>> deferral: 
> >>> TLS_connect_failed:_error:1421C105:SSL_routines:set_client_ciphersuite:wrong_cipher_returnedZConnected_to_83.246.65.85_but_connection_died._(#4.4.2)/
> >>>
> >>> So am I missing something here:
> >>>
> >>> [root@mail ~]# cat /var/qmail/control/tlsclientciphers
> >>> TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:ADH-SEED-SHA:SEED-SHA:IDEA-CBC-SHA:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-CCM8:ECDHE-ECDSA-AES256-CCM:DHE-RSA-AES256-CCM8:DHE-RSA-AES256-CCM:ECDHE-ECDSA-ARIA256-GCM-SHA384:ECDHE-ARIA256-GCM-SHA384:DHE-DSS-ARIA256-GCM-SHA384:DHE-RSA-ARIA256-GCM-SHA384:ADH-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-CCM8:ECDHE-ECDSA-AES128-CCM:DHE-RSA-AES128-CCM8:DHE-RSA-AES128-CCM:ECDHE-ECDSA-ARIA128-GCM-SHA256:ECDHE-ARIA128-GCM-SHA256:DHE-DSS-ARIA128-GCM-SHA256:DHE-RSA-ARIA128-GCM-SHA256:ADH-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:ECDHE-ECDSA-CAMELLIA256-SHA384:ECDHE-RSA-CAMELLIA256-SHA384:DHE-RSA-CAMELLIA256-SHA256:DHE-DSS-CAMELLIA256-SHA256:ADH-AES256-SHA256:ADH-CAMELLIA256-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:ECDHE-ECDSA-CAMELLIA128-SHA256:ECDHE-RSA-CAMELLIA128-SHA256:DHE-RSA-CAMELLIA128-SHA256:DHE-DSS-CAMELLIA128-SHA256:ADH-AES128-SHA256:ADH-CAMELLIA128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:AECDH-AES256-SHA:ADH-AES256-SHA:ADH-CAMELLIA256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:AECDH-AES128-SHA:ADH-AES128-SHA:ADH-CAMELLIA128-SHA:RSA-PSK-AES256-GCM-SHA384:DHE-PSK-AES256-GCM-SHA384:RSA-PSK-CHACHA20-POLY1305:DHE-PSK-CHACHA20-POLY1305:ECDHE-PSK-CHACHA20-POLY1305:DHE-PSK-AES256-CCM8:DHE-PSK-AES256-CCM:RSA-PSK-ARIA256-GCM-SHA384:DHE-PSK-ARIA256-GCM-SHA384:AES256-GCM-SHA384:AES256-CCM8:AES256-CCM:ARIA256-GCM-SHA384:PSK-AES256-GCM-SHA384:PSK-CHACHA20-POLY1305:PSK-AES256-CCM8:PSK-AES256-CCM:PSK-ARIA256-GCM-SHA384:RSA-PSK-AES128-GCM-SHA256:DHE-PSK-AES128-GCM-SHA256:DHE-PSK-AES128-CCM8:DHE-PSK-AES128-CCM:RSA-PSK-ARIA128-GCM-SHA256:DHE-PSK-ARIA128-GCM-SHA256:AES128-GCM-SHA256:AES128-CCM8:AES128-CCM:ARIA128-GCM-SHA256:PSK-AES128-GCM-SHA256:PSK-AES128-CCM8:PSK-AES128-CCM:PSK-ARIA128-GCM-SHA256:AES256-SHA256:CAMELLIA256-SHA256:AES128-SHA256:CAMELLIA128-SHA256:ECDHE-PSK-AES256-CBC-SHA384:ECDHE-PSK-AES256-CBC-SHA:SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:SRP-AES-256-CBC-SHA:RSA-PSK-AES256-CBC-SHA384:DHE-PSK-AES25

Re: [qmailtoaster] TLS connection failed: ciphersuite wrong

[Eric Broch]

What version of qmail ?

On 2/12/2022 12:56 PM, Peter Peltonen wrote:

Finally got an answer from them (see list below). I see some matching
siphers on their and on my own list. Any idea how I could debug this
more so I can find out why mail is not being delivered to their
server?

best,
Peter

"
OPTON
All ciphers

DESCRIPTION
TLS encryption is only possible with ciphers that are considered as
secure by the German Federal Office for Information Security. A TLS
connection is only established if the email server of the
communication partner supports one of the following ciphers:

• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-RSA-AES256-SHA384
• ECDHE-RSA-AES256-SHA
• DHE-RSA-AES256-GCM-SHA384
• DHE-RSA-AES256-SHA256
• DHE-RSA-AES256-SHA
• AES256-GCM-SHA384
• AES256-SHA256
• AES256-SHA
• ECDHE-RSA-DES-CBC3-SHA
• EDH-RSA-DES-CBC3-SHA
• DES-CBC3-SHA

OPTION
Secure ciphers

DESCRIPTION
Secure ciphers TLS encryption is only possible with ciphers that are
considered as secure by the German Federal Office for Information
Security. A TLS connection is only established if the email
server of the communication partner supports one of the following ciphers:

• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-RSA-AES256-SHA384
• DHE-RSA-AES256-GCM-SHA384
• DHE-RSA-AES256-SHA256
• ECDHE-RSA-AES128-GCM-SHA256
• ECDHE-RSA-AES128-SHA256
• DHE-RSA-AES128-GCM-SHA256
• DHE-RSA-AES128-SHA256
"


On Mon, Feb 7, 2022 at 4:08 PM Eric Broch  wrote:

Is there a way to contact them and find out what obscure B.S. they want?

On 2/7/2022 12:26 AM, Peter Peltonen wrote:

When trying to deliver email to a domain that is using spam protection
from antispameurope.com I get the following error:

deferral: 
TLS_connect_failed:_error:1421C105:SSL_routines:set_client_ciphersuite:wrong_cipher_returnedZConnected_to_83.246.65.85_but_connection_died._(#4.4.2)/

So am I missing something here:

[root@mail ~]# cat /var/qmail/control/tlsclientciphers
TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:ADH-SEED-SHA:SEED-SHA:IDEA-CBC-SHA:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-CCM8:ECDHE-ECDSA-AES256-CCM:DHE-RSA-AES256-CCM8:DHE-RSA-AES256-CCM:ECDHE-ECDSA-ARIA256-GCM-SHA384:ECDHE-ARIA256-GCM-SHA384:DHE-DSS-ARIA256-GCM-SHA384:DHE-RSA-ARIA256-GCM-SHA384:ADH-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-CCM8:ECDHE-ECDSA-AES128-CCM:DHE-RSA-AES128-CCM8:DHE-RSA-AES128-CCM:ECDHE-ECDSA-ARIA128-GCM-SHA256:ECDHE-ARIA128-GCM-SHA256:DHE-DSS-ARIA128-GCM-SHA256:DHE-RSA-ARIA128-GCM-SHA256:ADH-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:ECDHE-ECDSA-CAMELLIA256-SHA384:ECDHE-RSA-CAMELLIA256-SHA384:DHE-RSA-CAMELLIA256-SHA256:DHE-DSS-CAMELLIA256-SHA256:ADH-AES256-SHA256:ADH-CAMELLIA256-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:ECDHE-ECDSA-CAMELLIA128-SHA256:ECDHE-RSA-CAMELLIA128-SHA256:DHE-RSA-CAMELLIA128-SHA256:DHE-DSS-CAMELLIA128-SHA256:ADH-AES128-SHA256:ADH-CAMELLIA128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:AECDH-AES256-SHA:ADH-AES256-SHA:ADH-CAMELLIA256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:AECDH-AES128-SHA:ADH-AES128-SHA:ADH-CAMELLIA128-SHA:RSA-PSK-AES256-GCM-SHA384:DHE-PSK-AES256-GCM-SHA384:RSA-PSK-CHACHA20-POLY1305:DHE-PSK-CHACHA20-POLY1305:ECDHE-PSK-CHACHA20-POLY1305:DHE-PSK-AES256-CCM8:DHE-PSK-AES256-CCM:RSA-PSK-ARIA256-GCM-SHA384:DHE-PSK-ARIA256-GCM-SHA384:AES256-GCM-SHA384:AES256-CCM8:AES256-CCM:ARIA256-GCM-SHA384:PSK-AES256-GCM-SHA384:PSK-CHACHA20-POLY1305:PSK-AES256-CCM8:PSK-AES256-CCM:PSK-ARIA256-GCM-SHA384:RSA-PSK-AES128-GCM-SHA256:DHE-PSK-AES128-GCM-SHA256:DHE-PSK-AES128-CCM8:DHE-PSK-AES128-CCM:RSA-PSK-ARIA128-GCM-SHA256:DHE-PSK-ARIA128-GCM-SHA256:AES128-GCM-SHA256:AES128-CCM8:AES128-CCM:ARIA128-GCM-SHA256:PSK-AES128-GCM-SHA256:PSK-AES128-CCM8:PSK-AES128-CCM:PSK-ARIA128-GCM-SHA256:AES256-SHA256:CAMELLIA256-SHA256:AES128-SHA256:CAMELLIA128-SHA256:ECDHE-PSK-AES256-CBC-SHA384:ECDHE-PSK-AES256-CBC-SHA:SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:SRP-AES-256-CBC-SHA:RSA-PSK-AES256-CBC-SHA384:DHE-PSK-AES256-CBC-SHA384:RSA-PSK-AES256-CBC-SHA:DHE-PSK-AES256-CBC-SHA:ECDHE-PSK-CAMELLIA256-SHA384:RSA-PSK-CAMELLIA256-SHA384:DHE-PSK-CAMELLIA256-SHA384:AES256-SHA:CAMELLIA256-SHA:PSK-AES256-CBC-SHA384:PSK-AES256-CBC-SHA:PSK-CAMELLIA256-SHA384:ECDHE-PSK-AES128-CBC-SHA256:ECDHE-PSK-AES128-CBC-SHA:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:SRP-AES-128-CBC-SHA:RSA-PSK-AES128-CBC-SHA256:DHE-PSK-AES128-CBC-SHA256:RSA-PSK-AES128

Re: [qmailtoaster] TLS connection failed: ciphersuite wrong

[Peter Peltonen]

Finally got an answer from them (see list below). I see some matching
siphers on their and on my own list. Any idea how I could debug this
more so I can find out why mail is not being delivered to their
server?

best,
Peter

"
OPTON
All ciphers

DESCRIPTION
TLS encryption is only possible with ciphers that are considered as
secure by the German Federal Office for Information Security. A TLS
connection is only established if the email server of the
communication partner supports one of the following ciphers:

• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-RSA-AES256-SHA384
• ECDHE-RSA-AES256-SHA
• DHE-RSA-AES256-GCM-SHA384
• DHE-RSA-AES256-SHA256
• DHE-RSA-AES256-SHA
• AES256-GCM-SHA384
• AES256-SHA256
• AES256-SHA
• ECDHE-RSA-DES-CBC3-SHA
• EDH-RSA-DES-CBC3-SHA
• DES-CBC3-SHA

OPTION
Secure ciphers

DESCRIPTION
Secure ciphers TLS encryption is only possible with ciphers that are
considered as secure by the German Federal Office for Information
Security. A TLS connection is only established if the email
server of the communication partner supports one of the following ciphers:

• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-RSA-AES256-SHA384
• DHE-RSA-AES256-GCM-SHA384
• DHE-RSA-AES256-SHA256
• ECDHE-RSA-AES128-GCM-SHA256
• ECDHE-RSA-AES128-SHA256
• DHE-RSA-AES128-GCM-SHA256
• DHE-RSA-AES128-SHA256
"


On Mon, Feb 7, 2022 at 4:08 PM Eric Broch  wrote:
>
> Is there a way to contact them and find out what obscure B.S. they want?
>
> On 2/7/2022 12:26 AM, Peter Peltonen wrote:
> > When trying to deliver email to a domain that is using spam protection
> > from antispameurope.com I get the following error:
> >
> > deferral: 
> > TLS_connect_failed:_error:1421C105:SSL_routines:set_client_ciphersuite:wrong_cipher_returnedZConnected_to_83.246.65.85_but_connection_died._(#4.4.2)/
> >
> > So am I missing something here:
> >
> > [root@mail ~]# cat /var/qmail/control/tlsclientciphers
> > TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:ADH-SEED-SHA:SEED-SHA:IDEA-CBC-SHA:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-CCM8:ECDHE-ECDSA-AES256-CCM:DHE-RSA-AES256-CCM8:DHE-RSA-AES256-CCM:ECDHE-ECDSA-ARIA256-GCM-SHA384:ECDHE-ARIA256-GCM-SHA384:DHE-DSS-ARIA256-GCM-SHA384:DHE-RSA-ARIA256-GCM-SHA384:ADH-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-CCM8:ECDHE-ECDSA-AES128-CCM:DHE-RSA-AES128-CCM8:DHE-RSA-AES128-CCM:ECDHE-ECDSA-ARIA128-GCM-SHA256:ECDHE-ARIA128-GCM-SHA256:DHE-DSS-ARIA128-GCM-SHA256:DHE-RSA-ARIA128-GCM-SHA256:ADH-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:ECDHE-ECDSA-CAMELLIA256-SHA384:ECDHE-RSA-CAMELLIA256-SHA384:DHE-RSA-CAMELLIA256-SHA256:DHE-DSS-CAMELLIA256-SHA256:ADH-AES256-SHA256:ADH-CAMELLIA256-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:ECDHE-ECDSA-CAMELLIA128-SHA256:ECDHE-RSA-CAMELLIA128-SHA256:DHE-RSA-CAMELLIA128-SHA256:DHE-DSS-CAMELLIA128-SHA256:ADH-AES128-SHA256:ADH-CAMELLIA128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:AECDH-AES256-SHA:ADH-AES256-SHA:ADH-CAMELLIA256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:AECDH-AES128-SHA:ADH-AES128-SHA:ADH-CAMELLIA128-SHA:RSA-PSK-AES256-GCM-SHA384:DHE-PSK-AES256-GCM-SHA384:RSA-PSK-CHACHA20-POLY1305:DHE-PSK-CHACHA20-POLY1305:ECDHE-PSK-CHACHA20-POLY1305:DHE-PSK-AES256-CCM8:DHE-PSK-AES256-CCM:RSA-PSK-ARIA256-GCM-SHA384:DHE-PSK-ARIA256-GCM-SHA384:AES256-GCM-SHA384:AES256-CCM8:AES256-CCM:ARIA256-GCM-SHA384:PSK-AES256-GCM-SHA384:PSK-CHACHA20-POLY1305:PSK-AES256-CCM8:PSK-AES256-CCM:PSK-ARIA256-GCM-SHA384:RSA-PSK-AES128-GCM-SHA256:DHE-PSK-AES128-GCM-SHA256:DHE-PSK-AES128-CCM8:DHE-PSK-AES128-CCM:RSA-PSK-ARIA128-GCM-SHA256:DHE-PSK-ARIA128-GCM-SHA256:AES128-GCM-SHA256:AES128-CCM8:AES128-CCM:ARIA128-GCM-SHA256:PSK-AES128-GCM-SHA256:PSK-AES128-CCM8:PSK-AES128-CCM:PSK-ARIA128-GCM-SHA256:AES256-SHA256:CAMELLIA256-SHA256:AES128-SHA256:CAMELLIA128-SHA256:ECDHE-PSK-AES256-CBC-SHA384:ECDHE-PSK-AES256-CBC-SHA:SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:SRP-AES-256-CBC-SHA:RSA-PSK-AES256-CBC-SHA384:DHE-PSK-AES256-CBC-SHA384:RSA-PSK-AES256-CBC-SHA:DHE-PSK-AES256-CBC-SHA:ECDHE-PSK-CAMELLIA256-SHA384:RSA-PSK-CAMELLIA256-SHA384:DHE-PSK-CAMELLIA256-SHA384:AES256-SHA:CAMELLIA256-SHA:PSK-AES256-CBC-SHA384:PSK-AES256-CBC-SHA:PSK-CAMELLIA256-SHA384:ECDHE-PSK-AES128-CBC-SHA256:ECDHE-PSK-AES128-CBC-SHA:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:SRP-AES-128-CBC-SHA:RSA-PSK-AES128-CBC-SHA256:DHE-PSK-AES128-CBC-SHA256:RSA-PSK-AES128-CBC-SHA:DHE-PSK-AES128-CBC-SH

Re: [qmailtoaster] TLS connection failed: ciphersuite wrong

[Eric Broch]

Is there a way to contact them and find out what obscure B.S. they want?

On 2/7/2022 12:26 AM, Peter Peltonen wrote:

When trying to deliver email to a domain that is using spam protection
from antispameurope.com I get the following error:

deferral: 
TLS_connect_failed:_error:1421C105:SSL_routines:set_client_ciphersuite:wrong_cipher_returnedZConnected_to_83.246.65.85_but_connection_died._(#4.4.2)/

So am I missing something here:

[root@mail ~]# cat /var/qmail/control/tlsclientciphers
TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:ADH-SEED-SHA:SEED-SHA:IDEA-CBC-SHA:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-CCM8:ECDHE-ECDSA-AES256-CCM:DHE-RSA-AES256-CCM8:DHE-RSA-AES256-CCM:ECDHE-ECDSA-ARIA256-GCM-SHA384:ECDHE-ARIA256-GCM-SHA384:DHE-DSS-ARIA256-GCM-SHA384:DHE-RSA-ARIA256-GCM-SHA384:ADH-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-CCM8:ECDHE-ECDSA-AES128-CCM:DHE-RSA-AES128-CCM8:DHE-RSA-AES128-CCM:ECDHE-ECDSA-ARIA128-GCM-SHA256:ECDHE-ARIA128-GCM-SHA256:DHE-DSS-ARIA128-GCM-SHA256:DHE-RSA-ARIA128-GCM-SHA256:ADH-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:ECDHE-ECDSA-CAMELLIA256-SHA384:ECDHE-RSA-CAMELLIA256-SHA384:DHE-RSA-CAMELLIA256-SHA256:DHE-DSS-CAMELLIA256-SHA256:ADH-AES256-SHA256:ADH-CAMELLIA256-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:ECDHE-ECDSA-CAMELLIA128-SHA256:ECDHE-RSA-CAMELLIA128-SHA256:DHE-RSA-CAMELLIA128-SHA256:DHE-DSS-CAMELLIA128-SHA256:ADH-AES128-SHA256:ADH-CAMELLIA128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:AECDH-AES256-SHA:ADH-AES256-SHA:ADH-CAMELLIA256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:AECDH-AES128-SHA:ADH-AES128-SHA:ADH-CAMELLIA128-SHA:RSA-PSK-AES256-GCM-SHA384:DHE-PSK-AES256-GCM-SHA384:RSA-PSK-CHACHA20-POLY1305:DHE-PSK-CHACHA20-POLY1305:ECDHE-PSK-CHACHA20-POLY1305:DHE-PSK-AES256-CCM8:DHE-PSK-AES256-CCM:RSA-PSK-ARIA256-GCM-SHA384:DHE-PSK-ARIA256-GCM-SHA384:AES256-GCM-SHA384:AES256-CCM8:AES256-CCM:ARIA256-GCM-SHA384:PSK-AES256-GCM-SHA384:PSK-CHACHA20-POLY1305:PSK-AES256-CCM8:PSK-AES256-CCM:PSK-ARIA256-GCM-SHA384:RSA-PSK-AES128-GCM-SHA256:DHE-PSK-AES128-GCM-SHA256:DHE-PSK-AES128-CCM8:DHE-PSK-AES128-CCM:RSA-PSK-ARIA128-GCM-SHA256:DHE-PSK-ARIA128-GCM-SHA256:AES128-GCM-SHA256:AES128-CCM8:AES128-CCM:ARIA128-GCM-SHA256:PSK-AES128-GCM-SHA256:PSK-AES128-CCM8:PSK-AES128-CCM:PSK-ARIA128-GCM-SHA256:AES256-SHA256:CAMELLIA256-SHA256:AES128-SHA256:CAMELLIA128-SHA256:ECDHE-PSK-AES256-CBC-SHA384:ECDHE-PSK-AES256-CBC-SHA:SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:SRP-AES-256-CBC-SHA:RSA-PSK-AES256-CBC-SHA384:DHE-PSK-AES256-CBC-SHA384:RSA-PSK-AES256-CBC-SHA:DHE-PSK-AES256-CBC-SHA:ECDHE-PSK-CAMELLIA256-SHA384:RSA-PSK-CAMELLIA256-SHA384:DHE-PSK-CAMELLIA256-SHA384:AES256-SHA:CAMELLIA256-SHA:PSK-AES256-CBC-SHA384:PSK-AES256-CBC-SHA:PSK-CAMELLIA256-SHA384:ECDHE-PSK-AES128-CBC-SHA256:ECDHE-PSK-AES128-CBC-SHA:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:SRP-AES-128-CBC-SHA:RSA-PSK-AES128-CBC-SHA256:DHE-PSK-AES128-CBC-SHA256:RSA-PSK-AES128-CBC-SHA:DHE-PSK-AES128-CBC-SHA:ECDHE-PSK-CAMELLIA128-SHA256:RSA-PSK-CAMELLIA128-SHA256:DHE-PSK-CAMELLIA128-SHA256:AES128-SHA:CAMELLIA128-SHA:PSK-AES128-CBC-SHA256:PSK-AES128-CBC-SHA:PSK-CAMELLIA128-SHA256

?

Best,
Peter

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

Re: [qmailtoaster] TLS connect failed: connection reset

[Eric Broch]

older Exchange might cause problems

On 1/28/2021 3:57 AM, Mani Kandan wrote:

Hi Eric,
I have setup notlshosts in control folder and fixed this issue.
I think they are using exchange server

Sent from my iPhone


On 27 Jan 2021, at 9:57 PM, Eric Broch  wrote:



Do you know what server is on the other end?

On 1/27/2021 12:54 AM, ChandranManikandan wrote:

Hi Friends,
I am unable to send an email to one of the domains which was working 
earlier.


The below bounce message was sent to that domain.

Do I need to do anything on my server or the problem is on the other 
end?


Hi. This is the qmail-send program at mail.example.net 
.
I'm afraid I wasn't able to deliver your message to the following 
addresses.

This is a permanent error; I've given up. Sorry it didn't work out.

mailto:kellyw...@kennethchaucpa.com>e...@example1.com 
>:

TLS connect failed: connection reset; connected to XXX.XX.XXX.XX.
I'm not going to try again; this message has been in the queue too long.

Am running COS 7 with QMT.
Appreciate anyone could help me.
--
*/Regards,
Manikandan.C
/*

Re: [qmailtoaster] TLS connect failed: connection reset

[Mani Kandan]

Hi Eric, 
I have setup notlshosts in control folder and fixed this issue. 
I think they are using exchange server

Sent from my iPhone

> On 27 Jan 2021, at 9:57 PM, Eric Broch  wrote:
> 
> 
> Do you know what server is on the other end?
> 
> On 1/27/2021 12:54 AM, ChandranManikandan wrote:
>> Hi Friends,
>> I am unable to send an email to one of the domains which was working earlier.
>> 
>> The below bounce message was sent to that domain.
>> 
>> Do I need to do anything on my server or the problem is on the other end?
>> 
>> Hi. This is the qmail-send program at mail.example.net.
>> I'm afraid I wasn't able to deliver your message to the following addresses.
>> This is a permanent error; I've given up. Sorry it didn't work out.
>> 
>> :
>> TLS connect failed: connection reset; connected to XXX.XX.XXX.XX.
>> I'm not going to try again; this message has been in the queue too long.
>> 
>> Am running COS 7 with QMT.
>> Appreciate anyone could help me.
>> -- 
>> Regards,
>> Manikandan.C

Re: [qmailtoaster] TLS connect failed: connection reset

[Eric Broch]

Do you know what server is on the other end?

On 1/27/2021 12:54 AM, ChandranManikandan wrote:

Hi Friends,
I am unable to send an email to one of the domains which was working 
earlier.


The below bounce message was sent to that domain.

Do I need to do anything on my server or the problem is on the other end?

Hi. This is the qmail-send program at mail.example.net 
.
I'm afraid I wasn't able to deliver your message to the following 
addresses.

This is a permanent error; I've given up. Sorry it didn't work out.

mailto:kellyw...@kennethchaucpa.com>e...@example1.com 
>:

TLS connect failed: connection reset; connected to XXX.XX.XXX.XX.
I'm not going to try again; this message has been in the queue too long.

Am running COS 7 with QMT.
Appreciate anyone could help me.
--
*/Regards,
Manikandan.C
/*

Re: [qmailtoaster] TLS v1.2 on Centos 6, Thunderbird 78

[Emiliano Lima]

someone managed to solve this problem ..

Em qui., 12 de nov. de 2020 às 05:46, Janno Sannik  escreveu:

> Hi,
>
>
> Seems to have hit a problem with new Thunderbird 78 disabling tls lower
> than v1.2. So now they cannot connect.
>
> I run a older box on centos 6. OS supports TLS v1.2, but how to make it
> available on courier imaps?
>
> Running a tool on the imap port reports tls v1.0 only.
>
> My qmail version: qmail-toaster-1.03-1.3.22
>
> My courier-imap version: courier-imap-toaster-4.1.2-1.3.10
>
>
> Janno
>
>
> -
> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
>
>

Re: [qmailtoaster] TLS v1.2 on Centos 6, Thunderbird 78

[Peter Peltonen]

Hi,

This problem is also present on older Dovecot on centos5 I still have
installed: dovecot-2.0.17-2.qtp

-> the older dovecot does not support the possibility to disable sslv3

Eric in your repo's cos5 downloads I saw a more recent dovecot that
should support this:

dovecot-2.2.7-0.qt.el5.i386.rpm

I tried upgrading to it but encountered a dependency problem:

# rpm -Uvh dovecot-2.2.7-0.qt.el5.i386.rpm
warning: dovecot-2.2.7-0.qt.el5.i386.rpm: Header V3 DSA signature:
NOKEY, key ID 1bde5fd0
error: Failed dependencies:
libcourierauth.so.0 is needed by (installed)
maildrop-toaster-2.0.3-1.3.8.i686

Tips for solving this dependency problem?

If it is a lot of work then maybe its not worth the trouble as I
should be upgrading to cos8 based install anyway...

Best,
Peter

On Fri, Nov 13, 2020 at 6:50 PM Eric Broch  wrote:
>
> And,
>
> QMT Dovecot RPMs
>
> ftp://ftp.qmailtoaster.org/pub/repo/qmt/CentOS/6/testing/x86_64/
>
>
> On 11/13/2020 9:29 AM, Eric Broch wrote:
>
> Janno,
>
> How to
>
> http://wiki.qmailtoaster.com/index.php/Replacing_Courier_IMAP_with_Dovecot_IMAP
>
> https://wiki.dovecot.org/Migration/Courier
>
> Eric
>
> On 11/13/2020 9:19 AM, Janno Sannik wrote:
>
> Hi,
>
> No. Just looked into it. Seems like depencency goes a little grazy if trying 
> to compile it on centos6. I should convert to new os & dovecot anyway.
> Also it seems qmail itself (smtp) was not affected since thunderbird could 
> send out mail just fine. That would say that qmail itself is using openssl 
> latest tls as needed. I did not bother to recheck as it is working.
>
> I should probably dig into courier->dovecot howto that I saw floating aroud 
> here already instead.
> I have made one conversion. I just made everyone with outlook to readd their 
> mailboxes and I would like to avoid that.
>
> Thanks for help.
>
> Janno
>
> On 13.11.2020 00:01, Eric Broch wrote:
>
> Have you looked at upgrading:
>
> http://www.courier-mta.org/imap/download.html
>
> http://www.courier-mta.org/FAQ.html#rpm
>
>
> On 11/12/2020 12:45 PM, Janno Sannik wrote:
>
> The stackexchange was the first thing I tried, but it seemed just guesswork 
> going on in there.
> And of course - it did not work.
>
> Couriertls manpage says that you can use only:
> TLS_PROTOCOL=proto
>
> Set the protocol version. The possible versions are: SSL2, SSL3, TLS1.
>
> Source: http://manpages.org/couriertls
>
> The code reveals:
> ctx=SSL_CTX_new(protocol && strcmp(protocol, "SSL2") == 0
> ? SSLv2_method():
> protocol && strcmp(protocol, "SSL3") == 0 ? SSLv23_method():
> TLSv1_method());
>
> Which is what I saw - whatever garbage I put in the TLS_PROTOCOL variable - 
> it did not care and defaulted to tlsv1
>
> So looking at the openssl man page: 
> https://www.openssl.org/docs/man1.0.2/man3/TLSv1_method.html
>
> Luckyly there were sslv2 and sslv3 so I did not need to know much about c 
> coding and could just directly make a replacement since they are also 
> absolute.
>
> diff -Nur courier-imap-4.1.2/tcpd/libcouriertls.c 
> courier-imap-4.1.2-new/tcpd/libcouriertls.c
> --- courier-imap-4.1.2/tcpd/libcouriertls.c 2006-10-28 20:47:32.0 
> +0300
> +++ courier-imap-4.1.2-new/tcpd/libcouriertls.c 2020-11-12 21:06:03.338688570 
> +0200
> @@ -416,9 +416,9 @@
> memcpy(info_copy, info, sizeof(*info_copy));
> info_copy->isserver=isserver;
>
> -   ctx=SSL_CTX_new(protocol && strcmp(protocol, "SSL2") == 0
> -   ? SSLv2_method():
> -   protocol && strcmp(protocol, "SSL3") == 0 ? SSLv23_method():
> +   ctx=SSL_CTX_new(protocol && strcmp(protocol, "TLS1_1") == 0
> +   ? TLSv1_1_method():
> +   protocol && strcmp(protocol, "TLS1_2") == 0 ? 
> TLSv1_2_method():
>
>
> rpm was built --with cnt5064 (on centos6 system)
>
> And behold:
>
> openssl s_client -tls1_2 -connect mail.example.com:993
>
> New, TLSv1.2, Cipher is AES256-GCM-SHA384
> Server public key is 2048 bit
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> SSL-Session:
> Protocol  : TLSv1.2
> Cipher: AES256-GCM-SHA384
> Session-ID: 
> 175F44FDDE4230DBDD7200B5E276AB1D87206062931B05EAD68A3892DF3CDB68
> Session-ID-ctx:
> Master-Key: 
> F9BDA2CCD78802E8FE2AFD7B440C5E3F5EE8AFD286ABF39F7BCB7796B55D89C5D043207BCB5E8F5C70D372EFAF30CC65
> PSK identity: None
> PSK identity hint: None
> SRP username: None
> TLS session ticket lifetime hint: 7200 (seconds)
> TLS session ticket:
>
>
> I'm well aware that I'm fixin a dead horse, but just archiving it to myself 
> and anyone it might concern of :)
>
>
> On 12.11.2020 20:17, Eric Broch wrote:
>
> Also
>
> qmail with updated ssl
>
> http://repo.whitehorsetc.com/6/development/x86_64/
>
> On 11/12/2020 11:10 AM, Eric Broch wrote:
>
> This may he

Re: [qmailtoaster] TLS v1.2 on Centos 6, Thunderbird 78

[Eric Broch]

And,

QMT Dovecot RPMs

ftp://ftp.qmailtoaster.org/pub/repo/qmt/CentOS/6/testing/x86_64/


On 11/13/2020 9:29 AM, Eric Broch wrote:


Janno,

How to

http://wiki.qmailtoaster.com/index.php/Replacing_Courier_IMAP_with_Dovecot_IMAP

https://wiki.dovecot.org/Migration/Courier

Eric

On 11/13/2020 9:19 AM, Janno Sannik wrote:

Hi,

No. Just looked into it. Seems like depencency goes a little grazy if 
trying to compile it on centos6. I should convert to new os & dovecot 
anyway.
Also it seems qmail itself (smtp) was not affected since thunderbird 
could send out mail just fine. That would say that qmail itself is 
using openssl latest tls as needed. I did not bother to recheck as it 
is working.


I should probably dig into courier->dovecot howto that I saw floating 
aroud here already instead.
I have made one conversion. I just made everyone with outlook to 
readd their mailboxes and I would like to avoid that.


Thanks for help.

Janno

On 13.11.2020 00:01, Eric Broch wrote:


Have you looked at upgrading:

http://www.courier-mta.org/imap/download.html

http://www.courier-mta.org/FAQ.html#rpm


On 11/12/2020 12:45 PM, Janno Sannik wrote:
The stackexchange was the first thing I tried, but it seemed just 
guesswork going on in there.

And of course - it did not work.

Couriertls manpage says that you can use only:
TLS_PROTOCOL=proto

Set the protocol version. The possible versions are: SSL2, SSL3, TLS1.

Source: http://manpages.org/couriertls

The code reveals:
    ctx=SSL_CTX_new(protocol && strcmp(protocol, "SSL2") == 0
    ? 
SSLv2_method():
    protocol && strcmp(protocol, "SSL3") == 0 ? 
SSLv23_method():

    TLSv1_method());

Which is what I saw - whatever garbage I put in the TLS_PROTOCOL 
variable - it did not care and defaulted to tlsv1


So looking at the openssl man page: 
https://www.openssl.org/docs/man1.0.2/man3/TLSv1_method.html


Luckyly there were sslv2 and sslv3 so I did not need to know much 
about c coding and could just directly make a replacement since 
they are also absolute.


diff -Nur courier-imap-4.1.2/tcpd/libcouriertls.c 
courier-imap-4.1.2-new/tcpd/libcouriertls.c
--- courier-imap-4.1.2/tcpd/libcouriertls.c 2006-10-28 
20:47:32.0 +0300
+++ courier-imap-4.1.2-new/tcpd/libcouriertls.c 2020-11-12 
21:06:03.338688570 +0200

@@ -416,9 +416,9 @@
    memcpy(info_copy, info, sizeof(*info_copy));
    info_copy->isserver=isserver;

-   ctx=SSL_CTX_new(protocol && strcmp(protocol, "SSL2") == 0
-   ? 
SSLv2_method():
-   protocol && strcmp(protocol, "SSL3") == 0 ? 
SSLv23_method():

+   ctx=SSL_CTX_new(protocol && strcmp(protocol, "TLS1_1") == 0
+   ? 
TLSv1_1_method():
+   protocol && strcmp(protocol, "TLS1_2") == 0 ? 
TLSv1_2_method():



rpm was built --with cnt5064 (on centos6 system)

And behold:

openssl s_client -tls1_2 -connect mail.example.com:993

New, TLSv1.2, Cipher is AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : AES256-GCM-SHA384
    Session-ID: 
175F44FDDE4230DBDD7200B5E276AB1D87206062931B05EAD68A3892DF3CDB68

    Session-ID-ctx:
    Master-Key: 
F9BDA2CCD78802E8FE2AFD7B440C5E3F5EE8AFD286ABF39F7BCB7796B55D89C5D043207BCB5E8F5C70D372EFAF30CC65

    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:


I'm well aware that I'm fixin a dead horse, but just archiving it 
to myself and anyone it might concern of :)



On 12.11.2020 20:17, Eric Broch wrote:


Also

qmail with updated ssl

http://repo.whitehorsetc.com/6/development/x86_64/

On 11/12/2020 11:10 AM, Eric Broch wrote:


This may help with Courier IMAP

https://serverfault.com/questions/845162/disabling-sslv2-in-courier-imap


On 11/12/2020 10:50 AM, Janno Sannik wrote:


Yes. I probably compiled it to centos 6 myself (i have been 
using qmail from start of it's days when compiling it was usual, 
around 17 years). This specific box dates back to that time and 
is also the reason for this mixed setup.


[root@mail]# cat /etc/redhat-release
CentOS release 6.10 (Final)


I was not sure if it will work with latest one. We had a few 
modifications to the qmail, but I can't be 100% sure of all the 
things. Like autoresponder in mysql (so we can have easy change 
of autoresponders from our own web management panel).
Also I was probably afraid to mess up mailboxes if switching to 
dovecot. Since packages simply compiled it was fast and safe 
transition


So i'm guessing it's out of scope for you because I have this 
mixed setup what anyone should not even have in a first place.


I'm thinking of making centos 8 box with all latest qmail 
packages and mounting it with

Re: [qmailtoaster] TLS v1.2 on Centos 6, Thunderbird 78

[Eric Broch]

Janno,

How to

http://wiki.qmailtoaster.com/index.php/Replacing_Courier_IMAP_with_Dovecot_IMAP

https://wiki.dovecot.org/Migration/Courier

Eric

On 11/13/2020 9:19 AM, Janno Sannik wrote:

Hi,

No. Just looked into it. Seems like depencency goes a little grazy if 
trying to compile it on centos6. I should convert to new os & dovecot 
anyway.
Also it seems qmail itself (smtp) was not affected since thunderbird 
could send out mail just fine. That would say that qmail itself is 
using openssl latest tls as needed. I did not bother to recheck as it 
is working.


I should probably dig into courier->dovecot howto that I saw floating 
aroud here already instead.
I have made one conversion. I just made everyone with outlook to readd 
their mailboxes and I would like to avoid that.


Thanks for help.

Janno

On 13.11.2020 00:01, Eric Broch wrote:


Have you looked at upgrading:

http://www.courier-mta.org/imap/download.html

http://www.courier-mta.org/FAQ.html#rpm


On 11/12/2020 12:45 PM, Janno Sannik wrote:
The stackexchange was the first thing I tried, but it seemed just 
guesswork going on in there.

And of course - it did not work.

Couriertls manpage says that you can use only:
TLS_PROTOCOL=proto

Set the protocol version. The possible versions are: SSL2, SSL3, TLS1.

Source: http://manpages.org/couriertls

The code reveals:
    ctx=SSL_CTX_new(protocol && strcmp(protocol, "SSL2") == 0
    ? 
SSLv2_method():
    protocol && strcmp(protocol, "SSL3") == 0 ? 
SSLv23_method():

    TLSv1_method());

Which is what I saw - whatever garbage I put in the TLS_PROTOCOL 
variable - it did not care and defaulted to tlsv1


So looking at the openssl man page: 
https://www.openssl.org/docs/man1.0.2/man3/TLSv1_method.html


Luckyly there were sslv2 and sslv3 so I did not need to know much 
about c coding and could just directly make a replacement since they 
are also absolute.


diff -Nur courier-imap-4.1.2/tcpd/libcouriertls.c 
courier-imap-4.1.2-new/tcpd/libcouriertls.c
--- courier-imap-4.1.2/tcpd/libcouriertls.c 2006-10-28 
20:47:32.0 +0300
+++ courier-imap-4.1.2-new/tcpd/libcouriertls.c 2020-11-12 
21:06:03.338688570 +0200

@@ -416,9 +416,9 @@
    memcpy(info_copy, info, sizeof(*info_copy));
    info_copy->isserver=isserver;

-   ctx=SSL_CTX_new(protocol && strcmp(protocol, "SSL2") == 0
-   ? 
SSLv2_method():
-   protocol && strcmp(protocol, "SSL3") == 0 ? 
SSLv23_method():

+   ctx=SSL_CTX_new(protocol && strcmp(protocol, "TLS1_1") == 0
+   ? 
TLSv1_1_method():
+   protocol && strcmp(protocol, "TLS1_2") == 0 ? 
TLSv1_2_method():



rpm was built --with cnt5064 (on centos6 system)

And behold:

openssl s_client -tls1_2 -connect mail.example.com:993

New, TLSv1.2, Cipher is AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : AES256-GCM-SHA384
    Session-ID: 
175F44FDDE4230DBDD7200B5E276AB1D87206062931B05EAD68A3892DF3CDB68

    Session-ID-ctx:
    Master-Key: 
F9BDA2CCD78802E8FE2AFD7B440C5E3F5EE8AFD286ABF39F7BCB7796B55D89C5D043207BCB5E8F5C70D372EFAF30CC65

    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:


I'm well aware that I'm fixin a dead horse, but just archiving it to 
myself and anyone it might concern of :)



On 12.11.2020 20:17, Eric Broch wrote:


Also

qmail with updated ssl

http://repo.whitehorsetc.com/6/development/x86_64/

On 11/12/2020 11:10 AM, Eric Broch wrote:


This may help with Courier IMAP

https://serverfault.com/questions/845162/disabling-sslv2-in-courier-imap


On 11/12/2020 10:50 AM, Janno Sannik wrote:


Yes. I probably compiled it to centos 6 myself (i have been using 
qmail from start of it's days when compiling it was usual, around 
17 years). This specific box dates back to that time and is also 
the reason for this mixed setup.


[root@mail]# cat /etc/redhat-release
CentOS release 6.10 (Final)


I was not sure if it will work with latest one. We had a few 
modifications to the qmail, but I can't be 100% sure of all the 
things. Like autoresponder in mysql (so we can have easy change 
of autoresponders from our own web management panel).
Also I was probably afraid to mess up mailboxes if switching to 
dovecot. Since packages simply compiled it was fast and safe 
transition


So i'm guessing it's out of scope for you because I have this 
mixed setup what anyone should not even have in a first place.


I'm thinking of making centos 8 box with all latest qmail 
packages and mounting it with nfs in parallel to test things out 
and use it only as a client server (imap,pop). Later on would 
move on to fully replace old machi

Re: [qmailtoaster] TLS v1.2 on Centos 6, Thunderbird 78

[Janno Sannik]

Hi,

No. Just looked into it. Seems like depencency goes a little grazy if 
trying to compile it on centos6. I should convert to new os & dovecot 
anyway.
Also it seems qmail itself (smtp) was not affected since thunderbird 
could send out mail just fine. That would say that qmail itself is using 
openssl latest tls as needed. I did not bother to recheck as it is working.


I should probably dig into courier->dovecot howto that I saw floating 
aroud here already instead.
I have made one conversion. I just made everyone with outlook to readd 
their mailboxes and I would like to avoid that.


Thanks for help.

Janno

On 13.11.2020 00:01, Eric Broch wrote:


Have you looked at upgrading:

http://www.courier-mta.org/imap/download.html

http://www.courier-mta.org/FAQ.html#rpm


On 11/12/2020 12:45 PM, Janno Sannik wrote:
The stackexchange was the first thing I tried, but it seemed just 
guesswork going on in there.

And of course - it did not work.

Couriertls manpage says that you can use only:
TLS_PROTOCOL=proto

Set the protocol version. The possible versions are: SSL2, SSL3, TLS1.

Source: http://manpages.org/couriertls

The code reveals:
    ctx=SSL_CTX_new(protocol && strcmp(protocol, "SSL2") == 0
    ? SSLv2_method():
    protocol && strcmp(protocol, "SSL3") == 0 ? 
SSLv23_method():

    TLSv1_method());

Which is what I saw - whatever garbage I put in the TLS_PROTOCOL 
variable - it did not care and defaulted to tlsv1


So looking at the openssl man page: 
https://www.openssl.org/docs/man1.0.2/man3/TLSv1_method.html


Luckyly there were sslv2 and sslv3 so I did not need to know much 
about c coding and could just directly make a replacement since they 
are also absolute.


diff -Nur courier-imap-4.1.2/tcpd/libcouriertls.c 
courier-imap-4.1.2-new/tcpd/libcouriertls.c
--- courier-imap-4.1.2/tcpd/libcouriertls.c 2006-10-28 
20:47:32.0 +0300
+++ courier-imap-4.1.2-new/tcpd/libcouriertls.c 2020-11-12 
21:06:03.338688570 +0200

@@ -416,9 +416,9 @@
    memcpy(info_copy, info, sizeof(*info_copy));
    info_copy->isserver=isserver;

-   ctx=SSL_CTX_new(protocol && strcmp(protocol, "SSL2") == 0
-   ? SSLv2_method():
-   protocol && strcmp(protocol, "SSL3") == 0 ? 
SSLv23_method():

+   ctx=SSL_CTX_new(protocol && strcmp(protocol, "TLS1_1") == 0
+   ? 
TLSv1_1_method():
+   protocol && strcmp(protocol, "TLS1_2") == 0 ? 
TLSv1_2_method():



rpm was built --with cnt5064 (on centos6 system)

And behold:

openssl s_client -tls1_2 -connect mail.example.com:993

New, TLSv1.2, Cipher is AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : AES256-GCM-SHA384
    Session-ID: 
175F44FDDE4230DBDD7200B5E276AB1D87206062931B05EAD68A3892DF3CDB68

    Session-ID-ctx:
    Master-Key: 
F9BDA2CCD78802E8FE2AFD7B440C5E3F5EE8AFD286ABF39F7BCB7796B55D89C5D043207BCB5E8F5C70D372EFAF30CC65

    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:


I'm well aware that I'm fixin a dead horse, but just archiving it to 
myself and anyone it might concern of :)



On 12.11.2020 20:17, Eric Broch wrote:


Also

qmail with updated ssl

http://repo.whitehorsetc.com/6/development/x86_64/

On 11/12/2020 11:10 AM, Eric Broch wrote:


This may help with Courier IMAP

https://serverfault.com/questions/845162/disabling-sslv2-in-courier-imap


On 11/12/2020 10:50 AM, Janno Sannik wrote:


Yes. I probably compiled it to centos 6 myself (i have been using 
qmail from start of it's days when compiling it was usual, around 
17 years). This specific box dates back to that time and is also 
the reason for this mixed setup.


[root@mail]# cat /etc/redhat-release
CentOS release 6.10 (Final)


I was not sure if it will work with latest one. We had a few 
modifications to the qmail, but I can't be 100% sure of all the 
things. Like autoresponder in mysql (so we can have easy change of 
autoresponders from our own web management panel).
Also I was probably afraid to mess up mailboxes if switching to 
dovecot. Since packages simply compiled it was fast and safe 
transition


So i'm guessing it's out of scope for you because I have this 
mixed setup what anyone should not even have in a first place.


I'm thinking of making centos 8 box with all latest qmail packages 
and mounting it with nfs in parallel to test things out and use it 
only as a client server (imap,pop). Later on would move on to 
fully replace old machine so that incoming mail would also be 
handled. Would it work (accessing vpopmail fs in parallel that is)?


It's getting night time here and would be good time to make 
maintenance so help is 

Re: [qmailtoaster] TLS v1.2 on Centos 6, Thunderbird 78

[Eric Broch]

Have you looked at upgrading:

http://www.courier-mta.org/imap/download.html

http://www.courier-mta.org/FAQ.html#rpm


On 11/12/2020 12:45 PM, Janno Sannik wrote:
The stackexchange was the first thing I tried, but it seemed just 
guesswork going on in there.

And of course - it did not work.

Couriertls manpage says that you can use only:
TLS_PROTOCOL=proto

Set the protocol version. The possible versions are: SSL2, SSL3, TLS1.

Source: http://manpages.org/couriertls

The code reveals:
    ctx=SSL_CTX_new(protocol && strcmp(protocol, "SSL2") == 0
    ? SSLv2_method():
    protocol && strcmp(protocol, "SSL3") == 0 ? 
SSLv23_method():

    TLSv1_method());

Which is what I saw - whatever garbage I put in the TLS_PROTOCOL 
variable - it did not care and defaulted to tlsv1


So looking at the openssl man page: 
https://www.openssl.org/docs/man1.0.2/man3/TLSv1_method.html


Luckyly there were sslv2 and sslv3 so I did not need to know much 
about c coding and could just directly make a replacement since they 
are also absolute.


diff -Nur courier-imap-4.1.2/tcpd/libcouriertls.c 
courier-imap-4.1.2-new/tcpd/libcouriertls.c
--- courier-imap-4.1.2/tcpd/libcouriertls.c 2006-10-28 
20:47:32.0 +0300
+++ courier-imap-4.1.2-new/tcpd/libcouriertls.c 2020-11-12 
21:06:03.338688570 +0200

@@ -416,9 +416,9 @@
    memcpy(info_copy, info, sizeof(*info_copy));
    info_copy->isserver=isserver;

-   ctx=SSL_CTX_new(protocol && strcmp(protocol, "SSL2") == 0
-   ? SSLv2_method():
-   protocol && strcmp(protocol, "SSL3") == 0 ? 
SSLv23_method():

+   ctx=SSL_CTX_new(protocol && strcmp(protocol, "TLS1_1") == 0
+   ? 
TLSv1_1_method():
+   protocol && strcmp(protocol, "TLS1_2") == 0 ? 
TLSv1_2_method():



rpm was built --with cnt5064 (on centos6 system)

And behold:

openssl s_client -tls1_2 -connect mail.example.com:993

New, TLSv1.2, Cipher is AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : AES256-GCM-SHA384
    Session-ID: 
175F44FDDE4230DBDD7200B5E276AB1D87206062931B05EAD68A3892DF3CDB68

    Session-ID-ctx:
    Master-Key: 
F9BDA2CCD78802E8FE2AFD7B440C5E3F5EE8AFD286ABF39F7BCB7796B55D89C5D043207BCB5E8F5C70D372EFAF30CC65

    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:


I'm well aware that I'm fixin a dead horse, but just archiving it to 
myself and anyone it might concern of :)



On 12.11.2020 20:17, Eric Broch wrote:


Also

qmail with updated ssl

http://repo.whitehorsetc.com/6/development/x86_64/

On 11/12/2020 11:10 AM, Eric Broch wrote:


This may help with Courier IMAP

https://serverfault.com/questions/845162/disabling-sslv2-in-courier-imap


On 11/12/2020 10:50 AM, Janno Sannik wrote:


Yes. I probably compiled it to centos 6 myself (i have been using 
qmail from start of it's days when compiling it was usual, around 
17 years). This specific box dates back to that time and is also 
the reason for this mixed setup.


[root@mail]# cat /etc/redhat-release
CentOS release 6.10 (Final)


I was not sure if it will work with latest one. We had a few 
modifications to the qmail, but I can't be 100% sure of all the 
things. Like autoresponder in mysql (so we can have easy change of 
autoresponders from our own web management panel).
Also I was probably afraid to mess up mailboxes if switching to 
dovecot. Since packages simply compiled it was fast and safe transition


So i'm guessing it's out of scope for you because I have this mixed 
setup what anyone should not even have in a first place.


I'm thinking of making centos 8 box with all latest qmail packages 
and mounting it with nfs in parallel to test things out and use it 
only as a client server (imap,pop). Later on would move on to fully 
replace old machine so that incoming mail would also be handled. 
Would it work (accessing vpopmail fs in parallel that is)?


It's getting night time here and would be good time to make 
maintenance so help is appreciated.


Janno

On 12.11.2020 16:53, Eric Broch wrote:


Are you sure you're running CentOS 6?

On 11/12/2020 7:49 AM, Eric Broch wrote:


Sorry,

The *-toaster designation went out with CentOS 5 and we stopped 
using Courier IMAP altogether in CentOS 6


Eric

On 11/12/2020 7:47 AM, Eric Broch wrote:


So,

The *-toaster designation went out with CentOS 6. Did you 
compile/build the RPMs yourself?


Eric

On 11/12/2020 5:10 AM, Emiliano Lima wrote:

hello friend, I have this same problem ..

Em qui., 12 de nov. de 2020 às 5:46 AM, Janno Sannik 
mailto:ja...@foor.ee>> escreveu:


Hi,


Seems to have hit a problem with new Thunderbird 78
di

Re: [qmailtoaster] TLS v1.2 on Centos 6, Thunderbird 78

[Janno Sannik]

The stackexchange was the first thing I tried, but it seemed just 
guesswork going on in there.

And of course - it did not work.

Couriertls manpage says that you can use only:
TLS_PROTOCOL=proto

Set the protocol version. The possible versions are: SSL2, SSL3, TLS1.

Source: http://manpages.org/couriertls

The code reveals:
    ctx=SSL_CTX_new(protocol && strcmp(protocol, "SSL2") == 0
    ? SSLv2_method():
    protocol && strcmp(protocol, "SSL3") == 0 ? 
SSLv23_method():

    TLSv1_method());

Which is what I saw - whatever garbage I put in the TLS_PROTOCOL 
variable - it did not care and defaulted to tlsv1


So looking at the openssl man page: 
https://www.openssl.org/docs/man1.0.2/man3/TLSv1_method.html


Luckyly there were sslv2 and sslv3 so I did not need to know much about 
c coding and could just directly make a replacement since they are also 
absolute.


diff -Nur courier-imap-4.1.2/tcpd/libcouriertls.c 
courier-imap-4.1.2-new/tcpd/libcouriertls.c
--- courier-imap-4.1.2/tcpd/libcouriertls.c 2006-10-28 
20:47:32.0 +0300
+++ courier-imap-4.1.2-new/tcpd/libcouriertls.c 2020-11-12 
21:06:03.338688570 +0200

@@ -416,9 +416,9 @@
    memcpy(info_copy, info, sizeof(*info_copy));
    info_copy->isserver=isserver;

-   ctx=SSL_CTX_new(protocol && strcmp(protocol, "SSL2") == 0
-   ? SSLv2_method():
-   protocol && strcmp(protocol, "SSL3") == 0 ? SSLv23_method():
+   ctx=SSL_CTX_new(protocol && strcmp(protocol, "TLS1_1") == 0
+   ? TLSv1_1_method():
+   protocol && strcmp(protocol, "TLS1_2") == 0 ? 
TLSv1_2_method():



rpm was built --with cnt5064 (on centos6 system)

And behold:

openssl s_client -tls1_2 -connect mail.example.com:993

New, TLSv1.2, Cipher is AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : AES256-GCM-SHA384
    Session-ID: 
175F44FDDE4230DBDD7200B5E276AB1D87206062931B05EAD68A3892DF3CDB68

    Session-ID-ctx:
    Master-Key: 
F9BDA2CCD78802E8FE2AFD7B440C5E3F5EE8AFD286ABF39F7BCB7796B55D89C5D043207BCB5E8F5C70D372EFAF30CC65

    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:


I'm well aware that I'm fixin a dead horse, but just archiving it to 
myself and anyone it might concern of :)



On 12.11.2020 20:17, Eric Broch wrote:


Also

qmail with updated ssl

http://repo.whitehorsetc.com/6/development/x86_64/

On 11/12/2020 11:10 AM, Eric Broch wrote:


This may help with Courier IMAP

https://serverfault.com/questions/845162/disabling-sslv2-in-courier-imap


On 11/12/2020 10:50 AM, Janno Sannik wrote:


Yes. I probably compiled it to centos 6 myself (i have been using 
qmail from start of it's days when compiling it was usual, around 17 
years). This specific box dates back to that time and is also the 
reason for this mixed setup.


[root@mail]# cat /etc/redhat-release
CentOS release 6.10 (Final)


I was not sure if it will work with latest one. We had a few 
modifications to the qmail, but I can't be 100% sure of all the 
things. Like autoresponder in mysql (so we can have easy change of 
autoresponders from our own web management panel).
Also I was probably afraid to mess up mailboxes if switching to 
dovecot. Since packages simply compiled it was fast and safe transition


So i'm guessing it's out of scope for you because I have this mixed 
setup what anyone should not even have in a first place.


I'm thinking of making centos 8 box with all latest qmail packages 
and mounting it with nfs in parallel to test things out and use it 
only as a client server (imap,pop). Later on would move on to fully 
replace old machine so that incoming mail would also be handled. 
Would it work (accessing vpopmail fs in parallel that is)?


It's getting night time here and would be good time to make 
maintenance so help is appreciated.


Janno

On 12.11.2020 16:53, Eric Broch wrote:


Are you sure you're running CentOS 6?

On 11/12/2020 7:49 AM, Eric Broch wrote:


Sorry,

The *-toaster designation went out with CentOS 5 and we stopped 
using Courier IMAP altogether in CentOS 6


Eric

On 11/12/2020 7:47 AM, Eric Broch wrote:


So,

The *-toaster designation went out with CentOS 6. Did you 
compile/build the RPMs yourself?


Eric

On 11/12/2020 5:10 AM, Emiliano Lima wrote:

hello friend, I have this same problem ..

Em qui., 12 de nov. de 2020 às 5:46 AM, Janno Sannik 
mailto:ja...@foor.ee>> escreveu:


Hi,


Seems to have hit a problem with new Thunderbird 78
disabling tls lower
than v1.2. So now they cannot connect.

I run a older box on centos 6. OS supports TLS v1.2, but how
to make it
available on courier i

Re: [qmailtoaster] TLS v1.2 on Centos 6, Thunderbird 78

[Eric Broch]

Also

qmail with updated ssl

http://repo.whitehorsetc.com/6/development/x86_64/

On 11/12/2020 11:10 AM, Eric Broch wrote:


This may help with Courier IMAP

https://serverfault.com/questions/845162/disabling-sslv2-in-courier-imap


On 11/12/2020 10:50 AM, Janno Sannik wrote:


Yes. I probably compiled it to centos 6 myself (i have been using 
qmail from start of it's days when compiling it was usual, around 17 
years). This specific box dates back to that time and is also the 
reason for this mixed setup.


[root@mail]# cat /etc/redhat-release
CentOS release 6.10 (Final)


I was not sure if it will work with latest one. We had a few 
modifications to the qmail, but I can't be 100% sure of all the 
things. Like autoresponder in mysql (so we can have easy change of 
autoresponders from our own web management panel).
Also I was probably afraid to mess up mailboxes if switching to 
dovecot. Since packages simply compiled it was fast and safe transition


So i'm guessing it's out of scope for you because I have this mixed 
setup what anyone should not even have in a first place.


I'm thinking of making centos 8 box with all latest qmail packages 
and mounting it with nfs in parallel to test things out and use it 
only as a client server (imap,pop). Later on would move on to fully 
replace old machine so that incoming mail would also be handled. 
Would it work (accessing vpopmail fs in parallel that is)?


It's getting night time here and would be good time to make 
maintenance so help is appreciated.


Janno

On 12.11.2020 16:53, Eric Broch wrote:


Are you sure you're running CentOS 6?

On 11/12/2020 7:49 AM, Eric Broch wrote:


Sorry,

The *-toaster designation went out with CentOS 5 and we stopped 
using Courier IMAP altogether in CentOS 6


Eric

On 11/12/2020 7:47 AM, Eric Broch wrote:


So,

The *-toaster designation went out with CentOS 6. Did you 
compile/build the RPMs yourself?


Eric

On 11/12/2020 5:10 AM, Emiliano Lima wrote:

hello friend, I have this same problem ..

Em qui., 12 de nov. de 2020 às 5:46 AM, Janno Sannik 
mailto:ja...@foor.ee>> escreveu:


Hi,


Seems to have hit a problem with new Thunderbird 78 disabling
tls lower
than v1.2. So now they cannot connect.

I run a older box on centos 6. OS supports TLS v1.2, but how
to make it
available on courier imaps?

Running a tool on the imap port reports tls v1.0 only.

My qmail version: qmail-toaster-1.03-1.3.22

My courier-imap version: courier-imap-toaster-4.1.2-1.3.10


Janno


-
To unsubscribe, e-mail:
qmailtoaster-list-unsubscr...@qmailtoaster.com

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

Re: [qmailtoaster] TLS v1.2 on Centos 6, Thunderbird 78

[Eric Broch]

This may help with Courier IMAP

https://serverfault.com/questions/845162/disabling-sslv2-in-courier-imap


On 11/12/2020 10:50 AM, Janno Sannik wrote:


Yes. I probably compiled it to centos 6 myself (i have been using 
qmail from start of it's days when compiling it was usual, around 17 
years). This specific box dates back to that time and is also the 
reason for this mixed setup.


[root@mail]# cat /etc/redhat-release
CentOS release 6.10 (Final)


I was not sure if it will work with latest one. We had a few 
modifications to the qmail, but I can't be 100% sure of all the 
things. Like autoresponder in mysql (so we can have easy change of 
autoresponders from our own web management panel).
Also I was probably afraid to mess up mailboxes if switching to 
dovecot. Since packages simply compiled it was fast and safe transition


So i'm guessing it's out of scope for you because I have this mixed 
setup what anyone should not even have in a first place.


I'm thinking of making centos 8 box with all latest qmail packages and 
mounting it with nfs in parallel to test things out and use it only as 
a client server (imap,pop). Later on would move on to fully replace 
old machine so that incoming mail would also be handled. Would it work 
(accessing vpopmail fs in parallel that is)?


It's getting night time here and would be good time to make 
maintenance so help is appreciated.


Janno

On 12.11.2020 16:53, Eric Broch wrote:


Are you sure you're running CentOS 6?

On 11/12/2020 7:49 AM, Eric Broch wrote:


Sorry,

The *-toaster designation went out with CentOS 5 and we stopped 
using Courier IMAP altogether in CentOS 6


Eric

On 11/12/2020 7:47 AM, Eric Broch wrote:


So,

The *-toaster designation went out with CentOS 6. Did you 
compile/build the RPMs yourself?


Eric

On 11/12/2020 5:10 AM, Emiliano Lima wrote:

hello friend, I have this same problem ..

Em qui., 12 de nov. de 2020 às 5:46 AM, Janno Sannik 
mailto:ja...@foor.ee>> escreveu:


Hi,


Seems to have hit a problem with new Thunderbird 78 disabling
tls lower
than v1.2. So now they cannot connect.

I run a older box on centos 6. OS supports TLS v1.2, but how
to make it
available on courier imaps?

Running a tool on the imap port reports tls v1.0 only.

My qmail version: qmail-toaster-1.03-1.3.22

My courier-imap version: courier-imap-toaster-4.1.2-1.3.10


Janno


-
To unsubscribe, e-mail:
qmailtoaster-list-unsubscr...@qmailtoaster.com

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

Re: [qmailtoaster] TLS v1.2 on Centos 6, Thunderbird 78

[Janno Sannik]

Yes. I probably compiled it to centos 6 myself (i have been using qmail 
from start of it's days when compiling it was usual, around 17 years). 
This specific box dates back to that time and is also the reason for 
this mixed setup.


[root@mail]# cat /etc/redhat-release
CentOS release 6.10 (Final)


I was not sure if it will work with latest one. We had a few 
modifications to the qmail, but I can't be 100% sure of all the things. 
Like autoresponder in mysql (so we can have easy change of 
autoresponders from our own web management panel).
Also I was probably afraid to mess up mailboxes if switching to dovecot. 
Since packages simply compiled it was fast and safe transition


So i'm guessing it's out of scope for you because I have this mixed 
setup what anyone should not even have in a first place.


I'm thinking of making centos 8 box with all latest qmail packages and 
mounting it with nfs in parallel to test things out and use it only as a 
client server (imap,pop). Later on would move on to fully replace old 
machine so that incoming mail would also be handled. Would it work 
(accessing vpopmail fs in parallel that is)?


It's getting night time here and would be good time to make maintenance 
so help is appreciated.


Janno

On 12.11.2020 16:53, Eric Broch wrote:


Are you sure you're running CentOS 6?

On 11/12/2020 7:49 AM, Eric Broch wrote:


Sorry,

The *-toaster designation went out with CentOS 5 and we stopped using 
Courier IMAP altogether in CentOS 6


Eric

On 11/12/2020 7:47 AM, Eric Broch wrote:


So,

The *-toaster designation went out with CentOS 6. Did you 
compile/build the RPMs yourself?


Eric

On 11/12/2020 5:10 AM, Emiliano Lima wrote:

hello friend, I have this same problem ..

Em qui., 12 de nov. de 2020 às 5:46 AM, Janno Sannik > escreveu:


Hi,


Seems to have hit a problem with new Thunderbird 78 disabling
tls lower
than v1.2. So now they cannot connect.

I run a older box on centos 6. OS supports TLS v1.2, but how to
make it
available on courier imaps?

Running a tool on the imap port reports tls v1.0 only.

My qmail version: qmail-toaster-1.03-1.3.22

My courier-imap version: courier-imap-toaster-4.1.2-1.3.10


Janno


-
To unsubscribe, e-mail:
qmailtoaster-list-unsubscr...@qmailtoaster.com

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

Re: [qmailtoaster] TLS v1.2 on Centos 6, Thunderbird 78

[Eric Broch]

Are you sure you're running CentOS 6?

On 11/12/2020 7:49 AM, Eric Broch wrote:


Sorry,

The *-toaster designation went out with CentOS 5 and we stopped using 
Courier IMAP altogether in CentOS 6


Eric

On 11/12/2020 7:47 AM, Eric Broch wrote:


So,

The *-toaster designation went out with CentOS 6. Did you 
compile/build the RPMs yourself?


Eric

On 11/12/2020 5:10 AM, Emiliano Lima wrote:

hello friend, I have this same problem ..

Em qui., 12 de nov. de 2020 às 5:46 AM, Janno Sannik > escreveu:


Hi,


Seems to have hit a problem with new Thunderbird 78 disabling
tls lower
than v1.2. So now they cannot connect.

I run a older box on centos 6. OS supports TLS v1.2, but how to
make it
available on courier imaps?

Running a tool on the imap port reports tls v1.0 only.

My qmail version: qmail-toaster-1.03-1.3.22

My courier-imap version: courier-imap-toaster-4.1.2-1.3.10


Janno


-
To unsubscribe, e-mail:
qmailtoaster-list-unsubscr...@qmailtoaster.com

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

Re: [qmailtoaster] TLS v1.2 on Centos 6, Thunderbird 78

[Eric Broch]

Sorry,

The *-toaster designation went out with CentOS 5 and we stopped using 
Courier IMAP altogether in CentOS 6


Eric

On 11/12/2020 7:47 AM, Eric Broch wrote:


So,

The *-toaster designation went out with CentOS 6. Did you 
compile/build the RPMs yourself?


Eric

On 11/12/2020 5:10 AM, Emiliano Lima wrote:

hello friend, I have this same problem ..

Em qui., 12 de nov. de 2020 às 5:46 AM, Janno Sannik > escreveu:


Hi,


Seems to have hit a problem with new Thunderbird 78 disabling tls
lower
than v1.2. So now they cannot connect.

I run a older box on centos 6. OS supports TLS v1.2, but how to
make it
available on courier imaps?

Running a tool on the imap port reports tls v1.0 only.

My qmail version: qmail-toaster-1.03-1.3.22

My courier-imap version: courier-imap-toaster-4.1.2-1.3.10


Janno


-
To unsubscribe, e-mail:
qmailtoaster-list-unsubscr...@qmailtoaster.com

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

Re: [qmailtoaster] TLS v1.2 on Centos 6, Thunderbird 78

[Eric Broch]

So,

The *-toaster designation went out with CentOS 6. Did you compile/build 
the RPMs yourself?


Eric

On 11/12/2020 5:10 AM, Emiliano Lima wrote:

hello friend, I have this same problem ..

Em qui., 12 de nov. de 2020 às 5:46 AM, Janno Sannik > escreveu:


Hi,


Seems to have hit a problem with new Thunderbird 78 disabling tls
lower
than v1.2. So now they cannot connect.

I run a older box on centos 6. OS supports TLS v1.2, but how to
make it
available on courier imaps?

Running a tool on the imap port reports tls v1.0 only.

My qmail version: qmail-toaster-1.03-1.3.22

My courier-imap version: courier-imap-toaster-4.1.2-1.3.10


Janno


-
To unsubscribe, e-mail:
qmailtoaster-list-unsubscr...@qmailtoaster.com

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

Re: [qmailtoaster] TLS v1.2 on Centos 6, Thunderbird 78

[Emiliano Lima]

hello friend, I have this same problem ..

Em qui., 12 de nov. de 2020 às 5:46 AM, Janno Sannik 
escreveu:

> Hi,
>
>
> Seems to have hit a problem with new Thunderbird 78 disabling tls lower
> than v1.2. So now they cannot connect.
>
> I run a older box on centos 6. OS supports TLS v1.2, but how to make it
> available on courier imaps?
>
> Running a tool on the imap port reports tls v1.0 only.
>
> My qmail version: qmail-toaster-1.03-1.3.22
>
> My courier-imap version: courier-imap-toaster-4.1.2-1.3.10
>
>
> Janno
>
>
> -
> To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
>
>

Re: [qmailtoaster] TLS reason: 503_MAIL_first_(#5.5.1)

[Chris]

It was PEBKAC.  My settings are now:

#2020-08-08
#tls-certificate-file=/var/qmail/control/servercert.pem
tls-level=smtp

And I'm getting an A+ from the LuxSci TLS tester.

On Sun, Aug 9, 2020 at 4:11 AM Eric Broch  wrote:

> You can also tell in the mail log (/var/log/maillog) if messages have been
> encrypted, spamdyke will let you know if messages from a certain host are
> using TLS. See this entry:
>
> Aug  8 09:59:45 myhost spamdyke[10388]: TLS_ENCRYPTED from: (unknown) to:
> (unknown) origin_ip: 66.163.185.72 origin_rdns:
> sonic329-10.consmr.mail.ne1.yahoo.com auth: (unknown) encryption:
> TLS_PASSTHROUGH reason: (empty)
> On 8/7/2020 8:51 PM, Chris wrote:
>
>
>
> On Sat, Aug 8, 2020 at 1:26 PM Eric Broch  wrote:
>
>> What version of qmail do you have?
>>
> qmail-1.03-3.2.qt.el7.x86_64
>
>>
>> And, what about the email coming from the qmailtoaster-list? Can you send
>> that header along?
>>
> I send most mailing list emails to my gmail account, so I can communicate
> with the list even if my mail server is down.  :)
>
> -Chris
>
>
>
>> It can depend on the remote host as well. If you have a gmail account
>> send yourself an email from it and send the header along. Here's a header
>> from  a gmail account.
>>
>> Received: from unknown (HELO mail-qk1-f177.google.com) (209.85.222.177)
>>   by myhost.whitehorsetc.com with ESMTPS (ECDHE-RSA-AES128-GCM-SHA256 
>> encrypted)
>>
>>
>> On 8/7/2020 7:12 PM, Chris wrote:
>>
>> When I disabled TLS in spamdyke, I sent myself a message from one of the
>> problematic systems that was known to trigger repeats.  That message's
>> headers indicate qmail did not pick up the TLS encryption:
>>
>> Content-Type: ⁨text/html; charset=UTF-8⁩
>> Mime-Version: ⁨1.0⁩
>> X-Ses-Outgoing: ⁨2020.08.07-54.240.37.249⁩
>> Dkim-Signature: ⁨v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;
>> s=2ybsbk45dtwlgerewyfzx5qt442lak5j; d=reddit.com; t=1596830148;
>> h=From:To:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID:Date;
>> bh=hrVase2qeFHtu0bLhsrYTx2n7ISeji9Uin83vE7Xdh4=;
>> b=QrrO2K0wMkJ8uIgTRE1XSNq892ay6s7FXgEnkwZY0KaDDViiUV4h5y5HVYIoZjcv
>> wqZ97y/QgJEKnC98NPGJ9bJJnGbdoHUdaxY+VOx52u6nm8ofu3cS3BQELBuid+PMf2Y
>> E+QOoLacnNtusPmpc1+PVwJKNuIGRsk2pCUmk7os=⁩
>> Dkim-Signature: ⁨v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;
>> s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1596830148;
>> h=From:To:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID:Date:Feedback-ID;
>> bh=hrVase2qeFHtu0bLhsrYTx2n7ISeji9Uin83vE7Xdh4=;
>> b=V18r7xu5iTXqr9kSFDcX/StzbVKQX9nSXcJ/Q4JoHpVRoK5u2sCNikDVVBghOzeT
>> vInG1XcJaOMYMofcCKv0F8TwYAc253AdkK+b5PRn/eE1C2BucNO73/zCggwTSTI6lZG
>> IMPzOiBk77HYMfSH4YEKQWY7dWSqdQGPX0Glf7Wg=⁩
>> Return-Path: ⁨<
>> 01000173ca7e6738-e1b4d416-58b8-47ad-8a02-3c9e2696d0c8-000...@amazonses.com
>> >⁩
>> Feedback-Id:
>> ⁨1.us-east-1.UqlFplRllIQtiw+Kq2b87y7uRSu9p66fMici2AQNsMU=:AmazonSES⁩
>> Content-Transfer-Encoding: ⁨7bit⁩
>> Received: ⁨(qmail 8880 invoked by uid 89); 7 Aug 2020 19:56:04 -⁩
>> Received: ⁨by simscan 1.4.0 ppid: 8871, pid: 8873, t: 2.0387s scanners:
>> attach: 1.4.0 clamav: 0.101.4/m:59/d:25897 spam: 3.4.2⁩
>> *Received: ⁨from unknown (HELO a37-249.smtp-out.amazonses.com
>> ) (54.240.37.249) by
>> mail.bayhosting.net  with SMTP; 7 Aug 2020
>> 19:56:02 -⁩*
>> ⁨<
>> 01000173ca7e6738-e1b4d416-58b8-47ad-8a02-3c9e2696d0c8-000...@email.amazonses.com
>> >⁩
>> Delivered-To: ⁨ckni...@ghostwheel.com⁩
>> Received-Spf: ⁨pass (mail.bayhosting.net: SPF record at amazonses.com
>> designates 54.240.37.249 as permitted sender)
>>
>>
>>
>> On Sat, Aug 8, 2020 at 12:59 PM Eric Broch 
>> wrote:
>>
>>> That's the nature of spamdyke. See the documentation. I understand why
>>> it was programmed the way it was, with TLS, so that it could, after
>>> decrypting the email, operate spam blocking techniques. With qmail doing
>>> decryption everything that passes through spamdyke is encrypted so
>>> examining the email is not possible.
>>> tls-level   none, smtp smtp-no-passthrough or smtps none: Do not offer
>>> or allow SSL/TLS, even if qmail supports it.
>>>
>>> smtp: If tls-certificate-file is given, offer TLS during the SMTP
>>> conversation and decrypt the traffic. If tls-certificate-file is not
>>> given, allow qmail to offer TLS (if it has been patched to provide TLS) and
>>> pass the encrypted traffic to qmail.
>>>
>>> smtp-no-passthrough: If tls-certificate-file is given, offer TLS during
>>> the SMTP conversation and decrypt the traffic. If tls-certificate-file is
>>> not given, prevent TLS from starting.
>>>
>>> smtps: Initiate a SSL session at the beginning of the connection,
>>> before SMTP begins.
>>>
>>> If tls-level is given multiple times, spamdyke will use the last value
>>> it finds.
>>>
>>> If tls-level is not given, spamdyke will use a value of smtp.
>>>
>>> tls-level is not valid within configuration directories.
>>>
>>> See TLS 

Re: [qmailtoaster] TLS reason: 503_MAIL_first_(#5.5.1)

[Eric Broch]

You can also tell in the mail log (/var/log/maillog) if messages have 
been encrypted, spamdyke will let you know if messages from a certain 
host are using TLS. See this entry:


Aug  8 09:59:45 myhost spamdyke[10388]: TLS_ENCRYPTED from: (unknown) 
to: (unknown) origin_ip: 66.163.185.72 origin_rdns: 
sonic329-10.consmr.mail.ne1.yahoo.com auth: (unknown) encryption: 
TLS_PASSTHROUGH reason: (empty)


On 8/7/2020 8:51 PM, Chris wrote:



On Sat, Aug 8, 2020 at 1:26 PM Eric Broch > wrote:


What version of qmail do you have?

qmail-1.03-3.2.qt.el7.x86_64

And, what about the email coming from the qmailtoaster-list? Can
you send that header along?

I send most mailing list emails to my gmail account, so I can 
communicate with the list even if my mail server is down.  :)


-Chris

It can depend on the remote host as well. If you have a gmail
account send yourself an email from it and send the header along.
Here's a header from  a gmail account.

Received: from unknown (HELOmail-qk1-f177.google.com  
) (209.85.222.177)
   bymyhost.whitehorsetc.com    with ESMTPS 
(ECDHE-RSA-AES128-GCM-SHA256 encrypted)


On 8/7/2020 7:12 PM, Chris wrote:

When I disabled TLS in spamdyke, I sent myself a message from one
of the problematic systems that was known to trigger repeats. 
That message's headers indicate qmail did not pick up the TLS
encryption:

Content-Type: ⁨text/html; charset=UTF-8⁩
Mime-Version: ⁨1.0⁩
X-Ses-Outgoing: ⁨2020.08.07-54.240.37.249⁩
Dkim-Signature: ⁨v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;
s=2ybsbk45dtwlgerewyfzx5qt442lak5j; d=reddit.com
; t=1596830148;

h=From:To:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID:Date;
bh=hrVase2qeFHtu0bLhsrYTx2n7ISeji9Uin83vE7Xdh4=;
b=QrrO2K0wMkJ8uIgTRE1XSNq892ay6s7FXgEnkwZY0KaDDViiUV4h5y5HVYIoZjcv
wqZ97y/QgJEKnC98NPGJ9bJJnGbdoHUdaxY+VOx52u6nm8ofu3cS3BQELBuid+PMf2Y
E+QOoLacnNtusPmpc1+PVwJKNuIGRsk2pCUmk7os=⁩
Dkim-Signature: ⁨v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;
s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com
; t=1596830148;

h=From:To:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID:Date:Feedback-ID;
bh=hrVase2qeFHtu0bLhsrYTx2n7ISeji9Uin83vE7Xdh4=;
b=V18r7xu5iTXqr9kSFDcX/StzbVKQX9nSXcJ/Q4JoHpVRoK5u2sCNikDVVBghOzeT
vInG1XcJaOMYMofcCKv0F8TwYAc253AdkK+b5PRn/eE1C2BucNO73/zCggwTSTI6lZG
IMPzOiBk77HYMfSH4YEKQWY7dWSqdQGPX0Glf7Wg=⁩
Return-Path:
⁨<01000173ca7e6738-e1b4d416-58b8-47ad-8a02-3c9e2696d0c8-000...@amazonses.com

>⁩
Feedback-Id:
⁨1.us-east-1.UqlFplRllIQtiw+Kq2b87y7uRSu9p66fMici2AQNsMU=:AmazonSES⁩
Content-Transfer-Encoding: ⁨7bit⁩
Received: ⁨(qmail 8880 invoked by uid 89); 7 Aug 2020 19:56:04 -⁩
Received: ⁨by simscan 1.4.0 ppid: 8871, pid: 8873, t: 2.0387s
scanners: attach: 1.4.0 clamav: 0.101.4/m:59/d:25897 spam: 3.4.2⁩
*Received: ⁨from unknown (HELO a37-249.smtp-out.amazonses.com
) (54.240.37.249) by
mail.bayhosting.net  with SMTP; 7 Aug
2020 19:56:02 -⁩*

⁨<01000173ca7e6738-e1b4d416-58b8-47ad-8a02-3c9e2696d0c8-000...@email.amazonses.com

>⁩
Delivered-To: ⁨ckni...@ghostwheel.com
⁩
Received-Spf: ⁨pass (mail.bayhosting.net
: SPF record at amazonses.com
 designates 54.240.37.249 as permitted sender)



On Sat, Aug 8, 2020 at 12:59 PM Eric Broch
mailto:ebr...@whitehorsetc.com>> wrote:

That's the nature of spamdyke. See the documentation. I
understand why it was programmed the way it was, with TLS, so
that it could, after decrypting the email, operate spam
blocking techniques. With qmail doing decryption everything
that passes through spamdyke is encrypted so examining the
email is not possible.

|tls-level| |none|,|smtp||smtp-no-passthrough|or|smtps|
|none|: Do not offer or allow SSL/TLS, even if qmail supports it.

|smtp|: If|tls-certificate-file|is given, offer TLS during
the SMTP conversation and decrypt the traffic.
If|tls-certificate-file|is not given, allow qmail to offer
TLS (if it has been patched to provide TLS) and pass the
encrypted traffic to qmail.

|smtp-no-passthrough|: If|tls-certificate-file|is given,
offer TLS during the SMTP conversation and decrypt the
traffic. If|tls-certificate-file|is not given, prevent TLS
from starting.

|smtps|: Initiate a SSL session at the b

Re: [qmailtoaster] TLS reason: 503_MAIL_first_(#5.5.1)

[Chris]

On Sat, Aug 8, 2020 at 1:26 PM Eric Broch  wrote:

> What version of qmail do you have?
>
qmail-1.03-3.2.qt.el7.x86_64

>
> And, what about the email coming from the qmailtoaster-list? Can you send
> that header along?
>
I send most mailing list emails to my gmail account, so I can communicate
with the list even if my mail server is down.  :)

-Chris



> It can depend on the remote host as well. If you have a gmail account send
> yourself an email from it and send the header along. Here's a header from
> a gmail account.
>
> Received: from unknown (HELO mail-qk1-f177.google.com) (209.85.222.177)
>   by myhost.whitehorsetc.com with ESMTPS (ECDHE-RSA-AES128-GCM-SHA256 
> encrypted)
>
>
> On 8/7/2020 7:12 PM, Chris wrote:
>
> When I disabled TLS in spamdyke, I sent myself a message from one of the
> problematic systems that was known to trigger repeats.  That message's
> headers indicate qmail did not pick up the TLS encryption:
>
> Content-Type: ⁨text/html; charset=UTF-8⁩
> Mime-Version: ⁨1.0⁩
> X-Ses-Outgoing: ⁨2020.08.07-54.240.37.249⁩
> Dkim-Signature: ⁨v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;
> s=2ybsbk45dtwlgerewyfzx5qt442lak5j; d=reddit.com; t=1596830148;
> h=From:To:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID:Date;
> bh=hrVase2qeFHtu0bLhsrYTx2n7ISeji9Uin83vE7Xdh4=;
> b=QrrO2K0wMkJ8uIgTRE1XSNq892ay6s7FXgEnkwZY0KaDDViiUV4h5y5HVYIoZjcv
> wqZ97y/QgJEKnC98NPGJ9bJJnGbdoHUdaxY+VOx52u6nm8ofu3cS3BQELBuid+PMf2Y
> E+QOoLacnNtusPmpc1+PVwJKNuIGRsk2pCUmk7os=⁩
> Dkim-Signature: ⁨v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;
> s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1596830148;
> h=From:To:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID:Date:Feedback-ID;
> bh=hrVase2qeFHtu0bLhsrYTx2n7ISeji9Uin83vE7Xdh4=;
> b=V18r7xu5iTXqr9kSFDcX/StzbVKQX9nSXcJ/Q4JoHpVRoK5u2sCNikDVVBghOzeT
> vInG1XcJaOMYMofcCKv0F8TwYAc253AdkK+b5PRn/eE1C2BucNO73/zCggwTSTI6lZG
> IMPzOiBk77HYMfSH4YEKQWY7dWSqdQGPX0Glf7Wg=⁩
> Return-Path: ⁨<
> 01000173ca7e6738-e1b4d416-58b8-47ad-8a02-3c9e2696d0c8-000...@amazonses.com
> >⁩
> Feedback-Id:
> ⁨1.us-east-1.UqlFplRllIQtiw+Kq2b87y7uRSu9p66fMici2AQNsMU=:AmazonSES⁩
> Content-Transfer-Encoding: ⁨7bit⁩
> Received: ⁨(qmail 8880 invoked by uid 89); 7 Aug 2020 19:56:04 -⁩
> Received: ⁨by simscan 1.4.0 ppid: 8871, pid: 8873, t: 2.0387s scanners:
> attach: 1.4.0 clamav: 0.101.4/m:59/d:25897 spam: 3.4.2⁩
> *Received: ⁨from unknown (HELO a37-249.smtp-out.amazonses.com
> ) (54.240.37.249) by
> mail.bayhosting.net  with SMTP; 7 Aug 2020
> 19:56:02 -⁩*
> ⁨<
> 01000173ca7e6738-e1b4d416-58b8-47ad-8a02-3c9e2696d0c8-000...@email.amazonses.com
> >⁩
> Delivered-To: ⁨ckni...@ghostwheel.com⁩
> Received-Spf: ⁨pass (mail.bayhosting.net: SPF record at amazonses.com
> designates 54.240.37.249 as permitted sender)
>
>
>
> On Sat, Aug 8, 2020 at 12:59 PM Eric Broch 
> wrote:
>
>> That's the nature of spamdyke. See the documentation. I understand why it
>> was programmed the way it was, with TLS, so that it could, after decrypting
>> the email, operate spam blocking techniques. With qmail doing decryption
>> everything that passes through spamdyke is encrypted so examining the email
>> is not possible.
>> tls-level   none, smtp smtp-no-passthrough or smtps none: Do not offer
>> or allow SSL/TLS, even if qmail supports it.
>>
>> smtp: If tls-certificate-file is given, offer TLS during the SMTP
>> conversation and decrypt the traffic. If tls-certificate-file is not
>> given, allow qmail to offer TLS (if it has been patched to provide TLS) and
>> pass the encrypted traffic to qmail.
>>
>> smtp-no-passthrough: If tls-certificate-file is given, offer TLS during
>> the SMTP conversation and decrypt the traffic. If tls-certificate-file is
>> not given, prevent TLS from starting.
>>
>> smtps: Initiate a SSL session at the beginning of the connection, before
>> SMTP begins.
>>
>> If tls-level is given multiple times, spamdyke will use the last value
>> it finds.
>>
>> If tls-level is not given, spamdyke will use a value of smtp.
>>
>> tls-level is not valid within configuration directories.
>>
>> See TLS  for
>> details.
>>
>>
>> Qmail will pick up TLS negotiation if spamdyke is disabled. You can check
>> the headers of incoming email to confirm.
>>
>> Received: from unknown (HELO mail.qmailtoaster.com) (162.213.42.64)
>>   by myhost.whitehorsetc.com with ESMTPS (DHE-RSA-AES256-SHA encrypted);
>>
>> or in older TLS patches
>>
>> Received: from unknown (HELO mail.qmailtoaster.com) (162.213.42.64)
>>   by myhost.whitehorsetc.com with SMTP (DHE-RSA-AES256-SHA encrypted);
>>
>>
>>
>>
>> On 8/7/2020 6:36 PM, Chris wrote:
>>
>> Why does 'Setting tls-level=none turns of ALL TLS even in qmail's
>> offering' when it's a spamdyke config file, not qmail?
>>
>> What if I think spamdyke is part of my multi-delivery problem?  If I take
>> spamdyke out of the equ

Re: [qmailtoaster] TLS reason: 503_MAIL_first_(#5.5.1)

[Eric Broch]

What version of qmail do you have?

And, what about the email coming from the qmailtoaster-list? Can you 
send that header along?


It can depend on the remote host as well. If you have a gmail account 
send yourself an email from it and send the header along. Here's a 
header from  a gmail account.


Received: from unknown (HELO mail-qk1-f177.google.com) (209.85.222.177)
  by myhost.whitehorsetc.com with ESMTPS (ECDHE-RSA-AES128-GCM-SHA256 encrypted)


On 8/7/2020 7:12 PM, Chris wrote:
When I disabled TLS in spamdyke, I sent myself a message from one of 
the problematic systems that was known to trigger repeats.  That 
message's headers indicate qmail did not pick up the TLS encryption:


Content-Type: ⁨text/html; charset=UTF-8⁩
Mime-Version: ⁨1.0⁩
X-Ses-Outgoing: ⁨2020.08.07-54.240.37.249⁩
Dkim-Signature: ⁨v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; 
s=2ybsbk45dtwlgerewyfzx5qt442lak5j; d=reddit.com ; 
t=1596830148; 
h=From:To:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID:Date; 
bh=hrVase2qeFHtu0bLhsrYTx2n7ISeji9Uin83vE7Xdh4=; 
b=QrrO2K0wMkJ8uIgTRE1XSNq892ay6s7FXgEnkwZY0KaDDViiUV4h5y5HVYIoZjcv 
wqZ97y/QgJEKnC98NPGJ9bJJnGbdoHUdaxY+VOx52u6nm8ofu3cS3BQELBuid+PMf2Y 
E+QOoLacnNtusPmpc1+PVwJKNuIGRsk2pCUmk7os=⁩
Dkim-Signature: ⁨v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; 
s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com 
; t=1596830148; 
h=From:To:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID:Date:Feedback-ID; 
bh=hrVase2qeFHtu0bLhsrYTx2n7ISeji9Uin83vE7Xdh4=; 
b=V18r7xu5iTXqr9kSFDcX/StzbVKQX9nSXcJ/Q4JoHpVRoK5u2sCNikDVVBghOzeT 
vInG1XcJaOMYMofcCKv0F8TwYAc253AdkK+b5PRn/eE1C2BucNO73/zCggwTSTI6lZG 
IMPzOiBk77HYMfSH4YEKQWY7dWSqdQGPX0Glf7Wg=⁩
Return-Path: 
⁨<01000173ca7e6738-e1b4d416-58b8-47ad-8a02-3c9e2696d0c8-000...@amazonses.com 
>⁩
Feedback-Id: 
⁨1.us-east-1.UqlFplRllIQtiw+Kq2b87y7uRSu9p66fMici2AQNsMU=:AmazonSES⁩

Content-Transfer-Encoding: ⁨7bit⁩
Received: ⁨(qmail 8880 invoked by uid 89); 7 Aug 2020 19:56:04 -⁩
Received: ⁨by simscan 1.4.0 ppid: 8871, pid: 8873, t: 2.0387s 
scanners: attach: 1.4.0 clamav: 0.101.4/m:59/d:25897 spam: 3.4.2⁩
*Received: ⁨from unknown (HELO a37-249.smtp-out.amazonses.com 
) (54.240.37.249) by 
mail.bayhosting.net  with SMTP; 7 Aug 2020 
19:56:02 -⁩*
⁨<01000173ca7e6738-e1b4d416-58b8-47ad-8a02-3c9e2696d0c8-000...@email.amazonses.com 
>⁩

Delivered-To: ⁨ckni...@ghostwheel.com ⁩
Received-Spf: ⁨pass (mail.bayhosting.net : 
SPF record at amazonses.com  designates 
54.240.37.249 as permitted sender)




On Sat, Aug 8, 2020 at 12:59 PM Eric Broch > wrote:


That's the nature of spamdyke. See the documentation. I understand
why it was programmed the way it was, with TLS, so that it could,
after decrypting the email, operate spam blocking techniques. With
qmail doing decryption everything that passes through spamdyke is
encrypted so examining the email is not possible.

|tls-level| |none|,|smtp||smtp-no-passthrough|or|smtps| 
|none|:
Do not offer or allow SSL/TLS, even if qmail supports it.

|smtp|: If|tls-certificate-file|is given, offer TLS during the
SMTP conversation and decrypt the traffic.
If|tls-certificate-file|is not given, allow qmail to offer TLS (if
it has been patched to provide TLS) and pass the encrypted traffic
to qmail.

|smtp-no-passthrough|: If|tls-certificate-file|is given, offer TLS
during the SMTP conversation and decrypt the traffic.
If|tls-certificate-file|is not given, prevent TLS from starting.

|smtps|: Initiate a SSL session at the beginning of the
connection, before SMTP begins.

If|tls-level|is given multiple times, spamdyke will use the last
value it finds.

If|tls-level|is not given, spamdyke will use a value of|smtp|.

|tls-level|is not valid within configuration directories.

SeeTLS for
details.



Qmail will pick up TLS negotiation if spamdyke is disabled. You
can check the headers of incoming email to confirm.

Received: from unknown (HELOmail.qmailtoaster.com  
) (162.213.42.64)
   bymyhost.whitehorsetc.com    with ESMTPS 
(DHE-RSA-AES256-SHA encrypted);

or in older TLS patches

Received: from unknown (HELOmail.qmailtoaster.com  
) (162.213.42.64)
   bymyhost.whitehorsetc.com    with SMTP 
(DHE-RSA-AES256-SHA encrypted);



On 8/7/2020 6:36 PM, Chris wrote:

Why does 'Setting tls-le

Re: [qmailtoaster] TLS reason: 503_MAIL_first_(#5.5.1)

[Chris]

When I disabled TLS in spamdyke, I sent myself a message from one of the
problematic systems that was known to trigger repeats.  That message's
headers indicate qmail did not pick up the TLS encryption:

Content-Type: ⁨text/html; charset=UTF-8⁩
Mime-Version: ⁨1.0⁩
X-Ses-Outgoing: ⁨2020.08.07-54.240.37.249⁩
Dkim-Signature: ⁨v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;
s=2ybsbk45dtwlgerewyfzx5qt442lak5j; d=reddit.com; t=1596830148;
h=From:To:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID:Date;
bh=hrVase2qeFHtu0bLhsrYTx2n7ISeji9Uin83vE7Xdh4=;
b=QrrO2K0wMkJ8uIgTRE1XSNq892ay6s7FXgEnkwZY0KaDDViiUV4h5y5HVYIoZjcv
wqZ97y/QgJEKnC98NPGJ9bJJnGbdoHUdaxY+VOx52u6nm8ofu3cS3BQELBuid+PMf2Y
E+QOoLacnNtusPmpc1+PVwJKNuIGRsk2pCUmk7os=⁩
Dkim-Signature: ⁨v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple;
s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1596830148;
h=From:To:Subject:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID:Date:Feedback-ID;
bh=hrVase2qeFHtu0bLhsrYTx2n7ISeji9Uin83vE7Xdh4=;
b=V18r7xu5iTXqr9kSFDcX/StzbVKQX9nSXcJ/Q4JoHpVRoK5u2sCNikDVVBghOzeT
vInG1XcJaOMYMofcCKv0F8TwYAc253AdkK+b5PRn/eE1C2BucNO73/zCggwTSTI6lZG
IMPzOiBk77HYMfSH4YEKQWY7dWSqdQGPX0Glf7Wg=⁩
Return-Path: ⁨<
01000173ca7e6738-e1b4d416-58b8-47ad-8a02-3c9e2696d0c8-000...@amazonses.com>⁩
Feedback-Id:
⁨1.us-east-1.UqlFplRllIQtiw+Kq2b87y7uRSu9p66fMici2AQNsMU=:AmazonSES⁩
Content-Transfer-Encoding: ⁨7bit⁩
Received: ⁨(qmail 8880 invoked by uid 89); 7 Aug 2020 19:56:04 -⁩
Received: ⁨by simscan 1.4.0 ppid: 8871, pid: 8873, t: 2.0387s scanners:
attach: 1.4.0 clamav: 0.101.4/m:59/d:25897 spam: 3.4.2⁩
*Received: ⁨from unknown (HELO a37-249.smtp-out.amazonses.com
) (54.240.37.249) by
mail.bayhosting.net  with SMTP; 7 Aug 2020
19:56:02 -⁩*
⁨<
01000173ca7e6738-e1b4d416-58b8-47ad-8a02-3c9e2696d0c8-000...@email.amazonses.com
>⁩
Delivered-To: ⁨ckni...@ghostwheel.com⁩
Received-Spf: ⁨pass (mail.bayhosting.net: SPF record at amazonses.com
designates 54.240.37.249 as permitted sender)



On Sat, Aug 8, 2020 at 12:59 PM Eric Broch  wrote:

> That's the nature of spamdyke. See the documentation. I understand why it
> was programmed the way it was, with TLS, so that it could, after decrypting
> the email, operate spam blocking techniques. With qmail doing decryption
> everything that passes through spamdyke is encrypted so examining the email
> is not possible.
> tls-level   none, smtp smtp-no-passthrough or smtps none: Do not offer or
> allow SSL/TLS, even if qmail supports it.
>
> smtp: If tls-certificate-file is given, offer TLS during the SMTP
> conversation and decrypt the traffic. If tls-certificate-file is not
> given, allow qmail to offer TLS (if it has been patched to provide TLS) and
> pass the encrypted traffic to qmail.
>
> smtp-no-passthrough: If tls-certificate-file is given, offer TLS during
> the SMTP conversation and decrypt the traffic. If tls-certificate-file is
> not given, prevent TLS from starting.
>
> smtps: Initiate a SSL session at the beginning of the connection, before
> SMTP begins.
>
> If tls-level is given multiple times, spamdyke will use the last value it
> finds.
>
> If tls-level is not given, spamdyke will use a value of smtp.
>
> tls-level is not valid within configuration directories.
>
> See TLS  for
> details.
>
>
> Qmail will pick up TLS negotiation if spamdyke is disabled. You can check
> the headers of incoming email to confirm.
>
> Received: from unknown (HELO mail.qmailtoaster.com) (162.213.42.64)
>   by myhost.whitehorsetc.com with ESMTPS (DHE-RSA-AES256-SHA encrypted);
>
> or in older TLS patches
>
> Received: from unknown (HELO mail.qmailtoaster.com) (162.213.42.64)
>   by myhost.whitehorsetc.com with SMTP (DHE-RSA-AES256-SHA encrypted);
>
>
>
>
> On 8/7/2020 6:36 PM, Chris wrote:
>
> Why does 'Setting tls-level=none turns of ALL TLS even in qmail's
> offering' when it's a spamdyke config file, not qmail?
>
> What if I think spamdyke is part of my multi-delivery problem?  If I take
> spamdyke out of the equation in smtp/run how do I get qmail to pick up the
> TLS negotiation?
>
> On Sat, Aug 8, 2020 at 12:28 PM Eric Broch 
> wrote:
>
>> I'm not sure I like how spamdyke handles tls, though I don't know another
>> way one would do it.
>>
>> Setting tls-level=none turns of ALL TLS even in qmail's offering.
>>
>> If you want qmail to handle TLS comment the certificate file:
>>
>> #tls-certificate-file=/var/qmail/control/servercert.pem
>>
>> However, if you do this, spamdyke (I think) will not work anymore because
>> all traffic through it is now encrypted (you could check if I'm correct on
>> the spamdyke mailing list).
>> On 8/7/2020 6:13 PM, Chris wrote:
>>
>> I know I'm responding to a really old thread here, but I stumbled upon
>> this trying to solve another issue.
>>
>> When I set tls-level=none in /opt/spamdyke/etc/spamdyke.conf and reboot,
>> I now completel

Re: [qmailtoaster] TLS reason: 503_MAIL_first_(#5.5.1)

[Eric Broch]

That's the nature of spamdyke. See the documentation. I understand why 
it was programmed the way it was, with TLS, so that it could, after 
decrypting the email, operate spam blocking techniques. With qmail doing 
decryption everything that passes through spamdyke is encrypted so 
examining the email is not possible.


|tls-level| 		|none|,|smtp||smtp-no-passthrough|or|smtps| 	|none|: Do 
not offer or allow SSL/TLS, even if qmail supports it.


|smtp|: If|tls-certificate-file|is given, offer TLS during the SMTP 
conversation and decrypt the traffic. If|tls-certificate-file|is not 
given, allow qmail to offer TLS (if it has been patched to provide TLS) 
and pass the encrypted traffic to qmail.


|smtp-no-passthrough|: If|tls-certificate-file|is given, offer TLS 
during the SMTP conversation and decrypt the traffic. 
If|tls-certificate-file|is not given, prevent TLS from starting.


|smtps|: Initiate a SSL session at the beginning of the connection, 
before SMTP begins.


If|tls-level|is given multiple times, spamdyke will use the last value 
it finds.


If|tls-level|is not given, spamdyke will use a value of|smtp|.

|tls-level|is not valid within configuration directories.

SeeTLS for details.



Qmail will pick up TLS negotiation if spamdyke is disabled. You can 
check the headers of incoming email to confirm.


Received: from unknown (HELO mail.qmailtoaster.com) (162.213.42.64)
  by myhost.whitehorsetc.com with ESMTPS (DHE-RSA-AES256-SHA encrypted);

or in older TLS patches

Received: from unknown (HELO mail.qmailtoaster.com) (162.213.42.64)
  by myhost.whitehorsetc.com with SMTP (DHE-RSA-AES256-SHA encrypted);



On 8/7/2020 6:36 PM, Chris wrote:
Why does 'Setting tls-level=none turns of ALL TLS even in qmail's 
offering' when it's a spamdyke config file, not qmail?


What if I think spamdyke is part of my multi-delivery problem?  If I 
take spamdyke out of the equation in smtp/run how do I get qmail to 
pick up the TLS negotiation?


On Sat, Aug 8, 2020 at 12:28 PM Eric Broch > wrote:


I'm not sure I like how spamdyke handles tls, though I don't know
another way one would do it.

Setting tls-level=none turns of ALL TLS even in qmail's offering.

If you want qmail to handle TLS comment the certificate file:

#tls-certificate-file=/var/qmail/control/servercert.pem

However, if you do this, spamdyke (I think) will not work anymore
because all traffic through it is now encrypted (you could check
if I'm correct on the spamdyke mailing list).

On 8/7/2020 6:13 PM, Chris wrote:

I know I'm responding to a really old thread here, but I stumbled
upon this trying to solve another issue.

When I set tls-level=none in /opt/spamdyke/etc/spamdyke.conf and
reboot, I now completely fail the SMTP TLS checker at
https://luxsci.com/smtp-tls-checker
It would appear that qmail isn't doing the tls at all.

Where are the settings to telling qmail to handle the tls? Is it
in the run file, or elsewhere?

On Wed, Jun 19, 2019 at 3:14 AM Eric Broch
mailto:ebr...@whitehorsetc.com>> wrote:

In /etc/spamdyke/spamdyke.conf set 'tls-level' to 'none'.

tls-level=none

allow qmail to do the tls and see if it works.


On 6/18/2019 9:07 AM, Rajesh M wrote:

eric

in the spamdyke.conf i can see this
tls-certificate-file=/var/qmail/control/servercert.pem

also i am using the
/var/qmail/control/servercert.pem
for domain key signing of outgoing emails.

rajesh

- Original Message -
From: Eric Broch [mailto:ebr...@whitehorsetc.com]
To:qmailtoaster-list@qmailtoaster.com  

Sent: Tue, 18 Jun 2019 08:52:13 -0600
Subject:

So you have spamdyke doing the TLS?

On 6/18/2019 8:38 AM, Rajesh M wrote:

Hi

ISSUE 1
all of a sudden we are receiving error on one of our servers for one 
specific sender domain (sending from microsoft server)

the sender domain is not able to send emails to the recepient domain on 
our server. The email bounces with the following error
encryption: TLS reason: 503_MAIL_first_(#5.5.1)

06/18/2019 19:33:16 LOG OUTPUT TLS
DENIED_OTHER from:rethish.n...@sender.com    
to:nominati...@dxb.recepient.com    origin_ip: 
40.107.69.126 origin_rdns:mail-eopbgr690126.outbound.protection.outlook.com  
  auth: (unknown) encryption: TLS 
reason: 503_MAIL_first_(#5.5.1)
06/18/2019 19:33:16 FROM REMOTE TO CHILD: 6 bytes TLS
QUIT
06/18/2019 19:33:16 LOG OUTPUT TLS
ERROR(tls_write()@tls.c:678): unable to write to SSL/TLS stream: The 
operation failed due to an I/O error, Connecti

Re: [qmailtoaster] TLS reason: 503_MAIL_first_(#5.5.1)

[Chris]

Why does 'Setting tls-level=none turns of ALL TLS even in qmail's offering'
when it's a spamdyke config file, not qmail?

What if I think spamdyke is part of my multi-delivery problem?  If I take
spamdyke out of the equation in smtp/run how do I get qmail to pick up the
TLS negotiation?

On Sat, Aug 8, 2020 at 12:28 PM Eric Broch  wrote:

> I'm not sure I like how spamdyke handles tls, though I don't know another
> way one would do it.
>
> Setting tls-level=none turns of ALL TLS even in qmail's offering.
>
> If you want qmail to handle TLS comment the certificate file:
>
> #tls-certificate-file=/var/qmail/control/servercert.pem
>
> However, if you do this, spamdyke (I think) will not work anymore because
> all traffic through it is now encrypted (you could check if I'm correct on
> the spamdyke mailing list).
> On 8/7/2020 6:13 PM, Chris wrote:
>
> I know I'm responding to a really old thread here, but I stumbled upon
> this trying to solve another issue.
>
> When I set tls-level=none in /opt/spamdyke/etc/spamdyke.conf and reboot,
> I now completely fail the SMTP TLS checker at
> https://luxsci.com/smtp-tls-checker
> It would appear that qmail isn't doing the tls at all.
>
> Where are the settings to telling qmail to handle the tls? Is it in the
> run file, or elsewhere?
>
> On Wed, Jun 19, 2019 at 3:14 AM Eric Broch 
> wrote:
>
>> In /etc/spamdyke/spamdyke.conf set 'tls-level' to 'none'.
>>
>> tls-level=none
>>
>> allow qmail to do the tls and see if it works.
>>
>>
>> On 6/18/2019 9:07 AM, Rajesh M wrote:
>>
>> eric
>>
>> in the spamdyke.conf i can see this
>> tls-certificate-file=/var/qmail/control/servercert.pem
>>
>> also i am using the
>> /var/qmail/control/servercert.pem
>> for domain key signing of outgoing emails.
>>
>> rajesh
>>
>> - Original Message -
>> From: Eric Broch [mailto:ebr...@whitehorsetc.com ]
>> To: qmailtoaster-list@qmailtoaster.com
>> Sent: Tue, 18 Jun 2019 08:52:13 -0600
>> Subject:
>>
>> So you have spamdyke doing the TLS?
>>
>> On 6/18/2019 8:38 AM, Rajesh M wrote:
>>
>> Hi
>>
>> ISSUE 1
>> all of a sudden we are receiving error on one of our servers for one 
>> specific sender domain (sending from microsoft server)
>>
>> the sender domain is not able to send emails to the recepient domain on our 
>> server. The email bounces with the following error
>> encryption: TLS reason: 503_MAIL_first_(#5.5.1)
>>
>> 06/18/2019 19:33:16 LOG OUTPUT TLS
>> DENIED_OTHER from: rethish.n...@sender.com to: nominati...@dxb.recepient.com 
>> origin_ip: 40.107.69.126 origin_rdns: 
>> mail-eopbgr690126.outbound.protection.outlook.com auth: (unknown) 
>> encryption: TLS reason: 503_MAIL_first_(#5.5.1)
>> 06/18/2019 19:33:16 FROM REMOTE TO CHILD: 6 bytes TLS
>> QUIT
>> 06/18/2019 19:33:16 LOG OUTPUT TLS
>> ERROR(tls_write()@tls.c:678): unable to write to SSL/TLS stream: The 
>> operation failed due to an I/O error, Connection reset by peer
>> ERROR(output_writeln()@log.c:104): unable to write 27 bytes to file 
>> descriptor 1: Connection reset by peer
>> 06/18/2019 19:33:16 FROM CHILD TO REMOTE: 27 bytes TLS
>> 221 ns1.HOSTNAME.com
>> 06/18/2019 19:33:16 LOG OUTPUT TLS
>> ERROR(tls_read()@tls.c:620): unable to read from SSL/TLS stream: The 
>> operation failed due to an I/O error, Unexpected EOF found
>>
>> 06/18/2019 19:33:16 - TLS ended and closed
>>
>>
>> the error log of spamdyke  full-log-dir is give below follows
>>
>>
>> ISSUE 2
>> also i noted that spamdyke log mentions as such
>> reset address space soft limit to infinity: please stop using the softlimit 
>> program
>>
>> What exactly does this mean. What is the alternative to prevent large files 
>> should i disable softlimit program in
>> /usr/bin/softlimit -m 6400 \
>> in the smtp run file
>>
>> require your kind help in resolving the above 2 issues
>>
>> thanks
>> rajesh
>>
>> 06/18/2019 19:32:54 STARTED: VERSION = 5.0.1+TLS+CONFIGTEST+DEBUG, PID = 
>> 19829
>>
>> 06/18/2019 19:32:54 CURRENT ENVIRONMENT
>> PATH=/var/qmail/bin:/usr/local/bin:/usr/bin:/bin
>> PWD=/var/qmail/supervise/smtp
>> SHLVL=0
>> PROTO=TCP
>> TCPLOCALIP=103.241.181.154
>> TCPLOCALPORT=25
>> TCPLOCALHOST=ns1.HOSTNAME.com
>> TCPREMOTEIP=40.107.69.126
>> TCPREMOTEPORT=42264
>> BADMIMETYPE=
>> BADLOADERTYPE=M
>> QMAILQUEUE=/var/qmail/bin/simscan
>> CHKUSER_START=ALWAYS
>> CHKUSER_RCPTLIMIT=50
>> CHKUSER_WRONGRCPTLIMIT=10
>> NOP0FCHECK=1
>> DKQUEUE=/var/qmail/bin/qmail-queue.orig
>> DKVERIFY=DEGIJKfh
>> DKSIGN=/var/qmail/control/domainkeys/%/private
>>
>> 06/18/2019 19:32:54 CURRENT CONFIG
>> config-file=/etc/spamdyke/spamdyke.conf
>> dns-blacklist-entry=zen.spamhaus.org
>> full-log-dir=/var/log/spamdyke
>> graylist-dir=/var/spamdyke/graylist
>> graylist-max-secs=2678400
>> graylist-min-secs=180
>> header-blacklist-entry=From:*>,*<*
>> idle-timeout-secs=600
>> ip-blacklist-file=/etc/spamdyke/blacklist_ip
>> ip-in-rdns-keyword-blacklist-file=/etc/spamdyke/blacklist_keywords
>> ip-in-rdns-keyword-whitelist-file=/etc/spamdyke/whitelist_keywords
>> ip-whitelist-fil

Re: [qmailtoaster] TLS reason: 503_MAIL_first_(#5.5.1)

[Eric Broch]

I'm not sure I like how spamdyke handles tls, though I don't know 
another way one would do it.


Setting tls-level=none turns of ALL TLS even in qmail's offering.

If you want qmail to handle TLS comment the certificate file:

#tls-certificate-file=/var/qmail/control/servercert.pem

However, if you do this, spamdyke (I think) will not work anymore 
because all traffic through it is now encrypted (you could check if I'm 
correct on the spamdyke mailing list).


On 8/7/2020 6:13 PM, Chris wrote:
I know I'm responding to a really old thread here, but I stumbled upon 
this trying to solve another issue.


When I set tls-level=none in /opt/spamdyke/etc/spamdyke.conf and 
reboot, I now completely fail the SMTP TLS checker at 
https://luxsci.com/smtp-tls-checker

It would appear that qmail isn't doing the tls at all.

Where are the settings to telling qmail to handle the tls? Is it in 
the run file, or elsewhere?


On Wed, Jun 19, 2019 at 3:14 AM Eric Broch > wrote:


In /etc/spamdyke/spamdyke.conf set 'tls-level' to 'none'.

tls-level=none

allow qmail to do the tls and see if it works.


On 6/18/2019 9:07 AM, Rajesh M wrote:

eric

in the spamdyke.conf i can see this
tls-certificate-file=/var/qmail/control/servercert.pem

also i am using the
/var/qmail/control/servercert.pem
for domain key signing of outgoing emails.

rajesh

- Original Message -
From: Eric Broch [mailto:ebr...@whitehorsetc.com]
To:qmailtoaster-list@qmailtoaster.com  

Sent: Tue, 18 Jun 2019 08:52:13 -0600
Subject:

So you have spamdyke doing the TLS?

On 6/18/2019 8:38 AM, Rajesh M wrote:

Hi

ISSUE 1
all of a sudden we are receiving error on one of our servers for one 
specific sender domain (sending from microsoft server)

the sender domain is not able to send emails to the recepient domain on our 
server. The email bounces with the following error
encryption: TLS reason: 503_MAIL_first_(#5.5.1)

06/18/2019 19:33:16 LOG OUTPUT TLS
DENIED_OTHER from:rethish.n...@sender.com    
to:nominati...@dxb.recepient.com    origin_ip: 
40.107.69.126 origin_rdns:mail-eopbgr690126.outbound.protection.outlook.com  
  auth: (unknown) encryption: TLS 
reason: 503_MAIL_first_(#5.5.1)
06/18/2019 19:33:16 FROM REMOTE TO CHILD: 6 bytes TLS
QUIT
06/18/2019 19:33:16 LOG OUTPUT TLS
ERROR(tls_write()@tls.c:678): unable to write to SSL/TLS stream: The 
operation failed due to an I/O error, Connection reset by peer
ERROR(output_writeln()@log.c:104): unable to write 27 bytes to file 
descriptor 1: Connection reset by peer
06/18/2019 19:33:16 FROM CHILD TO REMOTE: 27 bytes TLS
221ns1.HOSTNAME.com  
06/18/2019 19:33:16 LOG OUTPUT TLS
ERROR(tls_read()@tls.c:620): unable to read from SSL/TLS stream: The 
operation failed due to an I/O error, Unexpected EOF found

06/18/2019 19:33:16 - TLS ended and closed


the error log of spamdyke  full-log-dir is give below follows


ISSUE 2
also i noted that spamdyke log mentions as such
reset address space soft limit to infinity: please stop using the softlimit 
program

What exactly does this mean. What is the alternative to prevent large files 
should i disable softlimit program in
/usr/bin/softlimit -m 6400 \
in the smtp run file

require your kind help in resolving the above 2 issues

thanks
rajesh

06/18/2019 19:32:54 STARTED: VERSION = 5.0.1+TLS+CONFIGTEST+DEBUG, PID = 
19829

06/18/2019 19:32:54 CURRENT ENVIRONMENT
PATH=/var/qmail/bin:/usr/local/bin:/usr/bin:/bin
PWD=/var/qmail/supervise/smtp
SHLVL=0
PROTO=TCP
TCPLOCALIP=103.241.181.154
TCPLOCALPORT=25
TCPLOCALHOST=ns1.HOSTNAME.com  
TCPREMOTEIP=40.107.69.126
TCPREMOTEPORT=42264
BADMIMETYPE=
BADLOADERTYPE=M
QMAILQUEUE=/var/qmail/bin/simscan
CHKUSER_START=ALWAYS
CHKUSER_RCPTLIMIT=50
CHKUSER_WRONGRCPTLIMIT=10
NOP0FCHECK=1
DKQUEUE=/var/qmail/bin/qmail-queue.orig
DKVERIFY=DEGIJKfh
DKSIGN=/var/qmail/control/domainkeys/%/private

06/18/2019 19:32:54 CURRENT CONFIG
config-file=/etc/spamdyke/spamdyke.conf
dns-blacklist-entry=zen.spamhaus.org  
full-log-dir=/var/log/spamdyke
graylist-dir=/var/spamdyke/graylist
graylist-max-secs=2678400
graylist-min-secs=180
header-blacklist-entry=From:*>,*<*
idle-timeout-secs=600
ip-blacklist-file=/etc/spamdyke/blacklist_ip
ip-in-rdns-keyword-blacklist-file=/etc/spamdyke/blacklist_keywords
ip-in-rdns-keyword-whitelist-file=/etc/spamdyke/whitelist_keywords
ip-whitelist-file=/etc/spamdyke/whitelist_ip
log-level=info
max-recipients=100
rdns-blacklist

Re: [qmailtoaster] TLS reason: 503_MAIL_first_(#5.5.1)

[Chris]

I know I'm responding to a really old thread here, but I stumbled upon this
trying to solve another issue.

When I set tls-level=none in /opt/spamdyke/etc/spamdyke.conf and reboot, I
now completely fail the SMTP TLS checker at
https://luxsci.com/smtp-tls-checker
It would appear that qmail isn't doing the tls at all.

Where are the settings to telling qmail to handle the tls? Is it in the run
file, or elsewhere?

On Wed, Jun 19, 2019 at 3:14 AM Eric Broch  wrote:

> In /etc/spamdyke/spamdyke.conf set 'tls-level' to 'none'.
>
> tls-level=none
>
> allow qmail to do the tls and see if it works.
>
>
> On 6/18/2019 9:07 AM, Rajesh M wrote:
>
> eric
>
> in the spamdyke.conf i can see this
> tls-certificate-file=/var/qmail/control/servercert.pem
>
> also i am using the
> /var/qmail/control/servercert.pem
> for domain key signing of outgoing emails.
>
> rajesh
>
> - Original Message -
> From: Eric Broch [mailto:ebr...@whitehorsetc.com ]
> To: qmailtoaster-list@qmailtoaster.com
> Sent: Tue, 18 Jun 2019 08:52:13 -0600
> Subject:
>
> So you have spamdyke doing the TLS?
>
> On 6/18/2019 8:38 AM, Rajesh M wrote:
>
> Hi
>
> ISSUE 1
> all of a sudden we are receiving error on one of our servers for one specific 
> sender domain (sending from microsoft server)
>
> the sender domain is not able to send emails to the recepient domain on our 
> server. The email bounces with the following error
> encryption: TLS reason: 503_MAIL_first_(#5.5.1)
>
> 06/18/2019 19:33:16 LOG OUTPUT TLS
> DENIED_OTHER from: rethish.n...@sender.com to: nominati...@dxb.recepient.com 
> origin_ip: 40.107.69.126 origin_rdns: 
> mail-eopbgr690126.outbound.protection.outlook.com auth: (unknown) encryption: 
> TLS reason: 503_MAIL_first_(#5.5.1)
> 06/18/2019 19:33:16 FROM REMOTE TO CHILD: 6 bytes TLS
> QUIT
> 06/18/2019 19:33:16 LOG OUTPUT TLS
> ERROR(tls_write()@tls.c:678): unable to write to SSL/TLS stream: The 
> operation failed due to an I/O error, Connection reset by peer
> ERROR(output_writeln()@log.c:104): unable to write 27 bytes to file 
> descriptor 1: Connection reset by peer
> 06/18/2019 19:33:16 FROM CHILD TO REMOTE: 27 bytes TLS
> 221 ns1.HOSTNAME.com
> 06/18/2019 19:33:16 LOG OUTPUT TLS
> ERROR(tls_read()@tls.c:620): unable to read from SSL/TLS stream: The 
> operation failed due to an I/O error, Unexpected EOF found
>
> 06/18/2019 19:33:16 - TLS ended and closed
>
>
> the error log of spamdyke  full-log-dir is give below follows
>
>
> ISSUE 2
> also i noted that spamdyke log mentions as such
> reset address space soft limit to infinity: please stop using the softlimit 
> program
>
> What exactly does this mean. What is the alternative to prevent large files 
> should i disable softlimit program in
> /usr/bin/softlimit -m 6400 \
> in the smtp run file
>
> require your kind help in resolving the above 2 issues
>
> thanks
> rajesh
>
> 06/18/2019 19:32:54 STARTED: VERSION = 5.0.1+TLS+CONFIGTEST+DEBUG, PID = 19829
>
> 06/18/2019 19:32:54 CURRENT ENVIRONMENT
> PATH=/var/qmail/bin:/usr/local/bin:/usr/bin:/bin
> PWD=/var/qmail/supervise/smtp
> SHLVL=0
> PROTO=TCP
> TCPLOCALIP=103.241.181.154
> TCPLOCALPORT=25
> TCPLOCALHOST=ns1.HOSTNAME.com
> TCPREMOTEIP=40.107.69.126
> TCPREMOTEPORT=42264
> BADMIMETYPE=
> BADLOADERTYPE=M
> QMAILQUEUE=/var/qmail/bin/simscan
> CHKUSER_START=ALWAYS
> CHKUSER_RCPTLIMIT=50
> CHKUSER_WRONGRCPTLIMIT=10
> NOP0FCHECK=1
> DKQUEUE=/var/qmail/bin/qmail-queue.orig
> DKVERIFY=DEGIJKfh
> DKSIGN=/var/qmail/control/domainkeys/%/private
>
> 06/18/2019 19:32:54 CURRENT CONFIG
> config-file=/etc/spamdyke/spamdyke.conf
> dns-blacklist-entry=zen.spamhaus.org
> full-log-dir=/var/log/spamdyke
> graylist-dir=/var/spamdyke/graylist
> graylist-max-secs=2678400
> graylist-min-secs=180
> header-blacklist-entry=From:*>,*<*
> idle-timeout-secs=600
> ip-blacklist-file=/etc/spamdyke/blacklist_ip
> ip-in-rdns-keyword-blacklist-file=/etc/spamdyke/blacklist_keywords
> ip-in-rdns-keyword-whitelist-file=/etc/spamdyke/whitelist_keywords
> ip-whitelist-file=/etc/spamdyke/whitelist_ip
> log-level=info
> max-recipients=100
> rdns-blacklist-file=/etc/spamdyke/blacklist_rdns
> rdns-whitelist-file=/etc/spamdyke/whitelist_rdns
> recipient-blacklist-file=/etc/spamdyke/blacklist_recipients
> recipient-whitelist-file=/etc/spamdyke/whitelist_recipients
> reject-empty-rdns=1
> reject-sender=no-mx
> reject-sender=authentication-domain-mismatch
> reject-unresolvable-rdns=1
> relay-level=normal
> sender-blacklist-file=/etc/spamdyke/blacklist_senders
> sender-whitelist-file=/etc/spamdyke/whitelist_senders
> tls-certificate-file=/var/qmail/control/servercert.pem
>
> 06/18/2019 19:32:54 - Remote IP = 40.107.69.126
>
> 06/18/2019 19:32:54 CURRENT CONFIG
> config-file=/etc/spamdyke/spamdyke.conf
> dns-blacklist-entry=zen.spamhaus.org
> dns-server-ip-primary=8.8.8.8
> full-log-dir=/var/log/spamdyke
> graylist-dir=/var/spamdyke/graylist
> graylist-max-secs=2678400
> graylist-min-secs=180
> header-blacklist-entry=From:*>,*<*
> idle-timeout-secs=600
> ip-blackl

Re: [qmailtoaster] TLS reason: 503_MAIL_first_(#5.5.1)

[Remo Mattei]

Hi Rajesh, 
I was using the TLS in the spamdyke.conf and I just removed it and it working 
just fine. You maybe facing different issues. 



Remo 

> On Jun 18, 2019, at 9:16 AM, Rajesh M <24x7ser...@24x7server.net> wrote:
> 
> remo
> 
> Were you facing the same issue ?
> 
> Could you please explain in detail the exact steps you followed
> 
> thanks,
> rajesh
> 
> - Original Message -
> From: r...@mattei.org [mailto:r...@mattei.org]
> To: qmailtoaster-list@qmailtoaster.com
> Sent: Tue, 18 Jun 2019 09:13:26 -0700
> Subject:
> 
> I just tested on mine I recalled you do not have to restart the service and 
> it works just fine
> 
>> Il giorno 18 giu 2019, alle ore 09:01, Rajesh M <24x7ser...@24x7server.net> 
>> ha scritto:
>> 
>> hello
>> 
>> it does not work
>> 
>> i get the same error.
>> 
>> auth: (unknown) encryption: (none) reason: 503_MAIL_first_(#5.5.1)
>> 
>> rajesh
>> 
>> 
>> - Original Message -
>> From: Eric Broch [mailto:ebr...@whitehorsetc.com]
>> To: qmailtoaster-list@qmailtoaster.com
>> Sent: Tue, 18 Jun 2019 09:25:59 -0600
>> Subject:
>> 
>> yes,
>> 
>> tls-level=none
>> 
>>> On 6/18/2019 9:19 AM, Rajesh M wrote:
>>> tls-level=smtp ?
>> 
>> -
>> 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
> 
> 
> -
> 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] TLS reason: 503_MAIL_first_(#5.5.1)

[Rajesh M]

remo

Were you facing the same issue ?

Could you please explain in detail the exact steps you followed

thanks,
rajesh

- Original Message -
From: r...@mattei.org [mailto:r...@mattei.org]
To: qmailtoaster-list@qmailtoaster.com
Sent: Tue, 18 Jun 2019 09:13:26 -0700
Subject:

I just tested on mine I recalled you do not have to restart the service and it 
works just fine

> Il giorno 18 giu 2019, alle ore 09:01, Rajesh M <24x7ser...@24x7server.net> 
> ha scritto:
>
> hello
>
> it does not work
>
> i get the same error.
>
> auth: (unknown) encryption: (none) reason: 503_MAIL_first_(#5.5.1)
>
> rajesh
>
>
> - Original Message -
> From: Eric Broch [mailto:ebr...@whitehorsetc.com]
> To: qmailtoaster-list@qmailtoaster.com
> Sent: Tue, 18 Jun 2019 09:25:59 -0600
> Subject:
>
> yes,
>
> tls-level=none
>
>> On 6/18/2019 9:19 AM, Rajesh M wrote:
>> tls-level=smtp ?
>
> -
> 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


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

Re: [qmailtoaster] TLS reason: 503_MAIL_first_(#5.5.1)

[remo]

I just tested on mine I recalled you do not have to restart the service and it 
works just fine

> Il giorno 18 giu 2019, alle ore 09:01, Rajesh M <24x7ser...@24x7server.net> 
> ha scritto:
> 
> hello
> 
> it does not work
> 
> i get the same error.
> 
> auth: (unknown) encryption: (none) reason: 503_MAIL_first_(#5.5.1)
> 
> rajesh
> 
> 
> - Original Message -
> From: Eric Broch [mailto:ebr...@whitehorsetc.com]
> To: qmailtoaster-list@qmailtoaster.com
> Sent: Tue, 18 Jun 2019 09:25:59 -0600
> Subject: 
> 
> yes,
> 
> tls-level=none
> 
>> On 6/18/2019 9:19 AM, Rajesh M wrote:
>> tls-level=smtp ?
> 
> -
> 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
-
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com

Re: [qmailtoaster] TLS reason: 503_MAIL_first_(#5.5.1)

[Rajesh M]

hello

it does not work

i get the same error.

 auth: (unknown) encryption: (none) reason: 503_MAIL_first_(#5.5.1)

rajesh


- Original Message -
From: Eric Broch [mailto:ebr...@whitehorsetc.com]
To: qmailtoaster-list@qmailtoaster.com
Sent: Tue, 18 Jun 2019 09:25:59 -0600
Subject:

yes,

tls-level=none

On 6/18/2019 9:19 AM, Rajesh M wrote:
> tls-level=smtp ?

-
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] TLS reason: 503_MAIL_first_(#5.5.1)

[Eric Broch]

yes,

tls-level=none

On 6/18/2019 9:19 AM, Rajesh M wrote:

tls-level=smtp ?


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

Re: [qmailtoaster] TLS reason: 503_MAIL_first_(#5.5.1)

[Rajesh M]

eric

should i comment the line in the spamdyke.conf
tls-level=smtp ?

#tls-certificate-file=/var/qmail/control/servercert.pem
tls-level=smtp

also please do note that this issue is occurring only for emails received from 
one single external domain.

rajesh


- Original Message -
From: Eric Broch [mailto:ebr...@whitehorsetc.com]
To: qmailtoaster-list@qmailtoaster.com
Sent: Tue, 18 Jun 2019 09:14:27 -0600
Subject:

In /etc/spamdyke/spamdyke.conf set 'tls-level' to 'none'.

tls-level=none

allow qmail to do the tls and see if it works.


On 6/18/2019 9:07 AM, Rajesh M wrote:
> eric
>
> in the spamdyke.conf i can see this
> tls-certificate-file=/var/qmail/control/servercert.pem
>
> also i am using the
> /var/qmail/control/servercert.pem
> for domain key signing of outgoing emails.
>
> rajesh
>
> - Original Message -
> From: Eric Broch [mailto:ebr...@whitehorsetc.com]
> To: qmailtoaster-list@qmailtoaster.com
> Sent: Tue, 18 Jun 2019 08:52:13 -0600
> Subject:
>
> So you have spamdyke doing the TLS?
>
> On 6/18/2019 8:38 AM, Rajesh M wrote:
>> Hi
>>
>> ISSUE 1
>> all of a sudden we are receiving error on one of our servers for one 
>> specific sender domain (sending from microsoft server)
>>
>> the sender domain is not able to send emails to the recepient domain on our 
>> server. The email bounces with the following error
>> encryption: TLS reason: 503_MAIL_first_(#5.5.1)
>>
>> 06/18/2019 19:33:16 LOG OUTPUT TLS
>> DENIED_OTHER from: rethish.n...@sender.com to: nominati...@dxb.recepient.com 
>> origin_ip: 40.107.69.126 origin_rdns: 
>> mail-eopbgr690126.outbound.protection.outlook.com auth: (unknown) 
>> encryption: TLS reason: 503_MAIL_first_(#5.5.1)
>> 06/18/2019 19:33:16 FROM REMOTE TO CHILD: 6 bytes TLS
>> QUIT
>> 06/18/2019 19:33:16 LOG OUTPUT TLS
>> ERROR(tls_write()@tls.c:678): unable to write to SSL/TLS stream: The 
>> operation failed due to an I/O error, Connection reset by peer
>> ERROR(output_writeln()@log.c:104): unable to write 27 bytes to file 
>> descriptor 1: Connection reset by peer
>> 06/18/2019 19:33:16 FROM CHILD TO REMOTE: 27 bytes TLS
>> 221 ns1.HOSTNAME.com
>> 06/18/2019 19:33:16 LOG OUTPUT TLS
>> ERROR(tls_read()@tls.c:620): unable to read from SSL/TLS stream: The 
>> operation failed due to an I/O error, Unexpected EOF found
>>
>> 06/18/2019 19:33:16 - TLS ended and closed
>>
>>
>> the error log of spamdyke  full-log-dir is give below follows
>>
>>
>> ISSUE 2
>> also i noted that spamdyke log mentions as such
>> reset address space soft limit to infinity: please stop using the softlimit 
>> program
>>
>> What exactly does this mean. What is the alternative to prevent large files 
>> should i disable softlimit program in
>> /usr/bin/softlimit -m 6400 \
>> in the smtp run file
>>
>> require your kind help in resolving the above 2 issues
>>
>> thanks
>> rajesh
>>
>> 06/18/2019 19:32:54 STARTED: VERSION = 5.0.1+TLS+CONFIGTEST+DEBUG, PID = 
>> 19829
>>
>> 06/18/2019 19:32:54 CURRENT ENVIRONMENT
>> PATH=/var/qmail/bin:/usr/local/bin:/usr/bin:/bin
>> PWD=/var/qmail/supervise/smtp
>> SHLVL=0
>> PROTO=TCP
>> TCPLOCALIP=103.241.181.154
>> TCPLOCALPORT=25
>> TCPLOCALHOST=ns1.HOSTNAME.com
>> TCPREMOTEIP=40.107.69.126
>> TCPREMOTEPORT=42264
>> BADMIMETYPE=
>> BADLOADERTYPE=M
>> QMAILQUEUE=/var/qmail/bin/simscan
>> CHKUSER_START=ALWAYS
>> CHKUSER_RCPTLIMIT=50
>> CHKUSER_WRONGRCPTLIMIT=10
>> NOP0FCHECK=1
>> DKQUEUE=/var/qmail/bin/qmail-queue.orig
>> DKVERIFY=DEGIJKfh
>> DKSIGN=/var/qmail/control/domainkeys/%/private
>>
>> 06/18/2019 19:32:54 CURRENT CONFIG
>> config-file=/etc/spamdyke/spamdyke.conf
>> dns-blacklist-entry=zen.spamhaus.org
>> full-log-dir=/var/log/spamdyke
>> graylist-dir=/var/spamdyke/graylist
>> graylist-max-secs=2678400
>> graylist-min-secs=180
>> header-blacklist-entry=From:*>,*<*
>> idle-timeout-secs=600
>> ip-blacklist-file=/etc/spamdyke/blacklist_ip
>> ip-in-rdns-keyword-blacklist-file=/etc/spamdyke/blacklist_keywords
>> ip-in-rdns-keyword-whitelist-file=/etc/spamdyke/whitelist_keywords
>> ip-whitelist-file=/etc/spamdyke/whitelist_ip
>> log-level=info
>> max-recipients=100
>> rdns-blacklist-file=/etc/spamdyke/blacklist_rdns
>> rdns-whitelist-file=/etc/spamdyke/whitelist_rdns
>> recipient-blacklist-file=/etc/spamdyke/blacklist_recipients
>> recipient-whitelist-file=/etc/spamdyke/whitelist_recipients
>> reject-empty-rdns=1
>> reject-sender=no-mx
>> reject-sender=authentication-domain-mismatch
>> reject-unresolvable-rdns=1
>> relay-level=normal
>> sender-blacklist-file=/etc/spamdyke/blacklist_senders
>> sender-whitelist-file=/etc/spamdyke/whitelist_senders
>> tls-certificate-file=/var/qmail/control/servercert.pem
>>
>> 06/18/2019 19:32:54 - Remote IP = 40.107.69.126
>>
>> 06/18/2019 19:32:54 CURRENT CONFIG
>> config-file=/etc/spamdyke/spamdyke.conf
>> dns-blacklist-entry=zen.spamhaus.org
>> dns-server-ip-primary=8.8.8.8
>> full-log-dir=/var/log/spamdyke
>> graylist-dir=/var/spamdyke/graylist
>> graylist-max-secs=2678400
>> graylist-min-secs=180
>> header-blackl

Re: [qmailtoaster] TLS reason: 503_MAIL_first_(#5.5.1)

[Eric Broch]

In /etc/spamdyke/spamdyke.conf set 'tls-level' to 'none'.

tls-level=none

allow qmail to do the tls and see if it works.


On 6/18/2019 9:07 AM, Rajesh M wrote:

eric

in the spamdyke.conf i can see this
tls-certificate-file=/var/qmail/control/servercert.pem

also i am using the
/var/qmail/control/servercert.pem
for domain key signing of outgoing emails.

rajesh

- Original Message -
From: Eric Broch [mailto:ebr...@whitehorsetc.com]
To: qmailtoaster-list@qmailtoaster.com
Sent: Tue, 18 Jun 2019 08:52:13 -0600
Subject:

So you have spamdyke doing the TLS?

On 6/18/2019 8:38 AM, Rajesh M wrote:

Hi

ISSUE 1
all of a sudden we are receiving error on one of our servers for one specific 
sender domain (sending from microsoft server)

the sender domain is not able to send emails to the recepient domain on our 
server. The email bounces with the following error
encryption: TLS reason: 503_MAIL_first_(#5.5.1)

06/18/2019 19:33:16 LOG OUTPUT TLS
DENIED_OTHER from: rethish.n...@sender.com to: nominati...@dxb.recepient.com 
origin_ip: 40.107.69.126 origin_rdns: 
mail-eopbgr690126.outbound.protection.outlook.com auth: (unknown) encryption: 
TLS reason: 503_MAIL_first_(#5.5.1)
06/18/2019 19:33:16 FROM REMOTE TO CHILD: 6 bytes TLS
QUIT
06/18/2019 19:33:16 LOG OUTPUT TLS
ERROR(tls_write()@tls.c:678): unable to write to SSL/TLS stream: The operation 
failed due to an I/O error, Connection reset by peer
ERROR(output_writeln()@log.c:104): unable to write 27 bytes to file descriptor 
1: Connection reset by peer
06/18/2019 19:33:16 FROM CHILD TO REMOTE: 27 bytes TLS
221 ns1.HOSTNAME.com
06/18/2019 19:33:16 LOG OUTPUT TLS
ERROR(tls_read()@tls.c:620): unable to read from SSL/TLS stream: The operation 
failed due to an I/O error, Unexpected EOF found

06/18/2019 19:33:16 - TLS ended and closed


the error log of spamdyke  full-log-dir is give below follows


ISSUE 2
also i noted that spamdyke log mentions as such
reset address space soft limit to infinity: please stop using the softlimit 
program

What exactly does this mean. What is the alternative to prevent large files 
should i disable softlimit program in
/usr/bin/softlimit -m 6400 \
in the smtp run file

require your kind help in resolving the above 2 issues

thanks
rajesh

06/18/2019 19:32:54 STARTED: VERSION = 5.0.1+TLS+CONFIGTEST+DEBUG, PID = 19829

06/18/2019 19:32:54 CURRENT ENVIRONMENT
PATH=/var/qmail/bin:/usr/local/bin:/usr/bin:/bin
PWD=/var/qmail/supervise/smtp
SHLVL=0
PROTO=TCP
TCPLOCALIP=103.241.181.154
TCPLOCALPORT=25
TCPLOCALHOST=ns1.HOSTNAME.com
TCPREMOTEIP=40.107.69.126
TCPREMOTEPORT=42264
BADMIMETYPE=
BADLOADERTYPE=M
QMAILQUEUE=/var/qmail/bin/simscan
CHKUSER_START=ALWAYS
CHKUSER_RCPTLIMIT=50
CHKUSER_WRONGRCPTLIMIT=10
NOP0FCHECK=1
DKQUEUE=/var/qmail/bin/qmail-queue.orig
DKVERIFY=DEGIJKfh
DKSIGN=/var/qmail/control/domainkeys/%/private

06/18/2019 19:32:54 CURRENT CONFIG
config-file=/etc/spamdyke/spamdyke.conf
dns-blacklist-entry=zen.spamhaus.org
full-log-dir=/var/log/spamdyke
graylist-dir=/var/spamdyke/graylist
graylist-max-secs=2678400
graylist-min-secs=180
header-blacklist-entry=From:*>,*<*
idle-timeout-secs=600
ip-blacklist-file=/etc/spamdyke/blacklist_ip
ip-in-rdns-keyword-blacklist-file=/etc/spamdyke/blacklist_keywords
ip-in-rdns-keyword-whitelist-file=/etc/spamdyke/whitelist_keywords
ip-whitelist-file=/etc/spamdyke/whitelist_ip
log-level=info
max-recipients=100
rdns-blacklist-file=/etc/spamdyke/blacklist_rdns
rdns-whitelist-file=/etc/spamdyke/whitelist_rdns
recipient-blacklist-file=/etc/spamdyke/blacklist_recipients
recipient-whitelist-file=/etc/spamdyke/whitelist_recipients
reject-empty-rdns=1
reject-sender=no-mx
reject-sender=authentication-domain-mismatch
reject-unresolvable-rdns=1
relay-level=normal
sender-blacklist-file=/etc/spamdyke/blacklist_senders
sender-whitelist-file=/etc/spamdyke/whitelist_senders
tls-certificate-file=/var/qmail/control/servercert.pem

06/18/2019 19:32:54 - Remote IP = 40.107.69.126

06/18/2019 19:32:54 CURRENT CONFIG
config-file=/etc/spamdyke/spamdyke.conf
dns-blacklist-entry=zen.spamhaus.org
dns-server-ip-primary=8.8.8.8
full-log-dir=/var/log/spamdyke
graylist-dir=/var/spamdyke/graylist
graylist-max-secs=2678400
graylist-min-secs=180
header-blacklist-entry=From:*>,*<*
idle-timeout-secs=600
ip-blacklist-file=/etc/spamdyke/blacklist_ip
ip-in-rdns-keyword-blacklist-file=/etc/spamdyke/blacklist_keywords
ip-in-rdns-keyword-whitelist-file=/etc/spamdyke/whitelist_keywords
ip-whitelist-file=/etc/spamdyke/whitelist_ip
log-level=info
max-recipients=100
rdns-blacklist-file=/etc/spamdyke/blacklist_rdns
rdns-whitelist-file=/etc/spamdyke/whitelist_rdns
recipient-blacklist-file=/etc/spamdyke/blacklist_recipients
recipient-whitelist-file=/etc/spamdyke/whitelist_recipients
reject-empty-rdns=1
reject-sender=no-mx
reject-sender=authentication-domain-mismatch
reject-unresolvable-rdns=1
relay-level=normal
sender-blacklist-file=/etc/spamdyke/blacklist_senders
sender-whitelist-file=/etc/spamdyke/whitelist_senders
tls-certificate-file

Re: [qmailtoaster] TLS reason: 503_MAIL_first_(#5.5.1)

[Rajesh M]

eric

in the spamdyke.conf i can see this
tls-certificate-file=/var/qmail/control/servercert.pem

also i am using the
/var/qmail/control/servercert.pem
for domain key signing of outgoing emails.

rajesh

- Original Message -
From: Eric Broch [mailto:ebr...@whitehorsetc.com]
To: qmailtoaster-list@qmailtoaster.com
Sent: Tue, 18 Jun 2019 08:52:13 -0600
Subject:

So you have spamdyke doing the TLS?

On 6/18/2019 8:38 AM, Rajesh M wrote:
> Hi
>
> ISSUE 1
> all of a sudden we are receiving error on one of our servers for one specific 
> sender domain (sending from microsoft server)
>
> the sender domain is not able to send emails to the recepient domain on our 
> server. The email bounces with the following error
> encryption: TLS reason: 503_MAIL_first_(#5.5.1)
>
> 06/18/2019 19:33:16 LOG OUTPUT TLS
> DENIED_OTHER from: rethish.n...@sender.com to: nominati...@dxb.recepient.com 
> origin_ip: 40.107.69.126 origin_rdns: 
> mail-eopbgr690126.outbound.protection.outlook.com auth: (unknown) encryption: 
> TLS reason: 503_MAIL_first_(#5.5.1)
> 06/18/2019 19:33:16 FROM REMOTE TO CHILD: 6 bytes TLS
> QUIT
> 06/18/2019 19:33:16 LOG OUTPUT TLS
> ERROR(tls_write()@tls.c:678): unable to write to SSL/TLS stream: The 
> operation failed due to an I/O error, Connection reset by peer
> ERROR(output_writeln()@log.c:104): unable to write 27 bytes to file 
> descriptor 1: Connection reset by peer
> 06/18/2019 19:33:16 FROM CHILD TO REMOTE: 27 bytes TLS
> 221 ns1.HOSTNAME.com
> 06/18/2019 19:33:16 LOG OUTPUT TLS
> ERROR(tls_read()@tls.c:620): unable to read from SSL/TLS stream: The 
> operation failed due to an I/O error, Unexpected EOF found
>
> 06/18/2019 19:33:16 - TLS ended and closed
>
>
> the error log of spamdyke  full-log-dir is give below follows
>
>
> ISSUE 2
> also i noted that spamdyke log mentions as such
> reset address space soft limit to infinity: please stop using the softlimit 
> program
>
> What exactly does this mean. What is the alternative to prevent large files 
> should i disable softlimit program in
> /usr/bin/softlimit -m 6400 \
> in the smtp run file
>
> require your kind help in resolving the above 2 issues
>
> thanks
> rajesh
>
> 06/18/2019 19:32:54 STARTED: VERSION = 5.0.1+TLS+CONFIGTEST+DEBUG, PID = 19829
>
> 06/18/2019 19:32:54 CURRENT ENVIRONMENT
> PATH=/var/qmail/bin:/usr/local/bin:/usr/bin:/bin
> PWD=/var/qmail/supervise/smtp
> SHLVL=0
> PROTO=TCP
> TCPLOCALIP=103.241.181.154
> TCPLOCALPORT=25
> TCPLOCALHOST=ns1.HOSTNAME.com
> TCPREMOTEIP=40.107.69.126
> TCPREMOTEPORT=42264
> BADMIMETYPE=
> BADLOADERTYPE=M
> QMAILQUEUE=/var/qmail/bin/simscan
> CHKUSER_START=ALWAYS
> CHKUSER_RCPTLIMIT=50
> CHKUSER_WRONGRCPTLIMIT=10
> NOP0FCHECK=1
> DKQUEUE=/var/qmail/bin/qmail-queue.orig
> DKVERIFY=DEGIJKfh
> DKSIGN=/var/qmail/control/domainkeys/%/private
>
> 06/18/2019 19:32:54 CURRENT CONFIG
> config-file=/etc/spamdyke/spamdyke.conf
> dns-blacklist-entry=zen.spamhaus.org
> full-log-dir=/var/log/spamdyke
> graylist-dir=/var/spamdyke/graylist
> graylist-max-secs=2678400
> graylist-min-secs=180
> header-blacklist-entry=From:*>,*<*
> idle-timeout-secs=600
> ip-blacklist-file=/etc/spamdyke/blacklist_ip
> ip-in-rdns-keyword-blacklist-file=/etc/spamdyke/blacklist_keywords
> ip-in-rdns-keyword-whitelist-file=/etc/spamdyke/whitelist_keywords
> ip-whitelist-file=/etc/spamdyke/whitelist_ip
> log-level=info
> max-recipients=100
> rdns-blacklist-file=/etc/spamdyke/blacklist_rdns
> rdns-whitelist-file=/etc/spamdyke/whitelist_rdns
> recipient-blacklist-file=/etc/spamdyke/blacklist_recipients
> recipient-whitelist-file=/etc/spamdyke/whitelist_recipients
> reject-empty-rdns=1
> reject-sender=no-mx
> reject-sender=authentication-domain-mismatch
> reject-unresolvable-rdns=1
> relay-level=normal
> sender-blacklist-file=/etc/spamdyke/blacklist_senders
> sender-whitelist-file=/etc/spamdyke/whitelist_senders
> tls-certificate-file=/var/qmail/control/servercert.pem
>
> 06/18/2019 19:32:54 - Remote IP = 40.107.69.126
>
> 06/18/2019 19:32:54 CURRENT CONFIG
> config-file=/etc/spamdyke/spamdyke.conf
> dns-blacklist-entry=zen.spamhaus.org
> dns-server-ip-primary=8.8.8.8
> full-log-dir=/var/log/spamdyke
> graylist-dir=/var/spamdyke/graylist
> graylist-max-secs=2678400
> graylist-min-secs=180
> header-blacklist-entry=From:*>,*<*
> idle-timeout-secs=600
> ip-blacklist-file=/etc/spamdyke/blacklist_ip
> ip-in-rdns-keyword-blacklist-file=/etc/spamdyke/blacklist_keywords
> ip-in-rdns-keyword-whitelist-file=/etc/spamdyke/whitelist_keywords
> ip-whitelist-file=/etc/spamdyke/whitelist_ip
> log-level=info
> max-recipients=100
> rdns-blacklist-file=/etc/spamdyke/blacklist_rdns
> rdns-whitelist-file=/etc/spamdyke/whitelist_rdns
> recipient-blacklist-file=/etc/spamdyke/blacklist_recipients
> recipient-whitelist-file=/etc/spamdyke/whitelist_recipients
> reject-empty-rdns=1
> reject-sender=no-mx
> reject-sender=authentication-domain-mismatch
> reject-unresolvable-rdns=1
> relay-level=normal
> sender-blacklist-file=/etc/spamdyke/blacklist_senders

Re: [qmailtoaster] TLS reason: 503_MAIL_first_(#5.5.1)

[Eric Broch]

So you have spamdyke doing the TLS?

On 6/18/2019 8:38 AM, Rajesh M wrote:

Hi

ISSUE 1
all of a sudden we are receiving error on one of our servers for one specific 
sender domain (sending from microsoft server)

the sender domain is not able to send emails to the recepient domain on our 
server. The email bounces with the following error
encryption: TLS reason: 503_MAIL_first_(#5.5.1)

06/18/2019 19:33:16 LOG OUTPUT TLS
DENIED_OTHER from: rethish.n...@sender.com to: nominati...@dxb.recepient.com 
origin_ip: 40.107.69.126 origin_rdns: 
mail-eopbgr690126.outbound.protection.outlook.com auth: (unknown) encryption: 
TLS reason: 503_MAIL_first_(#5.5.1)
06/18/2019 19:33:16 FROM REMOTE TO CHILD: 6 bytes TLS
QUIT
06/18/2019 19:33:16 LOG OUTPUT TLS
ERROR(tls_write()@tls.c:678): unable to write to SSL/TLS stream: The operation 
failed due to an I/O error, Connection reset by peer
ERROR(output_writeln()@log.c:104): unable to write 27 bytes to file descriptor 
1: Connection reset by peer
06/18/2019 19:33:16 FROM CHILD TO REMOTE: 27 bytes TLS
221 ns1.HOSTNAME.com
06/18/2019 19:33:16 LOG OUTPUT TLS
ERROR(tls_read()@tls.c:620): unable to read from SSL/TLS stream: The operation 
failed due to an I/O error, Unexpected EOF found

06/18/2019 19:33:16 - TLS ended and closed


the error log of spamdyke  full-log-dir is give below follows


ISSUE 2
also i noted that spamdyke log mentions as such
reset address space soft limit to infinity: please stop using the softlimit 
program

What exactly does this mean. What is the alternative to prevent large files 
should i disable softlimit program in
/usr/bin/softlimit -m 6400 \
in the smtp run file

require your kind help in resolving the above 2 issues

thanks
rajesh

06/18/2019 19:32:54 STARTED: VERSION = 5.0.1+TLS+CONFIGTEST+DEBUG, PID = 19829

06/18/2019 19:32:54 CURRENT ENVIRONMENT
PATH=/var/qmail/bin:/usr/local/bin:/usr/bin:/bin
PWD=/var/qmail/supervise/smtp
SHLVL=0
PROTO=TCP
TCPLOCALIP=103.241.181.154
TCPLOCALPORT=25
TCPLOCALHOST=ns1.HOSTNAME.com
TCPREMOTEIP=40.107.69.126
TCPREMOTEPORT=42264
BADMIMETYPE=
BADLOADERTYPE=M
QMAILQUEUE=/var/qmail/bin/simscan
CHKUSER_START=ALWAYS
CHKUSER_RCPTLIMIT=50
CHKUSER_WRONGRCPTLIMIT=10
NOP0FCHECK=1
DKQUEUE=/var/qmail/bin/qmail-queue.orig
DKVERIFY=DEGIJKfh
DKSIGN=/var/qmail/control/domainkeys/%/private

06/18/2019 19:32:54 CURRENT CONFIG
config-file=/etc/spamdyke/spamdyke.conf
dns-blacklist-entry=zen.spamhaus.org
full-log-dir=/var/log/spamdyke
graylist-dir=/var/spamdyke/graylist
graylist-max-secs=2678400
graylist-min-secs=180
header-blacklist-entry=From:*>,*<*
idle-timeout-secs=600
ip-blacklist-file=/etc/spamdyke/blacklist_ip
ip-in-rdns-keyword-blacklist-file=/etc/spamdyke/blacklist_keywords
ip-in-rdns-keyword-whitelist-file=/etc/spamdyke/whitelist_keywords
ip-whitelist-file=/etc/spamdyke/whitelist_ip
log-level=info
max-recipients=100
rdns-blacklist-file=/etc/spamdyke/blacklist_rdns
rdns-whitelist-file=/etc/spamdyke/whitelist_rdns
recipient-blacklist-file=/etc/spamdyke/blacklist_recipients
recipient-whitelist-file=/etc/spamdyke/whitelist_recipients
reject-empty-rdns=1
reject-sender=no-mx
reject-sender=authentication-domain-mismatch
reject-unresolvable-rdns=1
relay-level=normal
sender-blacklist-file=/etc/spamdyke/blacklist_senders
sender-whitelist-file=/etc/spamdyke/whitelist_senders
tls-certificate-file=/var/qmail/control/servercert.pem

06/18/2019 19:32:54 - Remote IP = 40.107.69.126

06/18/2019 19:32:54 CURRENT CONFIG
config-file=/etc/spamdyke/spamdyke.conf
dns-blacklist-entry=zen.spamhaus.org
dns-server-ip-primary=8.8.8.8
full-log-dir=/var/log/spamdyke
graylist-dir=/var/spamdyke/graylist
graylist-max-secs=2678400
graylist-min-secs=180
header-blacklist-entry=From:*>,*<*
idle-timeout-secs=600
ip-blacklist-file=/etc/spamdyke/blacklist_ip
ip-in-rdns-keyword-blacklist-file=/etc/spamdyke/blacklist_keywords
ip-in-rdns-keyword-whitelist-file=/etc/spamdyke/whitelist_keywords
ip-whitelist-file=/etc/spamdyke/whitelist_ip
log-level=info
max-recipients=100
rdns-blacklist-file=/etc/spamdyke/blacklist_rdns
rdns-whitelist-file=/etc/spamdyke/whitelist_rdns
recipient-blacklist-file=/etc/spamdyke/blacklist_recipients
recipient-whitelist-file=/etc/spamdyke/whitelist_recipients
reject-empty-rdns=1
reject-sender=no-mx
reject-sender=authentication-domain-mismatch
reject-unresolvable-rdns=1
relay-level=normal
sender-blacklist-file=/etc/spamdyke/blacklist_senders
sender-whitelist-file=/etc/spamdyke/whitelist_senders
tls-certificate-file=/var/qmail/control/servercert.pem

06/18/2019 19:32:54 - Remote rDNS = 
mail-eopbgr690126.outbound.protection.outlook.com

06/18/2019 19:32:54 LOG OUTPUT
DEBUG(filter_rdns_missing()@filter.c:947): checking for missing rDNS; rdns: 
mail-eopbgr690126.outbound.protection.outlook.com
DEBUG(filter_rdns_whitelist_file()@filter.c:1055): searching rDNS whitelist 
file(s); rdns: mail-eopbgr690126.outbound.protection.outlook.com
DEBUG(filter_rdns_blacklist_file()@filter.c:1159): searching rDNS blacklist 
file(s); rdns: mail-eopbgr690126

Re: [qmailtoaster] TLS issue how to fix it

[Tommi Järvilehto]

Yeah all good thx.
Using the domainkey-enabled queue the queue crashed but that is not a 
problem. domain keys was not used.
Just needed to remember while upgrading all the servers to run the 
ln-command to disable the dkim again.


On 29.3.2019 1:26, Eric Broch wrote:

Tommi,

Did you get this resolved?

On 3/22/2019 3:54 AM, Tommi Järvilehto wrote:

I used this when upgraded the servers last year

openssl101e ciphers 'MEDIUM:HIGH:!SSLv2:!MD5:!RC4:!3DES' 
>/var/qmail/control/tlsserverciphers


Also I had to disable dkim support. It came back with the update
cd /var/qmail/bin
ln -sf qmail-queue.orig qmail-queue

The queue crashes. This is COS5 32bit


On 13.3.2019 17:29, Eric Broch wrote:
Thanks, Peter. I'll update the website. Sorry for the no response. I 
misplaced your email.


On 3/13/2019 9:13 AM, Peter Peltonen wrote:

Replying to myself:yes at least for me everything worked ok after
updating tlsserverciphers with command/usr/bin/openssl101e ciphers >
tlsserverciphersCheers,Peter
On Wed, Mar 6, 2019 at 3:58 PM Peter Peltonen 
 wrote:

Hi,

After upgrading COS5 openssl I still encounter these errors:

TLS connect failed: error:14077410:SSL
routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure;
connected to

Am I missing something, should I update also tlsserverciphers after
the openssl upgrade?

Best,
Peter

On Tue, Dec 11, 2018 at 9:05 AM Tommi Järvilehto
 wrote:

I can confirm that this upgrade does work.
On a 32bit COS5. Just needed to turn off domainkeys again. This 
upgrade

turned it on and crashes.


On 6.12.2018 17:11, Eric Broch wrote:

Upgrade:

https://www.qmailtoaster.org/newopensslcnt50.html

or

Turn off:

https://www.qmailtoaster.org/notls.html


On 12/5/2018 11:30 PM, Remo Mattei wrote:

Just want to add the is an old CentOS 5 box.

Remo


On Dec 5, 2018, at 22:24, Remo Mattei  wrote:

Any tips on the issue

TLS_connect_failed:_connection_reset;_connected_to_195.200.170.100./ 




Thanks

- 

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



--
Tommi Järvilehto
DataVahti Oy
040 732 8032


- 

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






--
__
Tommi Järvilehto
DataVahti OY
040 732 8032


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

Re: [qmailtoaster] TLS issue how to fix it

[Eric Broch]

Tommi,

Did you get this resolved?

On 3/22/2019 3:54 AM, Tommi Järvilehto wrote:

I used this when upgraded the servers last year

openssl101e ciphers 'MEDIUM:HIGH:!SSLv2:!MD5:!RC4:!3DES' 
>/var/qmail/control/tlsserverciphers


Also I had to disable dkim support. It came back with the update
cd /var/qmail/bin
ln -sf qmail-queue.orig qmail-queue

The queue crashes. This is COS5 32bit


On 13.3.2019 17:29, Eric Broch wrote:
Thanks, Peter. I'll update the website. Sorry for the no response. I 
misplaced your email.


On 3/13/2019 9:13 AM, Peter Peltonen wrote:

Replying to myself:yes at least for me everything worked ok after
updating tlsserverciphers with command/usr/bin/openssl101e ciphers >
tlsserverciphersCheers,Peter
On Wed, Mar 6, 2019 at 3:58 PM Peter Peltonen 
 wrote:

Hi,

After upgrading COS5 openssl I still encounter these errors:

TLS connect failed: error:14077410:SSL
routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure;
connected to

Am I missing something, should I update also tlsserverciphers after
the openssl upgrade?

Best,
Peter

On Tue, Dec 11, 2018 at 9:05 AM Tommi Järvilehto
 wrote:

I can confirm that this upgrade does work.
On a 32bit COS5. Just needed to turn off domainkeys again. This 
upgrade

turned it on and crashes.


On 6.12.2018 17:11, Eric Broch wrote:

Upgrade:

https://www.qmailtoaster.org/newopensslcnt50.html

or

Turn off:

https://www.qmailtoaster.org/notls.html


On 12/5/2018 11:30 PM, Remo Mattei wrote:

Just want to add the is an old CentOS 5 box.

Remo


On Dec 5, 2018, at 22:24, Remo Mattei  wrote:

Any tips on the issue

TLS_connect_failed:_connection_reset;_connected_to_195.200.170.100./ 




Thanks

- 

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



--
Tommi Järvilehto
DataVahti Oy
040 732 8032


-
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





--
Eric Broch
White Horse Technical Consulting (WHTC)


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

Re: [qmailtoaster] TLS issue how to fix it

[Tommi Järvilehto]

I used this when upgraded the servers last year

openssl101e ciphers 'MEDIUM:HIGH:!SSLv2:!MD5:!RC4:!3DES' 
>/var/qmail/control/tlsserverciphers


Also I had to disable dkim support. It came back with the update
cd /var/qmail/bin
ln -sf qmail-queue.orig qmail-queue

The queue crashes. This is COS5 32bit


On 13.3.2019 17:29, Eric Broch wrote:
Thanks, Peter. I'll update the website. Sorry for the no response. I 
misplaced your email.


On 3/13/2019 9:13 AM, Peter Peltonen wrote:

Replying to myself:yes at least for me everything worked ok after
updating tlsserverciphers with command/usr/bin/openssl101e ciphers >
tlsserverciphersCheers,Peter
On Wed, Mar 6, 2019 at 3:58 PM Peter Peltonen 
 wrote:

Hi,

After upgrading COS5 openssl I still encounter these errors:

TLS connect failed: error:14077410:SSL
routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure;
connected to

Am I missing something, should I update also tlsserverciphers after
the openssl upgrade?

Best,
Peter

On Tue, Dec 11, 2018 at 9:05 AM Tommi Järvilehto
 wrote:

I can confirm that this upgrade does work.
On a 32bit COS5. Just needed to turn off domainkeys again. This 
upgrade

turned it on and crashes.


On 6.12.2018 17:11, Eric Broch wrote:

Upgrade:

https://www.qmailtoaster.org/newopensslcnt50.html

or

Turn off:

https://www.qmailtoaster.org/notls.html


On 12/5/2018 11:30 PM, Remo Mattei wrote:

Just want to add the is an old CentOS 5 box.

Remo


On Dec 5, 2018, at 22:24, Remo Mattei  wrote:

Any tips on the issue

TLS_connect_failed:_connection_reset;_connected_to_195.200.170.100./ 




Thanks

- 

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



--
Tommi Järvilehto
DataVahti Oy
040 732 8032


-
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



--
__
Tommi Järvilehto
DataVahti OY
040 732 8032


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

Re: [qmailtoaster] TLS issue how to fix it

[Tommi Järvilehto]

Ok, mine was not original anymore. I had updated these sometimes before. 
When trying to test the servers with the Qualys SSL test.

Glad that you noticed this.

On 13.3.2019 17:13, Peter Peltonen wrote:

Replying to myself:yes at least for me everything worked ok after
updating tlsserverciphers with command/usr/bin/openssl101e ciphers >
tlsserverciphersCheers,Peter
On Wed, Mar 6, 2019 at 3:58 PM Peter Peltonen  wrote:

Hi,

After upgrading COS5 openssl I still encounter these errors:

TLS connect failed: error:14077410:SSL
routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure;
connected to

Am I missing something, should I update also tlsserverciphers after
the openssl upgrade?

Best,
Peter

On Tue, Dec 11, 2018 at 9:05 AM Tommi Järvilehto
 wrote:

I can confirm that this upgrade does work.
On a 32bit COS5. Just needed to turn off domainkeys again. This upgrade
turned it on and crashes.


On 6.12.2018 17:11, Eric Broch wrote:

Upgrade:

https://www.qmailtoaster.org/newopensslcnt50.html

or

Turn off:

https://www.qmailtoaster.org/notls.html


On 12/5/2018 11:30 PM, Remo Mattei wrote:

Just want to add the is an old CentOS 5 box.

Remo


On Dec 5, 2018, at 22:24, Remo Mattei  wrote:

Any tips on the issue

TLS_connect_failed:_connection_reset;_connected_to_195.200.170.100./


Thanks

-
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


--
Tommi Järvilehto
DataVahti Oy
040 732 8032


-
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



--
Tommi Järvilehto
DataVahti Oy
040 732 8032


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

Re: [qmailtoaster] TLS issue how to fix it

[Eric Broch]

Thanks, Peter. I'll update the website. Sorry for the no response. I 
misplaced your email.


On 3/13/2019 9:13 AM, Peter Peltonen wrote:

Replying to myself:yes at least for me everything worked ok after
updating tlsserverciphers with command/usr/bin/openssl101e ciphers >
tlsserverciphersCheers,Peter
On Wed, Mar 6, 2019 at 3:58 PM Peter Peltonen  wrote:

Hi,

After upgrading COS5 openssl I still encounter these errors:

TLS connect failed: error:14077410:SSL
routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure;
connected to

Am I missing something, should I update also tlsserverciphers after
the openssl upgrade?

Best,
Peter

On Tue, Dec 11, 2018 at 9:05 AM Tommi Järvilehto
 wrote:

I can confirm that this upgrade does work.
On a 32bit COS5. Just needed to turn off domainkeys again. This upgrade
turned it on and crashes.


On 6.12.2018 17:11, Eric Broch wrote:

Upgrade:

https://www.qmailtoaster.org/newopensslcnt50.html

or

Turn off:

https://www.qmailtoaster.org/notls.html


On 12/5/2018 11:30 PM, Remo Mattei wrote:

Just want to add the is an old CentOS 5 box.

Remo


On Dec 5, 2018, at 22:24, Remo Mattei  wrote:

Any tips on the issue

TLS_connect_failed:_connection_reset;_connected_to_195.200.170.100./


Thanks

-
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


--
Tommi Järvilehto
DataVahti Oy
040 732 8032


-
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


--
Eric Broch
White Horse Technical Consulting (WHTC)


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

Re: [qmailtoaster] TLS issue how to fix it

[Peter Peltonen]

Replying to myself:yes at least for me everything worked ok after
updating tlsserverciphers with command/usr/bin/openssl101e ciphers >
tlsserverciphersCheers,Peter
On Wed, Mar 6, 2019 at 3:58 PM Peter Peltonen  wrote:
>
> Hi,
>
> After upgrading COS5 openssl I still encounter these errors:
>
> TLS connect failed: error:14077410:SSL
> routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure;
> connected to
>
> Am I missing something, should I update also tlsserverciphers after
> the openssl upgrade?
>
> Best,
> Peter
>
> On Tue, Dec 11, 2018 at 9:05 AM Tommi Järvilehto
>  wrote:
> >
> > I can confirm that this upgrade does work.
> > On a 32bit COS5. Just needed to turn off domainkeys again. This upgrade
> > turned it on and crashes.
> >
> >
> > On 6.12.2018 17:11, Eric Broch wrote:
> > > Upgrade:
> > >
> > > https://www.qmailtoaster.org/newopensslcnt50.html
> > >
> > > or
> > >
> > > Turn off:
> > >
> > > https://www.qmailtoaster.org/notls.html
> > >
> > >
> > > On 12/5/2018 11:30 PM, Remo Mattei wrote:
> > >> Just want to add the is an old CentOS 5 box.
> > >>
> > >> Remo
> > >>
> > >>> On Dec 5, 2018, at 22:24, Remo Mattei  wrote:
> > >>>
> > >>> Any tips on the issue
> > >>>
> > >>> TLS_connect_failed:_connection_reset;_connected_to_195.200.170.100./
> > >>>
> > >>>
> > >>> Thanks
> > >>>
> > >>> -
> > >>> 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
> > >>
> >
> > --
> > Tommi Järvilehto
> > DataVahti Oy
> > 040 732 8032
> >
> >
> > -
> > 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] TLS issue how to fix it

[Peter Peltonen]

Hi,

After upgrading COS5 openssl I still encounter these errors:

TLS connect failed: error:14077410:SSL
routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure;
connected to

Am I missing something, should I update also tlsserverciphers after
the openssl upgrade?

Best,
Peter

On Tue, Dec 11, 2018 at 9:05 AM Tommi Järvilehto
 wrote:
>
> I can confirm that this upgrade does work.
> On a 32bit COS5. Just needed to turn off domainkeys again. This upgrade
> turned it on and crashes.
>
>
> On 6.12.2018 17:11, Eric Broch wrote:
> > Upgrade:
> >
> > https://www.qmailtoaster.org/newopensslcnt50.html
> >
> > or
> >
> > Turn off:
> >
> > https://www.qmailtoaster.org/notls.html
> >
> >
> > On 12/5/2018 11:30 PM, Remo Mattei wrote:
> >> Just want to add the is an old CentOS 5 box.
> >>
> >> Remo
> >>
> >>> On Dec 5, 2018, at 22:24, Remo Mattei  wrote:
> >>>
> >>> Any tips on the issue
> >>>
> >>> TLS_connect_failed:_connection_reset;_connected_to_195.200.170.100./
> >>>
> >>>
> >>> Thanks
> >>>
> >>> -
> >>> 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
> >>
>
> --
> Tommi Järvilehto
> DataVahti Oy
> 040 732 8032
>
>
> -
> 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] TLS issue how to fix it

[Tommi Järvilehto]

I can confirm that this upgrade does work.
On a 32bit COS5. Just needed to turn off domainkeys again. This upgrade 
turned it on and crashes.



On 6.12.2018 17:11, Eric Broch wrote:

Upgrade:

https://www.qmailtoaster.org/newopensslcnt50.html

or

Turn off:

https://www.qmailtoaster.org/notls.html


On 12/5/2018 11:30 PM, Remo Mattei wrote:

Just want to add the is an old CentOS 5 box.

Remo


On Dec 5, 2018, at 22:24, Remo Mattei  wrote:

Any tips on the issue

TLS_connect_failed:_connection_reset;_connected_to_195.200.170.100./


Thanks

-
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



--
Tommi Järvilehto
DataVahti Oy
040 732 8032


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

Re: [qmailtoaster] TLS issue how to fix it

[Remo Mattei]

That was the first thing I did but then I changed to use only that domain that 
was having issue. This installation is not part of qmailtoaster.. Too old! 


Remo 

> On Dec 6, 2018, at 14:25, Peter Peltonen  wrote:
> 
> Easiest for COS5 is to turn off TLS entirely for SMTP:
> 
> 1. create dir /var/qmail/control/tlshosts
> 
> 2. create file /var/qmail/control/tlshosts/exhaustivelist
> 
> If someone knows if this can cause any incompatibilities between any
> receiving servers, please share your experiences?
> 
> Best,
> Peter
> On Thu, Dec 6, 2018 at 5:11 PM Eric Broch  wrote:
>> 
>> Upgrade:
>> 
>> https://www.qmailtoaster.org/newopensslcnt50.html
>> 
>> or
>> 
>> Turn off:
>> 
>> https://www.qmailtoaster.org/notls.html
>> 
>> 
>> On 12/5/2018 11:30 PM, Remo Mattei wrote:
>>> Just want to add the is an old CentOS 5 box.
>>> 
>>> Remo
>>> 
 On Dec 5, 2018, at 22:24, Remo Mattei  wrote:
 
 Any tips on the issue
 
 TLS_connect_failed:_connection_reset;_connected_to_195.200.170.100./
 
 
 Thanks
 
 -
 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
>>> 
>> --
>> Eric Broch
>> White Horse Technical Consulting (WHTC)
>> 
>> 
>> -
>> 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
> 


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

Re: [qmailtoaster] TLS issue how to fix it

[Peter Peltonen]

Easiest for COS5 is to turn off TLS entirely for SMTP:

1. create dir /var/qmail/control/tlshosts

2. create file /var/qmail/control/tlshosts/exhaustivelist

If someone knows if this can cause any incompatibilities between any
receiving servers, please share your experiences?

Best,
Peter
On Thu, Dec 6, 2018 at 5:11 PM Eric Broch  wrote:
>
> Upgrade:
>
> https://www.qmailtoaster.org/newopensslcnt50.html
>
> or
>
> Turn off:
>
> https://www.qmailtoaster.org/notls.html
>
>
> On 12/5/2018 11:30 PM, Remo Mattei wrote:
> > Just want to add the is an old CentOS 5 box.
> >
> > Remo
> >
> >> On Dec 5, 2018, at 22:24, Remo Mattei  wrote:
> >>
> >> Any tips on the issue
> >>
> >> TLS_connect_failed:_connection_reset;_connected_to_195.200.170.100./
> >>
> >>
> >> Thanks
> >>
> >> -
> >> 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
> >
> --
> Eric Broch
> White Horse Technical Consulting (WHTC)
>
>
> -
> 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] TLS issue how to fix it

[Eric Broch]

Upgrade:

https://www.qmailtoaster.org/newopensslcnt50.html

or

Turn off:

https://www.qmailtoaster.org/notls.html


On 12/5/2018 11:30 PM, Remo Mattei wrote:

Just want to add the is an old CentOS 5 box.

Remo


On Dec 5, 2018, at 22:24, Remo Mattei  wrote:

Any tips on the issue

TLS_connect_failed:_connection_reset;_connected_to_195.200.170.100./


Thanks

-
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


--
Eric Broch
White Horse Technical Consulting (WHTC)


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

Re: [qmailtoaster] TLS issue how to fix it

[Jeff Koch]

The version of OpenSSL on CentOS 5 does not support the TLS protocol 
required by some of the ISPs. We have seen the same error and have been 
moving customer's email accounts to our CentOS 7 QMT7 box.


Jeff

On 12/6/2018 1:30 AM, Remo Mattei wrote:

Just want to add the is an old CentOS 5 box.

Remo


On Dec 5, 2018, at 22:24, Remo Mattei  wrote:

Any tips on the issue

TLS_connect_failed:_connection_reset;_connected_to_195.200.170.100./


Thanks

-
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] TLS issue how to fix it

[Remo Mattei]

Just want to add the is an old CentOS 5 box. 

Remo 

> On Dec 5, 2018, at 22:24, Remo Mattei  wrote:
> 
> Any tips on the issue 
> 
> TLS_connect_failed:_connection_reset;_connected_to_195.200.170.100./
> 
> 
> Thanks 
> 
> -
> 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] TLS on SMTP connection error

[Eric Broch]

I had this last week when one of my QMT servers was trying to connect to 
some office 365 host which didn't exist.


Get the IP address or MX hostname of the failed connection and try 
telneting to it manually...this is what I did...found out why there was 
a failed connection...no host.



On 6/3/2018 5:16 PM, Tony White wrote:

Hi folks,
  This is the first time I have received this error
and have no idea why I should be getting it.

deferral: TLS_connect_failed;_connected_to_

The recipient is telling me it is my email client that
cannot connect using the latest protocols. I am sure it
is not my email client but is it QMT having issues?
Has anyone seen this before please and hopefully I can
tell the recipient it is his server with the problem.

TIA :)
--
best wishes
   Tony White




--
Eric Broch
White Horse Technical Consulting (WHTC)

Re: [qmailtoaster] TLS Connection failures

[Sean Murphy]

And, Eric, just so you know, that solved the issue with those domains.  
I am in the logistical stage now of getting the upgrade going.  Wish me 
luck, I will report to the list with the results when I have managed to 
get it done.


Thanks again!

On 5/24/2018 11:15 AM, Sean Murphy wrote:
Yeah, I've talked about this with you before, and I have a server on 
standby, it's just a matter of the will to do it.



On 5/24/2018 11:13 AM, Eric Broch wrote:
I'm not sure that I had as many users on one of my hosts as you have 
but I did an upgrade from CentOS 5 to 7 and it was almost seamless.



On 5/24/2018 9:10 AM, Sean Murphy wrote:
Good. I know I've been putting this upgrade off, but as this machine 
is so reliable (and busy!), I've been reluctant to do the upgrade. 
This will get me off my duff, though.



On 5/24/2018 11:08 AM, Eric Broch wrote:

correct


On 5/24/2018 9:07 AM, Sean Murphy wrote:
Thanks, Eric.  So, as long as the domain in question accepts 
unencrypted email, this will work?


-Sean


On 5/24/2018 11:03 AM, Eric Broch wrote:

http://qmailtoaster.org/notls.html


On 5/24/2018 8:53 AM, Sean Murphy wrote:

Hello all,

I have begun to get TLS connection errors, and I am fairly 
certain that this is a version issue, as the mail servers we are 
connecting to seem to be using TLS 2.0, while we are still on 
the old qmailtoaster plus machine running on CentOS 5.  (I know, 
I need to upgrade!)


Is there anything I can do to mitigate this until I make the 
upgrade?  I plan on doing it soon but downtime is frowned upon.


Thanks,

Sean


- 

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







-
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




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

Re: [qmailtoaster] TLS Connection failures

[Sean Murphy]

Yeah, I've talked about this with you before, and I have a server on 
standby, it's just a matter of the will to do it.



On 5/24/2018 11:13 AM, Eric Broch wrote:
I'm not sure that I had as many users on one of my hosts as you have 
but I did an upgrade from CentOS 5 to 7 and it was almost seamless.



On 5/24/2018 9:10 AM, Sean Murphy wrote:
Good. I know I've been putting this upgrade off, but as this machine 
is so reliable (and busy!), I've been reluctant to do the upgrade. 
This will get me off my duff, though.



On 5/24/2018 11:08 AM, Eric Broch wrote:

correct


On 5/24/2018 9:07 AM, Sean Murphy wrote:
Thanks, Eric.  So, as long as the domain in question accepts 
unencrypted email, this will work?


-Sean


On 5/24/2018 11:03 AM, Eric Broch wrote:

http://qmailtoaster.org/notls.html


On 5/24/2018 8:53 AM, Sean Murphy wrote:

Hello all,

I have begun to get TLS connection errors, and I am fairly 
certain that this is a version issue, as the mail servers we are 
connecting to seem to be using TLS 2.0, while we are still on the 
old qmailtoaster plus machine running on CentOS 5.  (I know, I 
need to upgrade!)


Is there anything I can do to mitigate this until I make the 
upgrade?  I plan on doing it soon but downtime is frowned upon.


Thanks,

Sean


- 

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







-
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] TLS Connection failures

[Eric Broch]

I'm not sure that I had as many users on one of my hosts as you have but 
I did an upgrade from CentOS 5 to 7 and it was almost seamless.



On 5/24/2018 9:10 AM, Sean Murphy wrote:
Good. I know I've been putting this upgrade off, but as this machine 
is so reliable (and busy!), I've been reluctant to do the upgrade. 
This will get me off my duff, though.



On 5/24/2018 11:08 AM, Eric Broch wrote:

correct


On 5/24/2018 9:07 AM, Sean Murphy wrote:
Thanks, Eric.  So, as long as the domain in question accepts 
unencrypted email, this will work?


-Sean


On 5/24/2018 11:03 AM, Eric Broch wrote:

http://qmailtoaster.org/notls.html


On 5/24/2018 8:53 AM, Sean Murphy wrote:

Hello all,

I have begun to get TLS connection errors, and I am fairly certain 
that this is a version issue, as the mail servers we are 
connecting to seem to be using TLS 2.0, while we are still on the 
old qmailtoaster plus machine running on CentOS 5.  (I know, I 
need to upgrade!)


Is there anything I can do to mitigate this until I make the 
upgrade?  I plan on doing it soon but downtime is frowned upon.


Thanks,

Sean


-
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







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



--
Eric Broch
White Horse Technical Consulting (WHTC)


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

Re: [qmailtoaster] TLS Connection failures

[Sean Murphy]

Good.  I know I've been putting this upgrade off, but as this machine is 
so reliable (and busy!), I've been reluctant to do the upgrade.  This 
will get me off my duff, though.



On 5/24/2018 11:08 AM, Eric Broch wrote:

correct


On 5/24/2018 9:07 AM, Sean Murphy wrote:
Thanks, Eric.  So, as long as the domain in question accepts 
unencrypted email, this will work?


-Sean


On 5/24/2018 11:03 AM, Eric Broch wrote:

http://qmailtoaster.org/notls.html


On 5/24/2018 8:53 AM, Sean Murphy wrote:

Hello all,

I have begun to get TLS connection errors, and I am fairly certain 
that this is a version issue, as the mail servers we are connecting 
to seem to be using TLS 2.0, while we are still on the old 
qmailtoaster plus machine running on CentOS 5.  (I know, I need to 
upgrade!)


Is there anything I can do to mitigate this until I make the 
upgrade?  I plan on doing it soon but downtime is frowned upon.


Thanks,

Sean


-
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






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

Re: [qmailtoaster] TLS Connection failures

[Eric Broch]

correct


On 5/24/2018 9:07 AM, Sean Murphy wrote:
Thanks, Eric.  So, as long as the domain in question accepts 
unencrypted email, this will work?


-Sean


On 5/24/2018 11:03 AM, Eric Broch wrote:

http://qmailtoaster.org/notls.html


On 5/24/2018 8:53 AM, Sean Murphy wrote:

Hello all,

I have begun to get TLS connection errors, and I am fairly certain 
that this is a version issue, as the mail servers we are connecting 
to seem to be using TLS 2.0, while we are still on the old 
qmailtoaster plus machine running on CentOS 5.  (I know, I need to 
upgrade!)


Is there anything I can do to mitigate this until I make the 
upgrade?  I plan on doing it soon but downtime is frowned upon.


Thanks,

Sean


-
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



--
Eric Broch
White Horse Technical Consulting (WHTC)


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

Re: [qmailtoaster] TLS Connection failures

[Sean Murphy]

Thanks, Eric.  So, as long as the domain in question accepts unencrypted 
email, this will work?


-Sean


On 5/24/2018 11:03 AM, Eric Broch wrote:

http://qmailtoaster.org/notls.html


On 5/24/2018 8:53 AM, Sean Murphy wrote:

Hello all,

I have begun to get TLS connection errors, and I am fairly certain 
that this is a version issue, as the mail servers we are connecting 
to seem to be using TLS 2.0, while we are still on the old 
qmailtoaster plus machine running on CentOS 5.  (I know, I need to 
upgrade!)


Is there anything I can do to mitigate this until I make the 
upgrade?  I plan on doing it soon but downtime is frowned upon.


Thanks,

Sean


-
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] TLS Connection failures

[Eric Broch]

http://qmailtoaster.org/notls.html


On 5/24/2018 8:53 AM, Sean Murphy wrote:

Hello all,

I have begun to get TLS connection errors, and I am fairly certain 
that this is a version issue, as the mail servers we are connecting to 
seem to be using TLS 2.0, while we are still on the old qmailtoaster 
plus machine running on CentOS 5.  (I know, I need to upgrade!)


Is there anything I can do to mitigate this until I make the upgrade?  
I plan on doing it soon but downtime is frowned upon.


Thanks,

Sean


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



--
Eric Broch
White Horse Technical Consulting (WHTC)


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

Re: [qmailtoaster] TLS connect failed: timed out

[Rajesh M]

eric

that is what is did.
first stop  wait for a minute and then start.

rajesh

- Original Message -
From: Eric Broch [mailto:ebr...@whitehorsetc.com]
To: qmailtoaster-list@qmailtoaster.com
Sent: Tue, 4 Apr 2017 08:35:13 -0600
Subject:

There is a difference between restart and stop/start. Try a stop/start.


On 4/4/2017 8:33 AM, Rajesh M wrote:
> eric
>
> yes, i restarted qmail.
>
> rajesh
>
> - Original Message -
> From: Eric Broch [mailto:ebr...@whitehorsetc.com]
> To: qmailtoaster-list@qmailtoaster.com
> Sent: Tue, 4 Apr 2017 06:14:59 -0600
> Subject:
>
> Rajesh,
>
> Did you (restart)
>
> # qmailctl restart
>
> or
>
> (stop/start)
>
> # qmailctl stop
>
> # qmailctl start
>
> ?
>
> Eric
>
>
> On 4/4/2017 12:13 AM, Rajesh M wrote:
>> eric
>>
>> here are the details
>>
>> [root@ns1 control]# openssl version
>> OpenSSL 1.0.1e-fips 11 Feb 2013
>>
>> [root@ns1 control]# openssl s_client -starttls smtp  -no_ssl3 -no_ssl2 
>> -cipher "AES256-SHA" -debug -msg -connect mx01.emas.dbschenker.com:25
>> CONNECTED(0003)
>> read from 0x1777e10 [0x17b9ae0] (4096 bytes => 75 (0x4B))
>>  - 32 32 30 20 6d 74 61 31-31 2e 65 6d 61 73 2e 64   220 mta11.emas.d
>> 0010 - 62 73 63 68 65 6e 6b 65-72 2e 63 6f 6d 20 45 53   bschenker.com ES
>> 0020 - 4d 54 50 20 53 6d 74 70-64 3b 20 54 75 65 2c 20   MTP Smtpd; Tue,
>> 0030 - 34 20 41 70 72 20 32 30-31 37 20 30 38 3a 31 32   4 Apr 2017 08:12
>> 0040 - 3a 33 30 20 2b 30 32 30-30 0d 0a  :30 +0200..
>> write to 0x1777e10 [0x17baaf0] (25 bytes => 25 (0x19))
>>  - 45 48 4c 4f 20 6f 70 65-6e 73 73 6c 2e 63 6c 69   EHLO openssl.cli
>> 0010 - 65 6e 74 2e 6e 65 74 0d-0aent.net..
>> read from 0x1777e10 [0x17b9ae0] (4096 bytes => 230 (0xE6))
>>  - 32 35 30 2d 6d 74 61 31-31 2e 65 6d 61 73 2e 64   250-mta11.emas.d
>> 0010 - 62 73 63 68 65 6e 6b 65-72 2e 63 6f 6d 20 48 65   bschenker.com He
>> 0020 - 6c 6c 6f 20 6e 73 31 2e-61 61 61 6f 6e 6c 69 6e   llo ns1.aaaonlin
>> 0030 - 75 78 2e 63 6f 6d 20 5b-31 30 33 2e 32 34 31 2e   ux.com [103.241.
>> 0040 - 31 38 31 2e 31 33 37 5d-2c 20 70 6c 65 61 73 65   181.137], please
>> 0050 - 64 20 74 6f 20 6d 65 65-74 20 79 6f 75 0d 0a 32   d to meet you..2
>> 0060 - 35 30 2d 45 4e 48 41 4e-43 45 44 53 54 41 54 55   50-ENHANCEDSTATU
>> 0070 - 53 43 4f 44 45 53 0d 0a-32 35 30 2d 50 49 50 45   SCODES..250-PIPE
>> 0080 - 4c 49 4e 49 4e 47 0d 0a-32 35 30 2d 38 42 49 54   LINING..250-8BIT
>> 0090 - 4d 49 4d 45 0d 0a 32 35-30 2d 53 49 5a 45 20 32   MIME..250-SIZE 2
>> 00a0 - 36 32 31 34 34 30 30 0d-0a 32 35 30 2d 41 55 54   6214400..250-AUT
>> 00b0 - 48 20 4c 4f 47 49 4e 20-50 4c 41 49 4e 0d 0a 32   H LOGIN PLAIN..2
>> 00c0 - 35 30 2d 53 54 41 52 54-54 4c 53 0d 0a 32 35 30   50-STARTTLS..250
>> 00d0 - 2d 44 45 4c 49 56 45 52-42 59 0d 0a 32 35 30 20   -DELIVERBY..250
>> 00e0 - 48 45 4c 50 0d 0a HELP..
>> write to 0x1777e10 [0x7ffd0b0c4880] (10 bytes => 10 (0xA))
>>  - 53 54 41 52 54 54 4c 53-0d 0a STARTTLS..
>> read from 0x1777e10 [0x16aad00] (8192 bytes => 30 (0x1E))
>>  - 32 32 30 20 32 2e 30 2e-30 20 52 65 61 64 79 20   220 2.0.0 Ready
>> 0010 - 74 6f 20 73 74 61 72 74-20 54 4c 53 0d 0a to start TLS..
>> write to 0x1777e10 [0x17b9ae0] (99 bytes => 99 (0x63))
>>  - 16 03 01 00 5e 01 00 00-5a 03 03 58 e3 38 52 5c   ^...Z..X.8R\
>> 0010 - d3 37 8b 23 86 92 e6 63-2f e7 dd f9 ed 42 df 2b   .7.#...c/B.+
>> 0020 - 45 51 06 1e f2 f3 38 b1-36 c7 d4 00 00 04 00 35   EQ8.6..5
>> 0030 - 00 ff 01 00 00 2d 00 23-00 00 00 0d 00 20 00 1e   .-.#. ..
>> 0040 - 06 01 06 02 06 03 05 01-05 02 05 03 04 01 04 02   
>> 0050 - 04 03 03 01 03 02 03 03-02 01 02 02 02 03 00 0f   
>> 0060 - 00 01 01  ...
> TLS 1.2 Handshake [length 005e], ClientHello
>>   01 00 00 5a 03 03 58 e3 38 52 5c d3 37 8b 23 86
>>   92 e6 63 2f e7 dd f9 ed 42 df 2b 45 51 06 1e f2
>>   f3 38 b1 36 c7 d4 00 00 04 00 35 00 ff 01 00 00
>>   2d 00 23 00 00 00 0d 00 20 00 1e 06 01 06 02 06
>>   03 05 01 05 02 05 03 04 01 04 02 04 03 03 01 03
>>   02 03 03 02 01 02 02 02 03 00 0f 00 01 01
>>
>>
>> thank you,
>> rajesh
>>
>> - Original Message -
>> From: Eric Broch [mailto:ebr...@whitehorsetc.com]
>> To: qmailtoaster-list@qmailtoaster.com
>> Sent: Tue, 4 Apr 2017 00:09:04 -0600
>> Subject:
>>
>> Also run command with -debug and -msg options in red below.
>>
>> # openssl s_client -starttls smtp  -no_ssl3 -no_ssl2 -cipher
>> "AES256-SHA" -debug -msg -connect mx01.emas.dbschenker.com:25
>>
>>
>> On 4/4/2017 12:03 AM, Eric Broch wrote:
>>> Rajesh,
>>>
>>> Please disregard my last question (Does it connect and get full cert
>>> details if you use IP address?).
>>>
>>> "here too, the issue is server side. My mail server is not able to
>>> connect to the mail server of hpe.com and send the emails of my clients"
>>>
>>> Your server is acting as a client in

Re: [qmailtoaster] TLS connect failed: timed out

[Eric Broch]

There is a difference between restart and stop/start. Try a stop/start.


On 4/4/2017 8:33 AM, Rajesh M wrote:

eric

yes, i restarted qmail.

rajesh

- Original Message -
From: Eric Broch [mailto:ebr...@whitehorsetc.com]
To: qmailtoaster-list@qmailtoaster.com
Sent: Tue, 4 Apr 2017 06:14:59 -0600
Subject:

Rajesh,

Did you (restart)

# qmailctl restart

or

(stop/start)

# qmailctl stop

# qmailctl start

?

Eric


On 4/4/2017 12:13 AM, Rajesh M wrote:

eric

here are the details

[root@ns1 control]# openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013

[root@ns1 control]# openssl s_client -starttls smtp  -no_ssl3 -no_ssl2 -cipher 
"AES256-SHA" -debug -msg -connect mx01.emas.dbschenker.com:25
CONNECTED(0003)
read from 0x1777e10 [0x17b9ae0] (4096 bytes => 75 (0x4B))
 - 32 32 30 20 6d 74 61 31-31 2e 65 6d 61 73 2e 64   220 mta11.emas.d
0010 - 62 73 63 68 65 6e 6b 65-72 2e 63 6f 6d 20 45 53   bschenker.com ES
0020 - 4d 54 50 20 53 6d 74 70-64 3b 20 54 75 65 2c 20   MTP Smtpd; Tue,
0030 - 34 20 41 70 72 20 32 30-31 37 20 30 38 3a 31 32   4 Apr 2017 08:12
0040 - 3a 33 30 20 2b 30 32 30-30 0d 0a  :30 +0200..
write to 0x1777e10 [0x17baaf0] (25 bytes => 25 (0x19))
 - 45 48 4c 4f 20 6f 70 65-6e 73 73 6c 2e 63 6c 69   EHLO openssl.cli
0010 - 65 6e 74 2e 6e 65 74 0d-0aent.net..
read from 0x1777e10 [0x17b9ae0] (4096 bytes => 230 (0xE6))
 - 32 35 30 2d 6d 74 61 31-31 2e 65 6d 61 73 2e 64   250-mta11.emas.d
0010 - 62 73 63 68 65 6e 6b 65-72 2e 63 6f 6d 20 48 65   bschenker.com He
0020 - 6c 6c 6f 20 6e 73 31 2e-61 61 61 6f 6e 6c 69 6e   llo ns1.aaaonlin
0030 - 75 78 2e 63 6f 6d 20 5b-31 30 33 2e 32 34 31 2e   ux.com [103.241.
0040 - 31 38 31 2e 31 33 37 5d-2c 20 70 6c 65 61 73 65   181.137], please
0050 - 64 20 74 6f 20 6d 65 65-74 20 79 6f 75 0d 0a 32   d to meet you..2
0060 - 35 30 2d 45 4e 48 41 4e-43 45 44 53 54 41 54 55   50-ENHANCEDSTATU
0070 - 53 43 4f 44 45 53 0d 0a-32 35 30 2d 50 49 50 45   SCODES..250-PIPE
0080 - 4c 49 4e 49 4e 47 0d 0a-32 35 30 2d 38 42 49 54   LINING..250-8BIT
0090 - 4d 49 4d 45 0d 0a 32 35-30 2d 53 49 5a 45 20 32   MIME..250-SIZE 2
00a0 - 36 32 31 34 34 30 30 0d-0a 32 35 30 2d 41 55 54   6214400..250-AUT
00b0 - 48 20 4c 4f 47 49 4e 20-50 4c 41 49 4e 0d 0a 32   H LOGIN PLAIN..2
00c0 - 35 30 2d 53 54 41 52 54-54 4c 53 0d 0a 32 35 30   50-STARTTLS..250
00d0 - 2d 44 45 4c 49 56 45 52-42 59 0d 0a 32 35 30 20   -DELIVERBY..250
00e0 - 48 45 4c 50 0d 0a HELP..
write to 0x1777e10 [0x7ffd0b0c4880] (10 bytes => 10 (0xA))
 - 53 54 41 52 54 54 4c 53-0d 0a STARTTLS..
read from 0x1777e10 [0x16aad00] (8192 bytes => 30 (0x1E))
 - 32 32 30 20 32 2e 30 2e-30 20 52 65 61 64 79 20   220 2.0.0 Ready
0010 - 74 6f 20 73 74 61 72 74-20 54 4c 53 0d 0a to start TLS..
write to 0x1777e10 [0x17b9ae0] (99 bytes => 99 (0x63))
 - 16 03 01 00 5e 01 00 00-5a 03 03 58 e3 38 52 5c   ^...Z..X.8R\
0010 - d3 37 8b 23 86 92 e6 63-2f e7 dd f9 ed 42 df 2b   .7.#...c/B.+
0020 - 45 51 06 1e f2 f3 38 b1-36 c7 d4 00 00 04 00 35   EQ8.6..5
0030 - 00 ff 01 00 00 2d 00 23-00 00 00 0d 00 20 00 1e   .-.#. ..
0040 - 06 01 06 02 06 03 05 01-05 02 05 03 04 01 04 02   
0050 - 04 03 03 01 03 02 03 03-02 01 02 02 02 03 00 0f   
0060 - 00 01 01  ...

TLS 1.2 Handshake [length 005e], ClientHello

  01 00 00 5a 03 03 58 e3 38 52 5c d3 37 8b 23 86
  92 e6 63 2f e7 dd f9 ed 42 df 2b 45 51 06 1e f2
  f3 38 b1 36 c7 d4 00 00 04 00 35 00 ff 01 00 00
  2d 00 23 00 00 00 0d 00 20 00 1e 06 01 06 02 06
  03 05 01 05 02 05 03 04 01 04 02 04 03 03 01 03
  02 03 03 02 01 02 02 02 03 00 0f 00 01 01


thank you,
rajesh

- Original Message -
From: Eric Broch [mailto:ebr...@whitehorsetc.com]
To: qmailtoaster-list@qmailtoaster.com
Sent: Tue, 4 Apr 2017 00:09:04 -0600
Subject:

Also run command with -debug and -msg options in red below.

# openssl s_client -starttls smtp  -no_ssl3 -no_ssl2 -cipher
"AES256-SHA" -debug -msg -connect mx01.emas.dbschenker.com:25


On 4/4/2017 12:03 AM, Eric Broch wrote:

Rajesh,

Please disregard my last question (Does it connect and get full cert
details if you use IP address?).

"here too, the issue is server side. My mail server is not able to
connect to the mail server of hpe.com and send the emails of my clients"

Your server is acting as a client in this case by initiating a TLS
connection to the domains in question...to deliver mail, correct? Do
you have settings in one of your control files to initiate TLS
connections with certain domains?

"openssl s_client -starttls smtp -no_ssl3 -no_ssl2 -cipher
"AES256-SHA" -connect mx01.emas.dbschenker.com:25"

This command works from my COS6 and COS7 hosts. So I don't think it's
on their end.

which openssl version are you running?

Eric



-
To unsubscribe, e-mail: qmai

Re: [qmailtoaster] TLS connect failed: timed out

[Rajesh M]

eric

yes, i restarted qmail.

rajesh

- Original Message -
From: Eric Broch [mailto:ebr...@whitehorsetc.com]
To: qmailtoaster-list@qmailtoaster.com
Sent: Tue, 4 Apr 2017 06:14:59 -0600
Subject:

Rajesh,

Did you (restart)

# qmailctl restart

or

(stop/start)

# qmailctl stop

# qmailctl start

?

Eric


On 4/4/2017 12:13 AM, Rajesh M wrote:
> eric
>
> here are the details
>
> [root@ns1 control]# openssl version
> OpenSSL 1.0.1e-fips 11 Feb 2013
>
> [root@ns1 control]# openssl s_client -starttls smtp  -no_ssl3 -no_ssl2 
> -cipher "AES256-SHA" -debug -msg -connect mx01.emas.dbschenker.com:25
> CONNECTED(0003)
> read from 0x1777e10 [0x17b9ae0] (4096 bytes => 75 (0x4B))
>  - 32 32 30 20 6d 74 61 31-31 2e 65 6d 61 73 2e 64   220 mta11.emas.d
> 0010 - 62 73 63 68 65 6e 6b 65-72 2e 63 6f 6d 20 45 53   bschenker.com ES
> 0020 - 4d 54 50 20 53 6d 74 70-64 3b 20 54 75 65 2c 20   MTP Smtpd; Tue,
> 0030 - 34 20 41 70 72 20 32 30-31 37 20 30 38 3a 31 32   4 Apr 2017 08:12
> 0040 - 3a 33 30 20 2b 30 32 30-30 0d 0a  :30 +0200..
> write to 0x1777e10 [0x17baaf0] (25 bytes => 25 (0x19))
>  - 45 48 4c 4f 20 6f 70 65-6e 73 73 6c 2e 63 6c 69   EHLO openssl.cli
> 0010 - 65 6e 74 2e 6e 65 74 0d-0aent.net..
> read from 0x1777e10 [0x17b9ae0] (4096 bytes => 230 (0xE6))
>  - 32 35 30 2d 6d 74 61 31-31 2e 65 6d 61 73 2e 64   250-mta11.emas.d
> 0010 - 62 73 63 68 65 6e 6b 65-72 2e 63 6f 6d 20 48 65   bschenker.com He
> 0020 - 6c 6c 6f 20 6e 73 31 2e-61 61 61 6f 6e 6c 69 6e   llo ns1.aaaonlin
> 0030 - 75 78 2e 63 6f 6d 20 5b-31 30 33 2e 32 34 31 2e   ux.com [103.241.
> 0040 - 31 38 31 2e 31 33 37 5d-2c 20 70 6c 65 61 73 65   181.137], please
> 0050 - 64 20 74 6f 20 6d 65 65-74 20 79 6f 75 0d 0a 32   d to meet you..2
> 0060 - 35 30 2d 45 4e 48 41 4e-43 45 44 53 54 41 54 55   50-ENHANCEDSTATU
> 0070 - 53 43 4f 44 45 53 0d 0a-32 35 30 2d 50 49 50 45   SCODES..250-PIPE
> 0080 - 4c 49 4e 49 4e 47 0d 0a-32 35 30 2d 38 42 49 54   LINING..250-8BIT
> 0090 - 4d 49 4d 45 0d 0a 32 35-30 2d 53 49 5a 45 20 32   MIME..250-SIZE 2
> 00a0 - 36 32 31 34 34 30 30 0d-0a 32 35 30 2d 41 55 54   6214400..250-AUT
> 00b0 - 48 20 4c 4f 47 49 4e 20-50 4c 41 49 4e 0d 0a 32   H LOGIN PLAIN..2
> 00c0 - 35 30 2d 53 54 41 52 54-54 4c 53 0d 0a 32 35 30   50-STARTTLS..250
> 00d0 - 2d 44 45 4c 49 56 45 52-42 59 0d 0a 32 35 30 20   -DELIVERBY..250
> 00e0 - 48 45 4c 50 0d 0a HELP..
> write to 0x1777e10 [0x7ffd0b0c4880] (10 bytes => 10 (0xA))
>  - 53 54 41 52 54 54 4c 53-0d 0a STARTTLS..
> read from 0x1777e10 [0x16aad00] (8192 bytes => 30 (0x1E))
>  - 32 32 30 20 32 2e 30 2e-30 20 52 65 61 64 79 20   220 2.0.0 Ready
> 0010 - 74 6f 20 73 74 61 72 74-20 54 4c 53 0d 0a to start TLS..
> write to 0x1777e10 [0x17b9ae0] (99 bytes => 99 (0x63))
>  - 16 03 01 00 5e 01 00 00-5a 03 03 58 e3 38 52 5c   ^...Z..X.8R\
> 0010 - d3 37 8b 23 86 92 e6 63-2f e7 dd f9 ed 42 df 2b   .7.#...c/B.+
> 0020 - 45 51 06 1e f2 f3 38 b1-36 c7 d4 00 00 04 00 35   EQ8.6..5
> 0030 - 00 ff 01 00 00 2d 00 23-00 00 00 0d 00 20 00 1e   .-.#. ..
> 0040 - 06 01 06 02 06 03 05 01-05 02 05 03 04 01 04 02   
> 0050 - 04 03 03 01 03 02 03 03-02 01 02 02 02 03 00 0f   
> 0060 - 00 01 01  ...
 TLS 1.2 Handshake [length 005e], ClientHello
>  01 00 00 5a 03 03 58 e3 38 52 5c d3 37 8b 23 86
>  92 e6 63 2f e7 dd f9 ed 42 df 2b 45 51 06 1e f2
>  f3 38 b1 36 c7 d4 00 00 04 00 35 00 ff 01 00 00
>  2d 00 23 00 00 00 0d 00 20 00 1e 06 01 06 02 06
>  03 05 01 05 02 05 03 04 01 04 02 04 03 03 01 03
>  02 03 03 02 01 02 02 02 03 00 0f 00 01 01
>
>
> thank you,
> rajesh
>
> - Original Message -
> From: Eric Broch [mailto:ebr...@whitehorsetc.com]
> To: qmailtoaster-list@qmailtoaster.com
> Sent: Tue, 4 Apr 2017 00:09:04 -0600
> Subject:
>
> Also run command with -debug and -msg options in red below.
>
> # openssl s_client -starttls smtp  -no_ssl3 -no_ssl2 -cipher
> "AES256-SHA" -debug -msg -connect mx01.emas.dbschenker.com:25
>
>
> On 4/4/2017 12:03 AM, Eric Broch wrote:
>> Rajesh,
>>
>> Please disregard my last question (Does it connect and get full cert
>> details if you use IP address?).
>>
>> "here too, the issue is server side. My mail server is not able to
>> connect to the mail server of hpe.com and send the emails of my clients"
>>
>> Your server is acting as a client in this case by initiating a TLS
>> connection to the domains in question...to deliver mail, correct? Do
>> you have settings in one of your control files to initiate TLS
>> connections with certain domains?
>>
>> "openssl s_client -starttls smtp -no_ssl3 -no_ssl2 -cipher
>> "AES256-SHA" -connect mx01.emas.dbschenker.com:25"
>>
>> This command works from my COS6 and COS7 hosts. So I don't think it's
>> on their end.
>>
>> which openssl version are you running?
>>
>> Eric
>>
>
>
> -

Re: [qmailtoaster] TLS connect failed: timed out

[Eric Broch]

Rajesh,

Did you (restart)

# qmailctl restart

or

(stop/start)

# qmailctl stop

# qmailctl start

?

Eric


On 4/4/2017 12:13 AM, Rajesh M wrote:

eric

here are the details

[root@ns1 control]# openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013

[root@ns1 control]# openssl s_client -starttls smtp  -no_ssl3 -no_ssl2 -cipher 
"AES256-SHA" -debug -msg -connect mx01.emas.dbschenker.com:25
CONNECTED(0003)
read from 0x1777e10 [0x17b9ae0] (4096 bytes => 75 (0x4B))
 - 32 32 30 20 6d 74 61 31-31 2e 65 6d 61 73 2e 64   220 mta11.emas.d
0010 - 62 73 63 68 65 6e 6b 65-72 2e 63 6f 6d 20 45 53   bschenker.com ES
0020 - 4d 54 50 20 53 6d 74 70-64 3b 20 54 75 65 2c 20   MTP Smtpd; Tue,
0030 - 34 20 41 70 72 20 32 30-31 37 20 30 38 3a 31 32   4 Apr 2017 08:12
0040 - 3a 33 30 20 2b 30 32 30-30 0d 0a  :30 +0200..
write to 0x1777e10 [0x17baaf0] (25 bytes => 25 (0x19))
 - 45 48 4c 4f 20 6f 70 65-6e 73 73 6c 2e 63 6c 69   EHLO openssl.cli
0010 - 65 6e 74 2e 6e 65 74 0d-0aent.net..
read from 0x1777e10 [0x17b9ae0] (4096 bytes => 230 (0xE6))
 - 32 35 30 2d 6d 74 61 31-31 2e 65 6d 61 73 2e 64   250-mta11.emas.d
0010 - 62 73 63 68 65 6e 6b 65-72 2e 63 6f 6d 20 48 65   bschenker.com He
0020 - 6c 6c 6f 20 6e 73 31 2e-61 61 61 6f 6e 6c 69 6e   llo ns1.aaaonlin
0030 - 75 78 2e 63 6f 6d 20 5b-31 30 33 2e 32 34 31 2e   ux.com [103.241.
0040 - 31 38 31 2e 31 33 37 5d-2c 20 70 6c 65 61 73 65   181.137], please
0050 - 64 20 74 6f 20 6d 65 65-74 20 79 6f 75 0d 0a 32   d to meet you..2
0060 - 35 30 2d 45 4e 48 41 4e-43 45 44 53 54 41 54 55   50-ENHANCEDSTATU
0070 - 53 43 4f 44 45 53 0d 0a-32 35 30 2d 50 49 50 45   SCODES..250-PIPE
0080 - 4c 49 4e 49 4e 47 0d 0a-32 35 30 2d 38 42 49 54   LINING..250-8BIT
0090 - 4d 49 4d 45 0d 0a 32 35-30 2d 53 49 5a 45 20 32   MIME..250-SIZE 2
00a0 - 36 32 31 34 34 30 30 0d-0a 32 35 30 2d 41 55 54   6214400..250-AUT
00b0 - 48 20 4c 4f 47 49 4e 20-50 4c 41 49 4e 0d 0a 32   H LOGIN PLAIN..2
00c0 - 35 30 2d 53 54 41 52 54-54 4c 53 0d 0a 32 35 30   50-STARTTLS..250
00d0 - 2d 44 45 4c 49 56 45 52-42 59 0d 0a 32 35 30 20   -DELIVERBY..250
00e0 - 48 45 4c 50 0d 0a HELP..
write to 0x1777e10 [0x7ffd0b0c4880] (10 bytes => 10 (0xA))
 - 53 54 41 52 54 54 4c 53-0d 0a STARTTLS..
read from 0x1777e10 [0x16aad00] (8192 bytes => 30 (0x1E))
 - 32 32 30 20 32 2e 30 2e-30 20 52 65 61 64 79 20   220 2.0.0 Ready
0010 - 74 6f 20 73 74 61 72 74-20 54 4c 53 0d 0a to start TLS..
write to 0x1777e10 [0x17b9ae0] (99 bytes => 99 (0x63))
 - 16 03 01 00 5e 01 00 00-5a 03 03 58 e3 38 52 5c   ^...Z..X.8R\
0010 - d3 37 8b 23 86 92 e6 63-2f e7 dd f9 ed 42 df 2b   .7.#...c/B.+
0020 - 45 51 06 1e f2 f3 38 b1-36 c7 d4 00 00 04 00 35   EQ8.6..5
0030 - 00 ff 01 00 00 2d 00 23-00 00 00 0d 00 20 00 1e   .-.#. ..
0040 - 06 01 06 02 06 03 05 01-05 02 05 03 04 01 04 02   
0050 - 04 03 03 01 03 02 03 03-02 01 02 02 02 03 00 0f   
0060 - 00 01 01  ...

TLS 1.2 Handshake [length 005e], ClientHello

 01 00 00 5a 03 03 58 e3 38 52 5c d3 37 8b 23 86
 92 e6 63 2f e7 dd f9 ed 42 df 2b 45 51 06 1e f2
 f3 38 b1 36 c7 d4 00 00 04 00 35 00 ff 01 00 00
 2d 00 23 00 00 00 0d 00 20 00 1e 06 01 06 02 06
 03 05 01 05 02 05 03 04 01 04 02 04 03 03 01 03
 02 03 03 02 01 02 02 02 03 00 0f 00 01 01


thank you,
rajesh

- Original Message -
From: Eric Broch [mailto:ebr...@whitehorsetc.com]
To: qmailtoaster-list@qmailtoaster.com
Sent: Tue, 4 Apr 2017 00:09:04 -0600
Subject:

Also run command with -debug and -msg options in red below.

# openssl s_client -starttls smtp  -no_ssl3 -no_ssl2 -cipher
"AES256-SHA" -debug -msg -connect mx01.emas.dbschenker.com:25


On 4/4/2017 12:03 AM, Eric Broch wrote:

Rajesh,

Please disregard my last question (Does it connect and get full cert
details if you use IP address?).

"here too, the issue is server side. My mail server is not able to
connect to the mail server of hpe.com and send the emails of my clients"

Your server is acting as a client in this case by initiating a TLS
connection to the domains in question...to deliver mail, correct? Do
you have settings in one of your control files to initiate TLS
connections with certain domains?

"openssl s_client -starttls smtp -no_ssl3 -no_ssl2 -cipher
"AES256-SHA" -connect mx01.emas.dbschenker.com:25"

This command works from my COS6 and COS7 hosts. So I don't think it's
on their end.

which openssl version are you running?

Eric




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


--
Eric Broch, IMSO, DAM, NGOO, DITH, URTS
White Horse Technical Consulting (WHTC)

Re: [qmailtoaster] TLS connect failed: timed out

[Rajesh M]

eric

here are the details

[root@ns1 control]# openssl version
OpenSSL 1.0.1e-fips 11 Feb 2013

[root@ns1 control]# openssl s_client -starttls smtp  -no_ssl3 -no_ssl2 -cipher 
"AES256-SHA" -debug -msg -connect mx01.emas.dbschenker.com:25
CONNECTED(0003)
read from 0x1777e10 [0x17b9ae0] (4096 bytes => 75 (0x4B))
 - 32 32 30 20 6d 74 61 31-31 2e 65 6d 61 73 2e 64   220 mta11.emas.d
0010 - 62 73 63 68 65 6e 6b 65-72 2e 63 6f 6d 20 45 53   bschenker.com ES
0020 - 4d 54 50 20 53 6d 74 70-64 3b 20 54 75 65 2c 20   MTP Smtpd; Tue,
0030 - 34 20 41 70 72 20 32 30-31 37 20 30 38 3a 31 32   4 Apr 2017 08:12
0040 - 3a 33 30 20 2b 30 32 30-30 0d 0a  :30 +0200..
write to 0x1777e10 [0x17baaf0] (25 bytes => 25 (0x19))
 - 45 48 4c 4f 20 6f 70 65-6e 73 73 6c 2e 63 6c 69   EHLO openssl.cli
0010 - 65 6e 74 2e 6e 65 74 0d-0aent.net..
read from 0x1777e10 [0x17b9ae0] (4096 bytes => 230 (0xE6))
 - 32 35 30 2d 6d 74 61 31-31 2e 65 6d 61 73 2e 64   250-mta11.emas.d
0010 - 62 73 63 68 65 6e 6b 65-72 2e 63 6f 6d 20 48 65   bschenker.com He
0020 - 6c 6c 6f 20 6e 73 31 2e-61 61 61 6f 6e 6c 69 6e   llo ns1.aaaonlin
0030 - 75 78 2e 63 6f 6d 20 5b-31 30 33 2e 32 34 31 2e   ux.com [103.241.
0040 - 31 38 31 2e 31 33 37 5d-2c 20 70 6c 65 61 73 65   181.137], please
0050 - 64 20 74 6f 20 6d 65 65-74 20 79 6f 75 0d 0a 32   d to meet you..2
0060 - 35 30 2d 45 4e 48 41 4e-43 45 44 53 54 41 54 55   50-ENHANCEDSTATU
0070 - 53 43 4f 44 45 53 0d 0a-32 35 30 2d 50 49 50 45   SCODES..250-PIPE
0080 - 4c 49 4e 49 4e 47 0d 0a-32 35 30 2d 38 42 49 54   LINING..250-8BIT
0090 - 4d 49 4d 45 0d 0a 32 35-30 2d 53 49 5a 45 20 32   MIME..250-SIZE 2
00a0 - 36 32 31 34 34 30 30 0d-0a 32 35 30 2d 41 55 54   6214400..250-AUT
00b0 - 48 20 4c 4f 47 49 4e 20-50 4c 41 49 4e 0d 0a 32   H LOGIN PLAIN..2
00c0 - 35 30 2d 53 54 41 52 54-54 4c 53 0d 0a 32 35 30   50-STARTTLS..250
00d0 - 2d 44 45 4c 49 56 45 52-42 59 0d 0a 32 35 30 20   -DELIVERBY..250
00e0 - 48 45 4c 50 0d 0a HELP..
write to 0x1777e10 [0x7ffd0b0c4880] (10 bytes => 10 (0xA))
 - 53 54 41 52 54 54 4c 53-0d 0a STARTTLS..
read from 0x1777e10 [0x16aad00] (8192 bytes => 30 (0x1E))
 - 32 32 30 20 32 2e 30 2e-30 20 52 65 61 64 79 20   220 2.0.0 Ready
0010 - 74 6f 20 73 74 61 72 74-20 54 4c 53 0d 0a to start TLS..
write to 0x1777e10 [0x17b9ae0] (99 bytes => 99 (0x63))
 - 16 03 01 00 5e 01 00 00-5a 03 03 58 e3 38 52 5c   ^...Z..X.8R\
0010 - d3 37 8b 23 86 92 e6 63-2f e7 dd f9 ed 42 df 2b   .7.#...c/B.+
0020 - 45 51 06 1e f2 f3 38 b1-36 c7 d4 00 00 04 00 35   EQ8.6..5
0030 - 00 ff 01 00 00 2d 00 23-00 00 00 0d 00 20 00 1e   .-.#. ..
0040 - 06 01 06 02 06 03 05 01-05 02 05 03 04 01 04 02   
0050 - 04 03 03 01 03 02 03 03-02 01 02 02 02 03 00 0f   
0060 - 00 01 01  ...
>>> TLS 1.2 Handshake [length 005e], ClientHello
01 00 00 5a 03 03 58 e3 38 52 5c d3 37 8b 23 86
92 e6 63 2f e7 dd f9 ed 42 df 2b 45 51 06 1e f2
f3 38 b1 36 c7 d4 00 00 04 00 35 00 ff 01 00 00
2d 00 23 00 00 00 0d 00 20 00 1e 06 01 06 02 06
03 05 01 05 02 05 03 04 01 04 02 04 03 03 01 03
02 03 03 02 01 02 02 02 03 00 0f 00 01 01


thank you,
rajesh

- Original Message -
From: Eric Broch [mailto:ebr...@whitehorsetc.com]
To: qmailtoaster-list@qmailtoaster.com
Sent: Tue, 4 Apr 2017 00:09:04 -0600
Subject:

Also run command with -debug and -msg options in red below.

# openssl s_client -starttls smtp  -no_ssl3 -no_ssl2 -cipher
"AES256-SHA" -debug -msg -connect mx01.emas.dbschenker.com:25


On 4/4/2017 12:03 AM, Eric Broch wrote:
> Rajesh,
>
> Please disregard my last question (Does it connect and get full cert
> details if you use IP address?).
>
> "here too, the issue is server side. My mail server is not able to
> connect to the mail server of hpe.com and send the emails of my clients"
>
> Your server is acting as a client in this case by initiating a TLS
> connection to the domains in question...to deliver mail, correct? Do
> you have settings in one of your control files to initiate TLS
> connections with certain domains?
>
> "openssl s_client -starttls smtp -no_ssl3 -no_ssl2 -cipher
> "AES256-SHA" -connect mx01.emas.dbschenker.com:25"
>
> This command works from my COS6 and COS7 hosts. So I don't think it's
> on their end.
>
> which openssl version are you running?
>
> Eric
>

--
Eric Broch, IMSO, DAM, NGOO, DITH, URTS
White Horse Technical Consulting (WHTC)


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

Re: [qmailtoaster] TLS connect failed: timed out

[Eric Broch]

Also run command with -debug and -msg options in red below.

# openssl s_client -starttls smtp  -no_ssl3 -no_ssl2 -cipher 
"AES256-SHA" -debug -msg -connect mx01.emas.dbschenker.com:25



On 4/4/2017 12:03 AM, Eric Broch wrote:

Rajesh,

Please disregard my last question (Does it connect and get full cert 
details if you use IP address?).


"here too, the issue is server side. My mail server is not able to 
connect to the mail server of hpe.com and send the emails of my clients"


Your server is acting as a client in this case by initiating a TLS 
connection to the domains in question...to deliver mail, correct? Do 
you have settings in one of your control files to initiate TLS 
connections with certain domains?


"openssl s_client -starttls smtp -no_ssl3 -no_ssl2 -cipher 
"AES256-SHA" -connect mx01.emas.dbschenker.com:25"


This command works from my COS6 and COS7 hosts. So I don't think it's 
on their end.


which openssl version are you running?

Eric



--
Eric Broch, IMSO, DAM, NGOO, DITH, URTS
White Horse Technical Consulting (WHTC)

Re: [qmailtoaster] TLS connect failed: timed out

[Eric Broch]

Rajesh,

Please disregard my last question (Does it connect and get full cert 
details if you use IP address?).


"here too, the issue is server side. My mail server is not able to 
connect to the mail server of hpe.com and send the emails of my clients"


Your server is acting as a client in this case by initiating a TLS 
connection to the domains in question...to deliver mail, correct? Do you 
have settings in one of your control files to initiate TLS connections 
with certain domains?


"openssl s_client -starttls smtp -no_ssl3 -no_ssl2 -cipher "AES256-SHA" 
-connect mx01.emas.dbschenker.com:25"


This command works from my COS6 and COS7 hosts. So I don't think it's on 
their end.


which openssl version are you running?

Eric

--
Eric Broch, IMSO, DAM, NGOO, DITH, URTS
White Horse Technical Consulting (WHTC)


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

Re: [qmailtoaster] TLS connect failed: timed out

[Eric Broch]

Does it connect and get full cert details if you use IP address?


On 4/3/2017 10:49 PM, Rajesh M wrote:

eric

here too, the issue is server side. My mail server is not able to connect to 
the mail server of hpe.com and send the emails of my clients

i changed the certificates and use your ciphers (restarted qmail), however it 
still does not connect.


it says CONNECTED but no further response.

[root@ns1 control]# openssl s_client -starttls smtp  -no_ssl3 -no_ssl2 -cipher 
"AES256-SHA" -connect mx01.emas.dbschenker.com:25
CONNECTED(0003)

[root@ns1 control]# openssl s_client -connect mx01.emas.dbschenker.com:25 
-starttls smtp
CONNECTED(0003)

if i connect to localhost
openssl s_client -connect localhost:25 -starttls smtp
i get the full cert details and
250 AUTH LOGIN PLAIN CRAM-MD5

rajesh


- Original Message -
From: Eric Broch [mailto:ebr...@whitehorsetc.com]
To: qmailtoaster-list@qmailtoaster.com
Sent: Mon, 3 Apr 2017 22:20:42 -0600
Subject:

Yes, test with your certificate and ciphers. Also use the domain name
NOT the IP address. There was a problem several months back that I
thought was a TLS issue but ended up being a dns/edns issue. Check the
below thread out. It was a server, not client, side issue but might be
the problem in your case, just the same:

https://www.mail-archive.com/qmailtoaster-list@qmailtoaster.com/msg40185.html


On 4/3/2017 10:15 PM, Rajesh M wrote:

eric

thanks for your reply

these the responses

to the mx of hpe.com
[root@ns1 domains]# openssl s_client -starttls smtp  -no_ssl3 -no_ssl2 -cipher 
"AES256-SHA" -connect 15.233.44.29:25
CONNECTED(0003)

to the mx of dbschenker.com
[root@ns1 domains]# openssl s_client -starttls smtp  -no_ssl3 -no_ssl2 -cipher 
"AES256-SHA" -connect 62.180.229.52:25
CONNECTED(0003)


shall i replace the tlsciphers and check out ?

rajesh



- Original Message -
From: Eric Broch [mailto:ebr...@whitehorsetc.com]
To: qmailtoaster-list@qmailtoaster.com
Sent: Mon, 3 Apr 2017 21:49:05 -0600
Subject:

Hi Rajesh,

Could you test something like this from qmail host:

openssl s_client -starttls smtp  -no_ssl3 -no_ssl2 -cipher "AES256-SHA"
-connect a...@domain.com:25

BTW these are the ciphers on my my COS 6 host:

DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:ADH-SEED-SHA:SEED-SHA:IDEA-CBC-SHA:KRB5-IDEA-CBC-SHA:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:AECDH-AES256-SHA:ADH-AES256-GCM-SHA384:ADH-AES256-SHA256:ADH-AES256-SHA:ADH-CAMELLIA256-SHA:ECDH-RSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES256-SHA384:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:CAMELLIA256-SHA:PSK-AES256-CBC-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:AECDH-AES128-SHA:ADH-AES128-GCM-SHA256:ADH-AES128-SHA256:ADH-AES128-SHA:ADH-CAMELLIA128-SHA:ECDH-RSA-AES128-GCM-SHA256:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-RSA-AES128-SHA256:ECDH-ECDSA-AES128-SHA256:ECDH-RSA-AES128-SHA:ECDH-ECDSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:CAMELLIA128-SHA:PSK-AES128-CBC-SHA


Eric


On 4/3/2017 8:23 PM, Rajesh M wrote:

hi

os ; centos 6
qmailtoaster, spamassassin, mysql, dovecot, clam

we are suddenly receiving TLS connect failed: timed out error on all our 
servers running qmail

when emails are sent by our customer to the following domains hp.com, hpe.com, 
dbschenker.com, kamyn.co.ke

the authentication by the customer is done correctly, email gets sent from the 
email client of the customer and emails recd by the server. however the mail 
lies in the queue till finally it bounces back to the sender with the message  
TLS connect failed.

2017-04-03 15:21:40.916522500 bounce msg 4468196 qp 33696
2017-04-03 15:21:40.916589500 end msg 4468196
2017-04-03 15:01:34.006986500 starting delivery 56232: msg 4468196 to remote 
a...@hpe.com
2017-04-03 15:21:40.869716500 delivery 56232: failure: 
TLS_connect_failed:_timed_out;_connected_to_15.241.48.71./I'm_not_going_to_try_again;
_this_message_has_been_in_the_queue_too_long./
2017-04-03 15:01:34.007035500 starting delivery 56233: msg 4468196 to remote 
xxx...@hpe.com
2017-04-03 15:21:40.851782500 delivery 56233: failure: 
TLS_connect_failed:_timed_out;_connected_to_15.241.48.71./I'm_not_going_to_try_again;
_this_message_has_been_in_the_queue_too_long./
2017-04-03 15:01:34.007150500 starting delivery 56234: msg 4468196 to remote 
dfdf...@hpe.com
2017-04-03 15:21:40.876609500 deliv