Почему я не могу узнать, не удается ли отправить почту?

Question

Я реализую CRM, где мне нужно отправлять почту своим клиентам. Конечно, я нашел проблему, которую многие, похоже, находят: вы не знаете, была ли почта успешно отправлена. Тем не менее, я не понимаю, почему именно так.

Во-первых, я понимаю, что тестирование для электронной почты может быть выполнено только путем фактического общения с сервером, контролирующего электронную почту (используя записи MX, а затем команды MAIL FROM и RCPT TO), и даже тогда сервер может отказаться отвечать эти просьбы. Я думаю, что у меня это ясно, и, например, так кажется, что работают такие сайты, как http://verify-email.org/.

Затем я прочитал от this comment к ответу здесь, что SmtpClient .NET в делает то же самое, чтобы убедиться, что сообщение может быть отправлено, и если это не удается, то бросает SmtpFailedRecipientsException. Поэтому я, кажется, получаю это ...

Но тогда я решил попробовать отправить письмо на недопустимый адрес: asdf@asdf.asdf (надеюсь, что .asdf не является одним из тех недавно одобренных новых TLD). Я использую его на http://verify-email.org/, и он говорит, что он недействителен (потому что нет даже записи MX, очевидно), но когда я использую SmtpClient, он преуспевает! Зачем?

Затем я прочитал this other question (я понимаю, что я не первый спрашиваю об этом), где говорится, что SMTP является «хранилищем и пересылкой» протокола (что означает, что он не может попытаться отправить сообщение сразу), который я также понять ... но в то же время я нахожу противоречивым.

Как можно asdf.asdf сохранить и передать сообщение, когда его вообще нет? Почему http://verify-email.org/ (и другие веб-службы, я не пробовал только этот) получить немедленный ответ, в то время как SmtpClient нет? Что они делают по-другому?

Answer 1

Давайте разберемся, как протекает почта (чрезмерно упрощенный):

Your App > Your Mail Server > Destination Mail Server > Recipient 
       |          ^
       |           | 
       + ---- if recipient on the same server ----+ 

Итак, когда вы отправить письмо получателю, который находится на том же сервере, например, если в том же домене, что и ваш Сервер Exchange является внутренне, тогда Сервер знает, существует ли ваш получатель или нет, и может сразу ответить вам.

Однако при отправке почты внешнему получателю ваш сервер отправит электронное письмо на почтовый сервер (указанный в записи MX имени домена). Когда это происходит, происходят две вещи:

1. Вы сервер с радостью принимает его от вас, и посылает вам принятым для доставки ACK сразу
2. Затем он пытается переслать почту на внешний сервер на основе его текущей очереди

Это не заставит ваше приложение ждать бесконечно, пока очередь не очистится, и она фактически отправит сообщение. Если бы это было так, есть вероятность, что ваше приложение может ждать до 4 дней!

Что касается другого вопроса/ответа, на который вы ссылаетесь, они предполагают, что получатель находится на одном сервере.

Как правило, при отправке писем с использованием smtpClient через ваше приложение вы не подключаетесь напрямую к серверу получателя. Вы используете либо интеллектуальный хост, либо собственный почтовый сервер. Вы проверяете подлинность на своем сервере, который затем будет передавать вашу почту.Способы использования VRFY и/или RCPT TO будут работать против вашего сервера. Пока получатель находится на одном сервере, вы (smtpClient, если на то пошло) будут работать против вашего собственного сервера и который в состоянии ответить. Однако, когда вы передаете свою почту для внешнего сервера, ваш сервер будет принимать вашу почту только и не сможет ответить.

Если вам нужен ответ, вам необходимо будет напрямую подключиться к целевому серверу и выдать команды SMTP. В этом случае вы можете получать или не получать ответ. На этот вопрос также четко ответил ответ. В качестве меры защиты от спама почти все серверы используют tarpitting (другими словами, задержку или черную дыру) для защиты от перечисления своих пользователей.

Это не имеет значения, если вы отправляете почту «someone@example.com» или «noone@nowhere.xyz», до тех пор, как это внешний сервер. Иллюстрация, приведенная выше, слишком упрощена. На самом деле может существовать несколько промежуточных сервисов, которые разрешают DNS для вашего почтового сервера.

Вы привели пример «http://verify-email.org/». Но вы читали, что там написано на домашней странице?

Этот инструмент проверки подлинности электронной почты фактически подключается к почтовому серверу, а проверяет, существует ли почтовый ящик или нет.

Что означает, что он напрямую подключается к серверу MX домена, к которому вы пытаетесь отправить почту. Даже вы можете это сделать. Единственное отличие в том, что в реальной жизни наши приложения не могут этого сделать. Вы подключаетесь к локальному smarthost/relay.

Кроме того, на главной странице этого сервиса говорит:

Что проверяется: Формат: "name@domain.xxx"; Допустимый домен: Недопустимый "somebody@new.york"; Действительный пользователь: проверьте, является ли пользователь; и почтовый ящик действительно существует

Это означает, что, прежде чем пытаться соединиться с сервером назначения, эта служба выполняет проверку формата (возможно регулярное выражение), а затем делает DNS поиска, чтобы проверить, если домен является действительным или а затем пытается подключиться к целевому серверу только после этого.

Помните, что даже эта служба не сможет точно сказать, что вы хотите о существовании пользователя для всех почтовых служб. Например, я использовал tarpitting на моем почтовом сервере, и, следовательно, даже эта служба не сможет сказать вам, существует ли я или нет. Мой почтовый сервер никогда не ответит. «verify-email.org« всегда будет возвращать вам ok.

BTW: "verify-email.org" будет чаще, чем не вернуть вам это:

550 5.7.1 Service unavailable; Client host [verify-email.org] blocked using Spamhaus; 

Этот сервис уже заблокирован несколькими провайдерами анти-спам сервис !!

Надеюсь, что это поможет.

.