Autor: Cyborg Data: A: exim-users Assumpte: Re: [exim] missing logline, as if the delivery crashed
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 <= user@???
>> 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
>> id=504f250e-1b94-40f6-3d26-2011d5f54bca@???
>> 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.
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.
