Соответствие кода ошибки SMTP

Question

Я не слишком уверен, что это лучшее место для постановки этого вопроса (или на сервере). Я использую сторонний компонент .NET SMTP для отправки электронной почты непосредственно на почтовый сервер получателя. Мне нужно сделать это, чтобы получить результат доставки в реальном времени. Отправка через другой SMTP-сервер требует, чтобы я получал результат асинхронно с помощью отчетов DSN, что слишком сложно для природы моего приложения.

В любом случае, у меня проблема с целевым SMTP-сервером, возвращающим код ошибки, который не совпадает с сообщением об ошибке. Таким образом, я не могу пометить доставку как жесткий или мягкий отскок. Например. Код ошибки ответа - 450 (означает, что почтовый ящик недоступен), но ответное сообщение связано с тайм-аутом. Когда я снова отправляю то же сообщение, оно прошло. Очевидно, проблема с тайм-аутом для предыдущей отправки.

Я также понял, что проблема может быть не в принимающем SMTP-сервере, а в брандмауэре / прокси (как вы его называете), который защищает сервер.

Кто-нибудь сталкивался с подобной проблемой и как с ней бороться.

PS: я постараюсь предоставить больше подробностей из своего журнала, когда вернусь в свой офис.

Answer 1

Звучит как грейлистинг. Что забавно, потому что, когда я начал читать ваш вопрос, это было одним из первых препятствий, которые я мог предвидеть.

Greylisting - это метод защиты от спама, который работает путем мягкого сбоя доставки на основе того, что законные MTA попытаются повторно отправить сообщение через определенный промежуток времени. К сожалению, две вещи не работают в вашу пользу:

• Период серых списков может быть выбран случайным образом. Это означает, что иногда потребуется несколько повторных попыток, прежде чем сообщение будет принято для доставки.
• Хотя коды 4xx всегда должны рассматриваться как программные сбои и используются для этой цели, серверу не требуется сообщать, что это происходит из-за серого списка. Некоторые будут так добры, а некоторые нет.

То, как вы справитесь с этим, будет зависеть от того, считаются ли программные сбои окончательным отказом для целей того, что делает ваше приложение. Если это не так, то вам придется разработать надежные очереди и повторные попытки. Мой честный совет вам будет заключаться в том, что, вероятно, проще внедрить надежную проверку подлинности DSN или проверки журналов, чем изобретать свой собственный MTA, совместимый с RFC.