Мы используем Google Apps для нашей почтовой службы и отправляем клиентам около 15 тысяч писем в день с нашего внутреннего сервера ретрансляции (только исходящий, без открытой ретрансляции).
Недавно мы получили три исходящих IP-адреса, перечисленных в черном списке CBL, и ничего больше.
Первой причиной, о которой он упомянул, было обнаружение почты, похожей на ботнет, но после проверки позже точная причина изменилась на: This IP address is HELO'ing as "localhost.localdomain" which violates the relevant standards (specifically: RFC5321).
Это казалось правильным - и наш внутренний почтовый ретранслятор использует виртуальный SMTP-сервер IIS 6.0 и ретранслирует почту из множества внутренних систем для нас в уведомления клиентов, а также уведомления сервера / системы для внутреннего использования.
Полное доменное имя виртуального SMTP-сервера было локальным именем сервера, которое позволяет просто сказать, было mail.company.local (да, наш внутренний домен .local - вздох). Я изменил полное доменное имя на company.com вместо этого - а затем проверил оригинал шоу и увидел, что запись SPF была указана как = pass, вместо того = neutral. И я подумал, что это исправило.
Другая проблема, которую я вижу, связана с записью обратного DNS. В настоящее время у нас его нет, и CBL отмечает, что запись обратного DNS не требуется, но все же заставляет меня задаться вопросом, не так ли уж плохо было бы получить настройку. Проблема в том, что наша конфигурация будет запутанной при настройке. Наш главный сайт по адресу company.com (который также является нашим доменом электронной почты, из которого мы отправляем электронную почту - company.com) не размещается у нас и имеет совершенно другой диапазон IP-адресов, чем исходящий IP-адрес нашей внутренней системы, с которого мы отправляем почту. Если я установлю обратную запись DNS для company.com на нашем исходящем IP-адресе, обратный поиск не будет соответствовать IP-адресу, который разрешает для company.com - для веб-сайта нашей компании, который не размещен нами. Непонятно - и, возможно, не требуется ... но я пытаюсь исправить это на случай, если это переменная. CBL является нашим основным приоритетом прямо сейчас, и если это не связано (CBL утверждает, что им наплевать на rDNS), то я бы предпочел сейчас побеспокоиться о CBL.
На следующий день снова попал в реестр, и я не совсем уверен, куда идти дальше. Это наш единственный трафик порта 25, идущий с этих IP-адресов, но что-то не совпадает. Я не могу найти какой-либо документ с рекомендациями или элементы для проверки наличия Google Apps + Internal SMTP Relay, только лучшие практики для Google Apps + с использованием вашего внутреннего сервера для ретрансляции smarthost на smtp-relay.gmail.com - что было бы хорошо, но они принимают только 10 тысяч электронных писем в день на своем размещенном реле на каждого клиента.
По сути, я хочу посмотреть, есть ли у кого-нибудь какая-либо общая / передовая конфигурация или элементы, которые можно проверить на кого-то, кто использует Google Apps с внутренним SMTP Relay. Это не обязательно должен быть IIS SMTP - и, честно говоря, я не против переключения его на что-то вроде Postfix или другого (в идеале бесплатного) сервера, который я мог бы запустить для внутренней пересылки почты. Просто хотел выбросить это там. Я ценю любую помощь или вещи, которые нужно проверить заранее - спасибо!
Вы, конечно, можете настроить Google Apps на использование внутреннего ретранслятора SMTP, но, как вы обнаружили, запуск сервера электронной почты полон предостережений. Как правило, я рекомендую передать службу SMTP вашему внешнему провайдеру.
Как минимум, вы хотите настроить:
Похоже, вы можете решить проблему с DNS, просто создав домен третьего уровня - например, smtp.whatever.com а не просто company.com. Вам придется работать с вашим интернет-провайдером, чтобы получить записи PTR, которые будут либо делегированы вашему провайдеру DNS, либо обновлены через поддержку провайдера.
Обратите внимание, что служба ретрансляции smtp от Google принимает более 10 тысяч электронных писем в день; это 10 тысяч получателей, которые ограничены.
Если вы отправляете почту более 10 тыс. Получателей в день, я бы рекомендовал использовать стороннего провайдера почтового хостинга, такого как mailchimp, mailgun и т. Д. И т. Д. В конце концов, проблемы с внутренним ретранслятором SMTP обычно не оправдываются низкая стоимость хостинг-провайдеров в наши дни.