У меня есть приложение, которое посылает smtp электронное письмо через местный телефонный сервер в клиенте. Вся электронная почта отправляет хорошо (это добирается до получателя), но некоторое электронное письмо послано многократно, потому что мое приложение никогда не получает 221 код respose, чтобы сказать, что это работало хорошо и так повторения. Мы могли remve повторения, но часто это необходимо для подлинных проблем.
Это происходит чаще всего на определенных desination адресах электронной почты и будет неоднократно происходить на той электронной почте, после того как это имеет.
Я получил поток TCP того, который работает и тот, который не делает. Очевидно, имена, изменившие для защиты виновного.
Did work:
220 SBS4S1.example.local Microsoft ESMTP MAIL Service ready at Thu, 16 Apr 2015 11:51:16 +0100
EHLO example-PC
250-SBS4S1.example.local Hello [192.168.111.15]
250-SIZE 10485760
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-AUTH
250-8BITMIME
250-BINARYMIME
250-CHUNKING
250-XEXCH50
250 XSHADOW
RSET
250 2.0.0 Resetting
MAIL FROM:<yyyy@example.com>
250 2.1.0 Sender OK
RCPT TO:<zzz@example.com>
250 2.1.5 Recipient OK
DATA
354 Start mail input; end with <CRLF>.<CRLF>
--DATA Here, identical other than MIME/Content IDs in both emails--
.
250 2.6.0 <ac8dcf01-0d61-4e76-a52e-3946e68bf3a1@SBS4S1.example.local> [InternalId=26602] Queued mail for delivery
QUIT
221 2.0.0 Service closing transmission channel
.
Did NOT work:
220 SBS4S1.example.local Microsoft ESMTP MAIL Service ready at Thu, 16 Apr 2015 11:43:39 +0100
EHLO example-PC
250-SBS4S1.example.local Hello [192.168.111.15]
250-SIZE 10485760
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-AUTH
250-8BITMIME
250-BINARYMIME
250-CHUNKING
250-XEXCH50
250 XSHADOW
RSET
250 2.0.0 Resetting
MAIL FROM:<yyyy@example.com>
250 2.1.0 Sender OK
RCPT TO:<zzz@example.com>
250 2.1.5 Recipient OK
DATA
354 Start mail input; end with <CRLF>.<CRLF>
--DATA Here, identical other than MIME/Content IDs in both emails--
.
QUIT
250 2.6.0 <96ac271e-5525-4d89-aefa-a7469bae04df@SBS4S1.example.local> [InternalId=26573] Queued mail for delivery
--This then times out but never gets the 221--
Единственная разница I видит кроме пропавших без вести 221, то, что 250 и ВЫХОД наоборот в сообщении, которое "перестало работать". Действительно ли это - известная причуда Exchange, мы должны работать вокруг, что-то, что мы могли зафиксировать или должны справиться в нашем приложении или чем-то, что мы могли попросить быть измененными на почтовом сервере? Мы не хотим повреждать что-либо для нормальной, общей ситуации.
Обновление: Я думал, что мы не сможем овладеть журналами Exchange (администраторы даже не знали, где они были), но я имею! Таким образом, соответствующая строка:
Tarpit для '0.00:00:32.619' из-за 'DelayedAck', Истекшего; Тайм-аут
Похоже, что это могло бы произойти из-за:
https://mikecrowley.wordpress.com/2010/07/24/delayed-smtp-acknowledgement/
Добрался, чтобы попытаться получить протестированный сначала.
Причиной проблемы был параметр «DelayedAck» на транспорте Exchange. Принимающий сервер на «другой стороне» ретранслятора слишком долго отвечал (более 30 секунд), поэтому время ожидания соединения, которое мы устанавливали, истекло, и диалог SMTP так и не завершился. (этот URL-адрес, который я добавил в вопросе).
Администратор Exchange отключил DelayedAck на внутреннем транспорте, и проблема исчезла.
Мы могли / должны были изменить наше приложение, чтобы обойти это, но у нас есть компонент третьей части из-за чего это было сложно, и поэтому мы не можем проверить, работает ли это.
Кажется, что иногда Ваше приложение посылает команду QUIT
до получения ответа на "конечную точку" сообщения (250 для OK).
.
Похоже, что MTA (MS Exchange) игнорирует команды, полученные до отправки ответа.
Предлагаемые исправления:
1) Увеличьте таймаут ожидания ответа, не отправляйте QUIT перед его получением (даже если объявлено расширение PIPELINING).
.
2) Не пересылайте , если Вы получили ответ 250
на "конечную точку". В этом случае ответственность за доставку сообщения берет на себя MTA (MS Exchange).