Время ожидания страницы отправляется, даже если письма отправлены

Эта проблема оставила меня в тупике. Возможно, этот вопрос нужно будет перенести на Server Fault, но есть компонент программирования, поэтому я решил, что я начну. Кроме того, наша команда по инфраструктуре страстно полагает, что все в порядке с их конца, но это не всегда означает ничего.

В любом случае, у меня есть простое действие GET-POST-Redirect, которое отправляет два отдельных письма с помощью пакета Postal nuget, прежде чем перенаправить на страницу успеха - довольно простой материал. Действие isync, и я использую await email.SendAsync() из Postal API.

Когда форма отправляется, первое электронное письмо приходит в мой почтовый ящик мгновенно, но код находится в этой строке await email.SendAsync() в течение 15-20 секунд, прежде чем он перейдет к следующей строке (подтвержденной в отладчике). Затем он отправляет второе электронное письмо, которое снова входит в мой почтовый ящик мгновенно, и снова код зависает на этой строке, независимо от успешной отправки, в течение 15-20 секунд, прежде чем перейти к строке с перенаправлением. В процессе производства эта задержка после отправки электронной почты, объединенная для двух писем, вызывает подключение к reset, прежде чем можно отправить ответ на перенаправление. Конечно, я мог бы просто перетащить страницу, но на самом деле это не устраняет проблему, так как пользователь все-таки заканчивает минутную задержку, прежде чем получить ответ.

Я также попытался отправить электронные письма синхронно только с email.Send(), но происходит такое же поведение. Я просмотрел источник для Postal, и хотя для отправки асинхронной электронной почты некоторые пользовательские оболочки вокруг SMTPClient отправляются по электронной почте, там практически ничего, кроме стандартной старой отправки электронной почты С# с синхронным методом Send.

Он также не связан с сервером, на котором работает сайт, поскольку я могу видеть одно и то же поведение как в производстве, так и при отладке локально (хотя и для соединения с тем же сервером Exchange).

Он действует так же, как и ожидает, что сервер Exchange отправит какой-то "готовый" ответ, но из того, что я знаю о SMTP, он не работает так. Он должен просто отправить письмо на SMTP-сервер и продолжить весело, полагая, что SMTP-сервер действительно сделает то, что он должен делать.

Любые идеи были бы очень благодарны, потому что я даже не уверен, как продолжить отладку этого на данный момент. Что еще я мог проверить или попробовать?

UPDATE

Благодаря предложению @MichaelEvanchik, чтобы опробовать Wireshark, я смог ясно видеть, что на самом деле 30-секундная задержка, вызванная сервером Exchange. Он получает последний бит отправляемого сообщения, а затем через 30 секунд, наконец, отвечает клиенту "Успешно поставил в очередь для доставки". На этом этапе клиент, наконец, ВЫЙДЕТ, и код возобновится. Итак, я возвращаю его обратно в инфраструктуру.

ОБНОВЛЕНИЕ # 2

Таким образом, по-видимому, на разъеме была установлена ​​30-секундная задержка, позволяющая подтвердить, что письмо действительно отправлено, а не просто поставлено в очередь для доставки. Лично я считаю, что в какой-то степени побеждает точка "поставлена ​​в очередь для доставки", но, несмотря на это, мне не нужно подтверждение, что она действительно была отправлена, только что она была получена сервером Exchange, поэтому инфраструктура удаляется задержка.