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 <ebr...@whitehorsetc.com> 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 <ebr...@whitehorsetc.com> wrote:
If I remember correctly it had something to do with Dovecot
On Feb 23, 2022, at 2:25 AM, Peter Peltonen <peter.pelto...@gmail.com> 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: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 :
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
< ebr...@whitehorsetc.com> 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
< ebr...@whitehorsetc.com> 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-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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com