Добрый день!

Периодически теряется соединение при получении почты от облака alibaba с такой ошибкой: SMTP connection lost after final dot

Писем приходит от них много, но некоторые с этой ошибкой не доходят, и не пересылаются в последствии. В логах вот такая картина:

2020-12-08 18:58:43 1kmYbt-0007MA-6e Accepted with  spam score. Founded in white_addreses file.  Letter from host out29-49.mail.aliyun.com [115.124.29.49] (nina@trans-hope.com ==> @)
2020-12-08 18:58:43 1kmYbt-0007MA-6e SMTPNOTQUIT: connection-lost Letter from host out29-49.mail.aliyun.com [115.124.29.49] (nina@trans-hope.com ==> @)
2020-12-08 18:58:43 1kmYbt-0007MA-6e SMTP connection lost after final dot H=out29-49.mail.aliyun.com [115.124.29.49] I=[192.168.111.230]:25 P=esmtps

На данный момент используется пакет 4.92-8+deb10u4+openssl1
Ранее была использован штатный пакет от debian10 с GNUTLS, так же был испробован 4.94 с GNUTLS
Ошибка возникала во всех вариантах. Узнать у китайцев причину, по которой они не получив подтверждения о приёме письма считают его доставленным и не производят попыток направить его ещё раз, на данный момент времени так и не вышло.

Сегодня пришла мысль, что на момент отправки финальной точки (final dot), согласно правилам проведения smtp сессии, уже должен быть известен получатель, а он неизвестен. Как такое может быть? Если неизвестен получатель, то как могла быть отправлена финальная точка, которая идёт вслед за командой DATA, которой предшествует RCPT TO? Или я неправильно понимаю природу данного явления?

Явление не очень частое, но есть риск не получить важное письмо, что обернётся огромной проблемой.

Спасибо за внимание!

• Exim SMTP connection lost after final dot,Аноним, 12:01 , 09-Дек-20
  • Exim SMTP connection lost after final dot,camojiet, 02:50 , 10-Дек-20
    • Exim SMTP connection lost after final dot,Аноним, 07:16 , 10-Дек-20
• Exim SMTP connection lost after final dot,Тот самый, 10:27 , 11-Дек-20
  • Exim SMTP connection lost after final dot,Тот самый, 10:38 , 11-Дек-20

> Периодически теряется соединение при получении почты от облака alibaba с такой ошибкой:
> SMTP connection lost after final dot

сервер не отправил команду SMTP QUIT
Письмо к этому моменту уже передано целиком, поэтому, как правило "и х... с ним, горемычным"

> Писем приходит от них много, но некоторые с этой ошибкой не доходят,
> и не пересылаются в последствии.
> Ошибка возникала во всех вариантах. Узнать у китайцев причину, по которой они
> не получив подтверждения о приёме письма считают его доставленным и не
> производят попыток направить его ещё раз, на данный момент времени так
> и не вышло.

А зачем? Это 146% китайская реклама, от которой у меня уже давно ящик трещит по швам. Потому и не заморачиватся перепосылкой и православным выходом из сессии. Надо скорее следующего клиента окучить

> Сегодня пришла мысль, что на момент отправки финальной точки (final dot), согласно
> правилам проведения smtp сессии, уже должен быть известен получатель, а он
> неизвестен. Как такое может быть?

Кривой китайский софт умеет много гитик.
Включи расширенное логирование, и смотри подробную картину сессии. Возможно, увидишь, что письмо вообще ничего не содержит.

> Явление не очень частое, но есть риск не получить важное письмо, что
> обернётся огромной проблемой.

Вероятность этого чуть менее, чем никакая.

>[оверквотинг удален]
> выходом из сессии. Надо скорее следующего клиента окучить
>> Сегодня пришла мысль, что на момент отправки финальной точки (final dot), согласно
>> правилам проведения smtp сессии, уже должен быть известен получатель, а он
>> неизвестен. Как такое может быть?
> Кривой китайский софт умеет много гитик.
> Включи расширенное логирование, и смотри подробную картину сессии. Возможно, увидишь,
> что письмо вообще ничего не содержит.
>> Явление не очень частое, но есть риск не получить важное письмо, что
>> обернётся огромной проблемой.
> Вероятность этого чуть менее, чем никакая.

Спасибо, конечно. Но организация занимается как раз международными контейнерными перевозками и основные партнёры - китайцы. Я знаю от кого идёт письмо, и этот адрес - наш партнёр. Если точка отправлена - значит и письмо должно быть на сервере - а его нет.

>> Кривой китайский софт умеет много гитик.
>> Включи расширенное логирование, и смотри подробную картину сессии. Возможно, увидишь,
> и этот адрес - наш партнёр. Если точка отправлена - значит
> и письмо должно быть на сервере - а его нет.

https://www.google.com/search?q=exim+debug+smtp+session

>Accepted with  spam score. Founded in white_addreses

Судя по логам, у тебя много чего накручено в ACL

>SMTPNOTQUIT: connection-lost Letter from host

Обрати внимание на SMTPNOTQUIT. Похоже, что письмо режется на твоей стороне в acl_smtp_notquit
Поставь временно acl_smtp_notquit = accept вместо твоих правил и проверь

Если ты уж используешь white_addreses, тогда первое правило в acl_smtp_notquit должно быть

accept condition = ${if <как ты проверяешь на white_addreses> }