Я пытаюсь понять, как возникает эта проблема и как ее решить. Каким-то образом сообщения попадают в нашу входящую спул Exim без символа \ n в конце. Когда наш исходящий процесс eximʻa пытается доставить эти письма, они терпят неудачу, поскольку exim выводит '.' в той же строке, что и отправленный. Я проверил это, записав разговор SMTP с обеих сторон с помощью tcpdump.
tcpdump показывает, что в конце отправляется следующее:
<! - www.https: //example.com--> <! - www.https: //example.com-->.
Что не является правильным завершением ДАННЫХ. В конце концов принимающий MTA отвечает
421 Потеряно входящее соединение
Передача сообщения в спуле через od, Я вижу в конце тела сообщения:
0011700 e. c o m - ->
Нет \ ns. Эти сообщения, застревающие в спуле, кажутся спамом. Что я вижу в исходящем журнале,
1NLolk-0003aD-3V == email@example.com R = Хранилище T = Отсрочка хранилища (-46): Ошибка SMTP от удаленного почтового сервера после окончания данных: хост 192.168.1.3 [192.168.1.3]: 421 mda.local SMTP время ожидания входящих данных - закрытие соединения.
У кого-нибудь есть идеи? Параметр message_suffix звучал так, как будто это был бы хороший бандаж, но он применяется только к appendfile и pipe.
Я проконсультировался по этому поводу со списком рассылки Exim, и похоже, что проблема заключается в фильтре содержимого MailScanner. У нас есть MailScanner, который выполняет сканирование на вирусы / спам для нас, и он кажется на некоторых сообщениях, когда он очищает конец сообщения, \n не учитывается, и сообщение помещается в исходящую очередь exim`a в состоянии, при котором exim не может его доставить. Exim не утверждает, что он послал \n перед попыткой завершить SMTP DATA передача с ., который сейчас обсуждают некоторые разработчики Exim.
Я думаю, что спамеры делают это специально, надеясь, что ваш почтовый сервер обратное рассеяние полное сообщение (ваш SMTP-сервер следует правилам, поэтому он добавит \ n) невиновному человеку, указанному в ответе.
Чтобы исправить это, вам нужно стать более агрессивным со своим антиспамом, проверив, что IP-адрес отправителя не указан в списках RBL, что SPF записывать матчи и т. д.
Еще одна мысль - каждую ночь очищать вашу очередь мертвых сообщений с помощью сценария. Я недостаточно хорошо знаю Exim, чтобы предлагать, как это сделать ...
HTH