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


Watch logs


On 2/23/2022 8:53 AM, Peter Peltonen wrote:
You mean my server with (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 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?


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:


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


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:

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 

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 


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

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


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:

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.


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

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


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


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.


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-
Did anyone find a solution?


Am 17.02.22 um 20:28 schrieb Qmail:

Not sure it is related, but I just read in the Nginx forum that
some have issues (failed (SSL: error:0A0000B9: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 :


The 4.0 list contains:


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 ?


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

TLS connect failed: error:1421C105:SSL
cipher returnedZConnected to 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.

Am 15.02.22 um 09:39 schrieb Peter Peltonen:
What I have installed is

Any reason to update?


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
siphers on their and on my own list. Any idea how I could debug
more so I can find out why mail is not being delivered to their


All ciphers

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

• AES256-GCM-SHA384
• AES256-SHA256
• AES256-SHA

Secure ciphers

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:


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
from I get the following error:


So am I missing something here:

[root@mail ~]# cat /var/qmail/control/tlsclientciphers




To unsubscribe, e-mail:
For additional commands, e-mail:


To unsubscribe, e-mail:
For additional commands, e-mail:


To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to