☰

Лучшие практики, которые помогут вам не выглядеть спамером

tag-icon • tag-icon email-server spam spf spam-filter mx-record
Лучшие практики, которые помогут вам не выглядеть спамером

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

  1. Записи SPF хороши, но не все службы/программы фильтрации спама (SFSS) используют их.

  2. Обратные записи DNS (PTR) практически необходимы.

  3. Открытые реле — это плохо.

    (Вот «другие советы», которые я прочитал):

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

  5. Ваш сервер должен использовать HELO FQDN.of.your.mail.server.com при обращении к другим почтовым серверам.

  6. Записи хоста A в записях MX должны быть (или разрешаться в IP-адрес) вашим FQDN.of.your.mail.server.com

Чувствую себя довольно хорошо по поводу пунктов 1 и 3. Вот здесь я хотел бы получить некоторые разъяснения/предложения:

2 и 4: Я много копал, и это, похоже, неверно, поскольку большинство спам-фильтров ищут PTR вобщийи один, который не назначен интернет-провайдером в качестве общего; похоже, домен, с которого вы отправляете почту, не имеет к этому никакого отношения (т. е. если бы у вас было два домена, которые вы использовали для почты, вам пришлось бы отправлять почту с двух IP-адресов с PTR для каждого?)

  1. Это имеет смысл, но разве это имеет значение, во что преобразуется это FQDN? Должно ли оно преобразовываться в IP-адрес, который в данный момент отправляет указанный HELO?

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

А как насчет отправки от имени другого домена, для которого вы не являетесь уполномоченным? У меня есть несколько клиентов (some.branchdomain.tld), которые должны отправлять почту как @some.corporatedomain.tld, даже если указанная корпоративная штаб-квартира не настроит для них ретранслятор/смартхост. corporatedomain.tld может создавать записи SPF, чтобы показать, что some.branchdomain.tld разрешено отправлять почту, но будет ли это все еще считаться «спуфингом», особенно если указанная SFSS не проверяет записи SPF? Стоит ли мне беспокоиться об этом?

решение1

Я могу поручиться, что #2 (обратный PTR) важен, но не #4 (домен почтового сервера, соответствующий "from"). Мы постоянно настраиваем почтовые серверы, и большинство почтовых хостов на самом деле даже не заботятся о #2.

Главной занозой всегда является AOL, и они перечисляютстандартыможете вычеркнуть.

решение2

Помимо вашей строки HELO и записей DNS PTR, о которых упоминалось выше, основная часть вещей, которые могут помочь, будет связана с контентом, а не с сервером отправки.

  • Не отправляйте HTML-сообщения, если можете этого избежать.
  • Не включайте подозрительные фразы («нажмите, чтобы отписаться», «конфиденциальность важна» и т. п.)
  • Не используйте заголовки «ответить», отправляйте с того адреса, на который хотите получать ответы.
  • ...и многое другое. Прочитайте набор правил SpamAssassin для получения дополнительных хороших примеров.

Что касается вашего вопроса «имеет ли значение, во что преобразуется это полное доменное имя?», то это полностью зависит от того, что делает принимающий почтовый сервер, и, конечно, это может варьироваться, но обычно вы не найдете слишком много почтовых серверов, полагающихся на поиск полного доменного имени как на жесткое и быстрое правило, поскольку можно настроить несколько машин по принципу циклического перебора.

решение3

А как насчет правил по содержанию? Разумное использование электронной почты поможет вам избежать пометки как спамера в различных системах. Обучите своих клиентов не пересылать "смешные вещи" всем в своем списке контактов, не подписываться на рассылки по электронной почте или информационные бюллетени и использовать разумные механизмы защиты от вредоносных программ, чтобы не стать частью спам-ботнета...

решение4

4 на самом деле полностью ложно. Вы могли бы думать больше в духеСтруктура политики отправителя, в котором DNS для домена содержит запись, которая указывает, каким SMTP-серверам разрешено отправлять почту с заголовком From: с этим доменным именем. Но дело в том, что размещенные домены обычно имеют исходящие почтовые серверы, которыенетто же самое, что и доменное имя, но провайдер отправителя. Например, если у вас myvanitydomain.com и адрес электронной почты[email protected], но вы используете Sprint в качестве интернет-провайдера, вам обычно приходится использовать сервер исходящей почты Sprint для отправки электронной почты. Есть способы обойти это (например, веб-почта или аутентификация POP-then-SMTP), но это хороший пример.

Что касается "как сделать так, чтобы электронная почта не выглядела как спам", ну... вы не делаете ее похожей на спам, конечно. Тот факт, что вы даже рассматриваете возможность использования открытого ретранслятора, звучит... подозрительно. Я не могу придумать ни одной законной причины, по которой вы дажехотетьдо, когда у каждого интернет-провайдера есть SMTP-сервер. Если вы платите за хостинг сервера, с которого отправляете почту, то единственный способ не допустить попадания вашего IP-адреса в списки различных органов — не рассылать спам.

Связанный контент