* Проблемы с приемом писем

После обновления exe и dll на последние бета версии начались проблемы с приемом писем с ряда доменов.

Т.е SMTP сессия нормально доходит до передачи тела письма, создается файл в spool-е, а потом сессия отваливается по таймауту.
Причем проблема существует перманентно, но только для некоторых доменов (т.е почта от этих MTA не принимается вообще — не зависит ни от дня недели, ни от провайдера — пробовал двух разных). И таких отправителей (разных) больше десятка. Найти что-то общее между ними не смог.

Лог со стороны сервера

12:16:07 81962 Connected 12:16:07 81962 Reply: 220 mx1.maggitech.ru Eserv/3.4807 (PigMail/1.36beta7) ESMTP. Mon, 17 Oct 2016 12:16:07 +0300 12:16:07 81962 EHLO tekomprof.ru 12:16:07 81962 Reply: 250-mx1.maggitech.ru Hello [78.36.43.28], pleased to meet you 12:16:08 81962 MAIL From:<aleksandr.tarasov@tekomprof.ru> 12:16:08 81962 WhiteList (MailRoll) 12:16:08 81962 Reply: 250 aleksandr.tarasov@tekomprof.ru OK. Glad to meet you again 12:16:08 81962 RCPT To:<d.nurov@mirkrasok.com> 12:16:08 81962 Local domain user, accepted 12:16:08 81962 Reply: 250 d.nurov@mirkrasok.com OK, my domain user 12:16:08 81962 DATA 12:16:08 81962 Reply: 354 send the mail data, end with . 12:21:08 81962 Reply: 450 error: 10060 12:21:08 81962 STAT: 102:422:0:0:300765

Лог со стороны клиента:

--- Session Transcript --- Mon 2016-10-17 12:14:03: Session 112527; child 0002 Mon 2016-10-17 12:14:03: Parsing message <xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\pd90000023886.msg> Mon 2016-10-17 12:14:03: * From: aleksandr.tarasov@tekomprof.ru Mon 2016-10-17 12:14:03: * To: d.nurov@mirkrasok.com Mon 2016-10-17 12:14:03: * Subject: Mon 2016-10-17 12:14:03: * Size (bytes): 6173 Mon 2016-10-17 12:14:03: * Message-ID: <!&!AAAAAAAAAAAYAAAAAAAAAARZUKWLqJlEiQ/xGlum78vCgAAAEAAAALUsVDHxVeVEh2IUcSMq iykBAAAAAA==@tekomprof.ru> Mon 2016-10-17 12:14:03: Attempting SMTP connection to [mirkrasok.com] Mon 2016-10-17 12:14:03: Resolving MX records for [mirkrasok.com] (DNS Server: 78.36.60.226)... Mon 2016-10-17 12:14:03: * P=010 S=000 D=mirkrasok.com TTL=(120) MX=[mx.mirkrasok.com] Mon 2016-10-17 12:14:03: Attempting SMTP connection to [mx.mirkrasok.com:25] Mon 2016-10-17 12:14:03: Resolving A record for [mx.mirkrasok.com] (DNS Server: 78.36.60.226)... Mon 2016-10-17 12:14:03: * D=mx.mirkrasok.com TTL=(120) A=[93.189.148.226] Mon 2016-10-17 12:14:03: Attempting SMTP connection to [93.189.148.226:25] Mon 2016-10-17 12:14:03: Waiting for socket connection... Mon 2016-10-17 12:14:03: * Connection established (192.168.10.4:1056 -> 93.189.148.226:25) Mon 2016-10-17 12:14:03: Waiting for protocol to start... Mon 2016-10-17 12:14:03: <-- 220 mx1.maggitech.ru Eserv/3.4807 (PigMail/1.36beta7) ESMTP. Mon, 17 Oct 2016 12:16:07 +0300 Mon 2016-10-17 12:14:03: --> EHLO tekomprof.ru Mon 2016-10-17 12:14:03: <-- 250-mx1.maggitech.ru Hello [78.36.43.28], pleased to meet you Mon 2016-10-17 12:14:04: <-- 250-STARTTLS Mon 2016-10-17 12:14:04: <-- 250-AUTH PLAIN LOGIN Mon 2016-10-17 12:14:04: <-- 250-AUTH=LOGIN Mon 2016-10-17 12:14:04: <-- 250-ETRN Mon 2016-10-17 12:14:04: <-- 250-8bitmime Mon 2016-10-17 12:14:04: <-- 250-BINARYMIME Mon 2016-10-17 12:14:04: <-- 250 HELP Mon 2016-10-17 12:14:04: --> MAIL From:<aleksandr.tarasov@tekomprof.ru> Mon 2016-10-17 12:14:04: <-- 250 aleksandr.tarasov@tekomprof.ru OK. Glad to meet you again Mon 2016-10-17 12:14:04: --> RCPT To:<d.nurov@mirkrasok.com> Mon 2016-10-17 12:14:04: <-- 250 d.nurov@mirkrasok.com OK, my domain user Mon 2016-10-17 12:14:04: --> DATA Mon 2016-10-17 12:14:04: <-- 354 send the mail data, end with . Mon 2016-10-17 12:14:04: Sending <xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx\pd90000023886.msg> to [93.189.148.226] Mon 2016-10-17 12:14:04: Transfer Complete Mon 2016-10-17 12:15:39: Socket connection closed by the other side (how rude!) Mon 2016-10-17 12:15:39: * Winsock Error 10053 Mon 2016-10-17 12:15:39: Connection closed Mon 2016-10-17 12:15:39: This message is 3 days old; it has 0 days left to get delivered --- End Transcript ---

