У меня есть приложение asp.net, которое рассылает электронные письма. SMTP-сервер - iis6. Электронные письма отправляются от имени пользователей нашего приложения, и у них разные доменные имена. Большинство провайдеров электронной почты, таких как Gmail и Yahoo, принимают электронные письма, но некоторые из них не принимают, например AOL.
Это сообщение, которое пользователи получают от нашего SMTP-сервера через несколько минут:
Тема: Уведомление о статусе доставки (сбой) Это автоматически сгенерированное уведомление о статусе доставки. Невозможно доставить сообщение следующим получателям из-за невозможности успешно подключиться к целевому почтовому серверу.
Сообщение, которое вы опубликовали, - это сбой при подключении, что не обязательно означает, что они отказались от вашей электронной почты, скорее всего, это проблема с DNS или другая проблема с подключением. Вот некоторые вещи, которые следует проверить / подумать:
Можете ли вы проверить свой сервер приложений, чтобы убедиться, что он правильно разрешает записи DNS и MX для домена, который вы пытаетесь отправить по электронной почте.
Можете ли вы использовать telnet с этого сервера в эти домены, если да, то какой ответ вы получите?
Есть ли у доменных имен, с которых вы отправляете записи, есть записи spf, и если да, то включен ли IP, с которого вы отправляете, в запись spf?
Правильно ли настроены обратные записи DNS для IP, с которого вы отправляете, для доменов, которые вы отправляете?
В идеале, прежде чем кто-либо действительно сможет дать вам окончательный ответ на проблему, вам нужно иметь telnet или что-то в этом роде и получить ответ сервера, в котором рассказывается, почему вы вообще не можете подключиться.
Один из возможных вариантов - эти серверы помечают вашу электронную почту как спам. Даже если это не так действительно спама, многие поставщики услуг электронной почты блокируют сообщения, которые не совсем правильны или адресованы большому количеству людей.
Однажды мы столкнулись с этим, и нам пришлось связаться с несколькими провайдерами, чтобы попасть в белый список. После того, как мы связались с ними и объяснили нашу программу электронных купонов (согласие на участие, полностью соответствует CAN-SPAM) и предоставили им подробности, они добавили нас в белые списки.
Есть много вещей, которые могут пометить вас как спамера. Вот пара, которую стоит проверить:
Вот несколько ссылок, которые могут оказаться полезными
http://searchwarp.com/swa209211.htm
http://www.wilsonweb.com/05/020529b.htm
http://searchdomino.techtarget.com/news/article/0,289142,sid4_gci1192720,00.html (не совсем для Domino, несмотря на URL-адрес)
С кем вы размещаете свое приложение? У меня были проблемы с общими хостами, когда все сайты, размещенные на их серверах, были занесены в черный список в дыру для спама.
Тот факт, что ваше приложение не рассылает спам, не означает, что другого приложения на общем хосте нет. Поскольку это общий хост, весь трафик smtp поступает из одного источника, который может быть заблокирован.
Сообщение, которое вы опубликовали, - это сбой при подключении, что не обязательно означает, что они отказались от вашей электронной почты, скорее всего, это проблема с DNS или другая проблема с подключением. Вот некоторые вещи, которые следует проверить / подумать:
Можете ли вы проверить свой сервер приложений, чтобы убедиться, что он правильно разрешает записи DNS и MX для домена, который вы пытаетесь отправить по электронной почте.
Можете ли вы использовать telnet с этого сервера в эти домены, если да, то какой ответ вы получите?
Есть ли у доменных имен, с которых вы отправляете записи, есть записи spf, и если да, то включен ли IP, с которого вы отправляете, в запись spf?
Правильно ли настроены обратные записи DNS для IP, с которого вы отправляете, для доменов, которые вы отправляете?
В идеале, прежде чем кто-либо действительно сможет дать вам окончательный ответ на проблему, вам нужно иметь telnet или что-то в этом роде и получить ответ сервера, в котором рассказывается, почему вы вообще не можете подключиться.
Откуда приходит отчет о недоставке, предположительно с вашего SMTP-сервера IIS, хотя я не очень часто работаю с IIS SMTP, поэтому я не уверен, может ли SMTP-сервер IIS генерировать отчеты о недоставке.
В любом случае не забудьте включить ведение журнала в свойствах SMTP-сервера IIS, а затем проверьте журналы после получения отчета о недоставке. Если в файле журнала нет записей, соответствующих электронному письму, которое сгенерировало отчет о недоставке, я бы заподозрил проблему с тем, что DNS-клиент сервера IIS может разрешить запись MX для домена получателя. Если в файле журнала есть записи, соответствующие электронному письму, сгенерировавшему отчет о недоставке, то коды состояния SMTP в файле журнала должны подсказать вам, что происходит.
Убедитесь, что вы указываете отправителя и обратный путь в заголовке письма. Прочтите это: Отправлять электронную почту от имени клиентов
Сначала вы должны проверить, действительно ли вы можете подключиться на целевой почтовый SMTP-сервер с вашего внутреннего сервера. Вы можете сделать это telnet <destination server> 25 и посмотрите, получите ли вы приветствие. Иногда в качестве политики предотвращения спама в некоторых местах фильтруются соединения порта 25.
Еще одна потенциальная проблема с почтой - это обратная настройка DNS. Иногда целевые серверы проверяют, кто вы Запрос проверять исходный IP-адрес домена, который вы представляете. Возможно, вам потребуется настроить это у своего поставщика DNS.
Некоторые почтовые серверы ограничивают ваши соединения, пока вы не установите этот IP-адрес в качестве надежного отправителя. Это требует нескольких вещей - вы должны придерживаться лучших правил настройки:
Вам также будет лучше, если вы отправите IP-адреса в различные белые списки / списки массовых отправителей, такие как AOL и yahoo.
Количество пользователей, которые сообщают о вас как о спаме, и количество плохих адресов электронной почты, на которые вы отправляете, также повлияют на вашу способность отправлять сообщения.
Habeas и Returnpath также могут дать вам дополнительные «очки», чтобы повысить ваш рейтинг за спам.
Наконец, если вы отправляете электронные письма от пользователей, не входящих в ваш домен, у вас, вероятно, всегда будут проблемы. Вы можете попробовать отправить с определенного адреса электронной почты и просто изменить имя отправителя и адрес для ответа в электронном письме.
Возможно, я опаздываю на день, а доллар не хватает, но я недавно столкнулся с этим, и, увы, возник ваш вопрос. У меня оказалось плохое разрешение DNS из-за MalwareBytes.
Я видел, как в очереди IIS SMTP болтаются электронные письма, и в конце концов это не удалось. Вот некоторые вещи, которые я сделал и в конечном итоге выяснил причину.
Для нас это было специально для одного домена.
Я запустил захват пакетов на нашем брандмауэре, чтобы посмотреть, могу ли я увидеть трафик, исходящий с сервера электронной почты. Это было не так, чтобы я знал, что пакеты останавливаются в сети. Я также не видел никаких сообщений о блокировке в журналах брандмауэра, специально блокирующих трафик.
Шаг 1: Перейти к MXToolbox и подключите их доменное имя для MX Lookup Tool. Это даст вам правильный IP-адрес, который вы проверите на шаге 2.
Вы также должны указать здесь свой общедоступный IP-адрес и запустить проверку черного списка и проверку SPF.
Шаг 2: Бегать NSLOOKUP из командной строки на SMTP-сервере.
>>nslookup -type=mx domain.com
Server: domaincontroller1.mydomain.com
Address: 192.168.1.6
Non-authoritative answer:
domain.com MX preference = 1, mail exchanger = mail.domain.com
mail.domain.com internet address = 168.144.68.87
Это была наша проблема. Наш локальный DNS-сервер разрешал домен в IP-адрес 127.x.x.x. Это было немедленно идентифицировано как проблема, и мы отследили ее до проблемы с MalwareBytes, не позволяющей DNS-серверу разрешать домен. Нам пришлось отключить MWB, очистить кеш DNS, а затем снова запросить домен, чтобы получить правильный IP.
Non-authoritative answer:
domain.com MX preference = 10, mail exchanger = mx.domain.com
mx.domain.com internet address = 127.42.0.2
mx.domain.com internet address = 127.42.0.4
mx.domain.com internet address = 127.42.0.5
Шаг 2: Telnet к домену почтового обменника через порт 25. Вы должны увидеть следующее. Попробуйте набрать EHLO domain.com если он подключается, и вы должны увидеть еще несколько всплывающих окон.
>> telnet mail.domain.com
220 xmail03.domain.com ESMTP 648143d3667b3045487bb901cdbbf649
EHLO domain.com
250-xmail03.domain.com
250-PIPELINING
250-SIZE 100000000
250-DATAZ
250-STARTTLS
250-AUTH LOGIN PLAIN
250 8BITMIME
Если не подключается или просто выдает черный экран, нажмите ENTER. Если он выводит вас обратно в командную строку, он не подключается или сервер отказывается от него.