Вопросы Теги

Рекомендации, чтобы не выглядеть спамером [дубликат]

На этот вопрос уже есть ответ:

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

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

  2. записи обратного DNS (PTR) в значительной степени необходимы.

  3. Открытые реле неисправны.

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

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

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

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

Довольно хорошо с 1 и 3. Вот где я бы хотел некоторые пояснения / предложения:

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

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

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

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

28
задан 16 July 2009 в 19:26
4 ответа

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

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

7
ответ дан 28 November 2019 в 20:03
  • 1
    Кроме того, Ваш PTRs должен решить вперед к тому же IP (т.е. если у Вас есть PTR для 192.168.0.1 на mail.example.com, mail.example.com должен иметь рекордное указание на 192.168.0.1 –  Cian 16 July 2009 в 19:42
  • 2
    Да, that' s, как я обычно делаю это. –  gravyface 16 July 2009 в 19:53
  • 3
    Haven' t получил любое разъяснение по поводу моего " spoofing" сценарий все же. –  gravyface 16 July 2009 в 19:56
  • 4
    Don' t волнуются о спуфинге. Это естественно... вовлекают себя добавленный к записи SPF. Но спуфинг происходит все время, особенно с жилыми интернет-учетными записями, где ISP вынуждает всех использовать их сервер SMTP. –  Adam Brand 16 July 2009 в 20:15
  • 5
    Да, положительная сторона; я никогда не думал об этом. –  gravyface 16 July 2009 в 21:28

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

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

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

5
ответ дан 28 November 2019 в 20:03

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

2
ответ дан 28 November 2019 в 20:03

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

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

1
ответ дан 28 November 2019 в 20:03

Теги

Похожие вопросы