Smtp, отправляющие через Exchange некоторые письма, не завершаются, но все еще отправляют - почему?

У меня есть приложение, которое посылает 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/

Добрался, чтобы попытаться получить протестированный сначала.

1
задан 16 April 2015 в 15:34
2 ответа

Причиной проблемы был параметр «DelayedAck» на транспорте Exchange. Принимающий сервер на «другой стороне» ретранслятора слишком долго отвечал (более 30 секунд), поэтому время ожидания соединения, которое мы устанавливали, истекло, и диалог SMTP так и не завершился. (этот URL-адрес, который я добавил в вопросе).

Администратор Exchange отключил DelayedAck на внутреннем транспорте, и проблема исчезла.

Мы могли / должны были изменить наше приложение, чтобы обойти это, но у нас есть компонент третьей части из-за чего это было сложно, и поэтому мы не можем проверить, работает ли это.

1
ответ дан 3 December 2019 в 18:40

Кажется, что иногда Ваше приложение посылает команду QUIT до получения ответа на "конечную точку" сообщения (250 для OK).
. Похоже, что MTA (MS Exchange) игнорирует команды, полученные до отправки ответа.

Предлагаемые исправления:
1) Увеличьте таймаут ожидания ответа, не отправляйте QUIT перед его получением (даже если объявлено расширение PIPELINING).
. 2) Не пересылайте , если Вы получили ответ 250 на "конечную точку". В этом случае ответственность за доставку сообщения берет на себя MTA (MS Exchange).

.
2
ответ дан 3 December 2019 в 18:40

Теги

Похожие вопросы