Am 02.06.21 um 10:23 schrieb Jeremy Harris via Exim-users:
On 02/06/2021 07:49, Cyborg via Exim-users wrote:
since an os upgrade of fedora, where the security policy changed,
this happens to some connections:
2021-06-02 07:02:58 1loJ1s-006Qmo-BG <= [email protected]
H=nx222.node01.secure-mailgate.com [89.22.108.222] P=esmtps
X=TLS1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=no K S=19127
[email protected]
2021-06-02 07:02:58 1loJ1s-006Qmo-BG Completed
You will notice, that the delivery line is missing.
You're not showing a connection there; either of reception or of
delivery.
That the delivery "=>" line is missing, is exactly the problem here.
All other valid attempts in and out have that delivery line, but this ->
failed <- message, does not have one. I have never seen this happen
in 15 years of exim services.
It's reliably happening if a specific server
How were those lines extracted from the log?
manually copy and paste . I searched for error lines between <= and
completed, but there are none. The "=>" is not printed to the log at all
and there is no other error.
Do you log connection arrivals, incoming connection terminations,
Standard logs are active, so we get "<=" "=>" "**" and Completed and
some internal warnings used for in-case-debugging of antispam problems.
here is a typical, randomly choosen, working log:
2021-06-02 10:51:44 1loMbI-00794v-6n
H=mta-174-90-195.senderdomain.de.sparkpostmail.com [192.174.90.195]
Warning: processing file "" for "To: "XXXXX XXXXXXX" <[email protected]>
-> From: "YYYYYYYYYYYYYYY" <[email protected]> /
R="YYYYYYYYYYYYYYY" <[email protected]>"
2021-06-02 10:51:44 1loMbI-00794v-6n
H=mta-174-90-195.senderdomain.de.sparkpostmail.com [192.174.90.195]
Warning: send for "XXXXX XXXXXXXXXX" <[email protected]>
2021-06-02 10:51:48 1loMbI-00794v-6n <=
[email protected]
H=mta-174-90-195.senderdomain.de.sparkpostmail.com [192.174.90.195]
P=esmtps X=TLS1.2:ECDHE-RSA-AES128-GCM-SHA256:128 CV=no S=76268
[email protected]
2021-06-02 10:51:48 1loMbI-00794v-6n => /STORAGE/Maildir/
([email protected]) <[email protected]> R=virtual_user T=address_directory
2021-06-02 10:51:48 1loMbI-00794v-6n Completed
The messages in question have normal entries in those Warnings we
additional create, so i left them out, as they are not relevant personal
informations.
delivery connection attempts or terminations?
Normally everything is logged, thats exactly the point.
NOW, AFTER i downgraded the crypto-policy of fedora back to F32, the
delivery of these message from the named server are processed and fully
logged again.
My guess is, we just found a bug in processing of the DH KEY TOO SMALL
error on incoming connections, openssl throws , where the error avoids
getting logged.
We are talking about a mailcluster with thousands of mailboxes, which
had no problems with >99% of all incoming/outgoing mails when the new
crypto-policy was active. That <1% of mailserver "seem" to have the same
dhe problem.
After i switched back to f32 policy and restarted exim, those remote
mailserver with the "DH key too small" error ( problem 2) did use DHE
ciphers . I'm pretty sure, the orginal problem is a config error either
in fedoras openssl default config ( never changed it manually ) or the
remote servers DHE exchange is misconfigured.
If someone knows how to tell openssl s_client to simulate or detect
this zero sized DH key, i can run tests on those servers to find out more.
best regards,
Marius
--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/