Были ли какие-нибудь изменения в последних билдах помимо SSL/TLS ? Что можно попробовать подкрутить?

P.S. антивирусов нет, умных файрволов тоже

Спасибо

Автор

Дата

Текст

tags

pig

18.10.2016 17:30

Судя по 10053, соединение кто-то рвёт на стороне отправителя. Через полторы минуты. А acSMTP ещё три с половиной минуты ждёт данных.
И никакого SSL при этом.

wikipost

asm

19.10.2016 09:30

Только вот этого "кто-то" совсем не видно..
Умного файрвола нет (только простой NAT на маршрутизаторе без какой либо L7 фильтрации, DPI и т.п) , антивируса тоже, пускал через разных провайдеров. И ладно был бы один такой клиент, но их несколько и все абсолютно разные приходят из разных регионов, AS, магистральных провайдеров

wikipost

asm

19.10.2016 09:31

да и не было такого до обновления... может конечно совпадение, но на всякий случай спросил, может АС какую-то еще оптимизацию делал

wikipost

19.10.2016 19:56
ред: 19.10.2016 20:00

В SMTP ничего не менялось в этом обновлении. SSL в приведённых сессиях нет, т.е. ничего вообще не должно было измениться для этого случая.

Таймаут на этапе DATA может быть вызван разными причинами. Самыми вероятными я бы назвал такие:

Congestion в канале: где-то в маршруте есть роутер с толстым буфером передачи, куда письмо быстро влетает целиком, а оттуда к получателю едет по относительно тонкому каналу, часть подтверждений от получателя (вашей Windows) теряется, требуется переотправка фреймов, но отправляющая машина не может их своевременно отправить, т.к. исходящий буфер забит в той точке перехода "из толстого в тонкий". К сожалению, TCP очень неудачно реализован по части детектирования и исключения congestions, помогает в таких случаях только замедление отправителя. Для тех случаев, когда отправителем является Eserv, у нас даже давно есть специальный флажок замедления у smtpsend. Раз у вас есть доступ к обеим машинам, можно попробовать такое же письмо отправить не MDaemon'ом, а smtpsend'ом.
Антивирусы (ну раз у вас нет, здесь не считается)
Фильтры — может здесь таймаут от функции связи с PopFile, а не с отправителем?
NAT, firewall, tcpmap. В вашей сессии странно то, что MDaemon утверждает, что соединение закрыто получателем через полторы минуты после отправки (мгновенной, см. п1), хотя Eserv честно ждёт 5 минут по таймауту на операции чтения, судя по вашему логу, то есть закрыть соединение раньше никак не мог. Значит соединение закрыто (сброшено, судя по 10053) промежуточным звеном. Скорее всего роутером в ЛС отправителя, где MDaemon стоит. И скорее всего именно из-за congestion, либо от "большого ума" (багов в трансляции протоколов, попытками уменьшить число соединений в таблице NAT и т.п.). Не помню, как конкретно у MDaemon, но вообще у MTA таймауты на SMTP сессии по умолчанию большие — больше полутора минут — и раз он прервал ожидание ответа раньше, и не по таймауту, то явно какой-то промежуточный узел прислал ему TCP RST-пакет в этом соединении, чего нормальные тупые честные роутеры не делают, они на уровень TCP даже не заглядывают.

В общем, интересно было бы посмотреть, как это будет выглядеть в smtpsend вместо mdaemon на стороне отправителя.

wikipost

19.10.2016 20:07

В логе MDaemon размер письма указан 6КБ, значит congestion в данном конкретном случае маловероятен. Тогда повышается вероятность вмешательства постороннего софта в TCP-сессию, т.е. пп 2-4. И в число тестов Smtpsend'ом стоит добавить отправку с TLS, чтобы скрыть контент от всех фильтров кроме ваших Eserv'ных.

wikipost

asm

21.10.2016 16:54

Таймаут антиспама исключил — пробовал с отключенным и запускал снифер, после DATA никакие пакеты к серверу больше не приходят. Причем, что интересно — такая проблема имеет место быть и с MTA, которые используют TSL, т.е. железку с DPI и т.п можно исключать.

Пробовал менять принудительно mss вплоть до 1300. Ничего не поменялось.

К сожалению доступа к проблемным MTA у меня нет — лог MDaemon-а прислали клиенты для разбора полетов.

Какие еще танцы с бубном можно попробовать?

wikipost

25.10.2016 03:16

asm пишет: Таймаут антиспама исключил — пробовал с отключенным и запускал снифер, после DATA никакие пакеты к серверу больше не приходят. Причем, что интересно — такая проблема имеет место быть и с MTA, которые используют TSL, т.е. железку с DPI и т.п можно исключать.

Нет, железку можно исключить только в случае, если вы проснифили трафик не только на выходе с неё, но и на входе — если ей на вход тоже не поступают никакие пакеты от проблемных MTA, то значит железка ничего не фильтрует и не виновата. Но тогда у вас и рычагов влияния на ситуацию уже никаких не остаётся — все проблемы снаружи.

wikipost

Eserv Forum / E5 / Mail / Проблемы с приемом писем