Назад | Перейти на главную страницу

Почему электронные письма, отправленные из моих приложений, помечаются как спам?

У меня есть 2 веб-приложения, работающие на одном сервере. Первый - www.nimikri.com, второй - www.hourjar.com. Оба приложения имеют один и тот же IP-адрес (75.127.100.175). Мой сервер находится через компанию виртуального хостинга.

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

Я произвел обратный поиск своего IP-адреса в DNS и получил следующие результаты:

100.127.75.in-addr.arpa NS DNS2.GNAX.NET.

100.127.75.in-addr.arpa NS DNS1.GNAX.NET.

Должен ли обратный поиск DNS указывать на nimikri.com и hourjar.com, или они настроены правильно?

Я заметил в заголовке письма эти 2 строки:

Получено: от nimikri.nimikri.com

От: Hour Jar <Invite@hourjar.com>

Могут ли другие доменные имена заставить Gmail думать, что это спам?

Вот заголовок одного из писем. Пожалуйста, дайте мне знать, если это выглядит как красный флаг для спама. Спасибо.

Delivered-To: bapublic@gmail.com
Received: by 10.231.157.85 with SMTP id a21cs54749ibx;
        Sun, 25 Apr 2010 10:03:14 -0700 (PDT)
Received: by 10.151.130.18 with SMTP id h18mr3056714ybn.186.1272214992196;
        Sun, 25 Apr 2010 10:03:12 -0700 (PDT)
Return-Path: <invite@hourjar.com>
Received: from nimikri.nimikri.com ([75.127.100.175])
        by mx.google.com with ESMTP id 28si4358025gxk.44.2010.04.25.10.03.11;
        Sun, 25 Apr 2010 10:03:11 -0700 (PDT)
Received-SPF: neutral (google.com: 75.127.100.175 is neither permitted nor denied by best guess record for domain of invite@hourjar.com) client-ip=75.127.100.175;
Authentication-Results: mx.google.com; spf=neutral (google.com: 75.127.100.175 is neither permitted nor denied by best guess record for domain of invite@hourjar.com) smtp.mail=invite@hourjar.com
Received: from nimikri.nimikri.com (localhost.localdomain [127.0.0.1])
 by nimikri.nimikri.com (8.14.3/8.14.3) with ESMTP id o3PH3A7a029986
 for <bapublic@gmail.com>; Sun, 25 Apr 2010 12:03:11 -0500
Date: Sun, 25 Apr 2010 12:03:10 -0500
From: Hour Jar <invite@hourjar.com>
To: bapublic@gmail.com
Message-ID: <8441961.01272214990893.JavaMail.mailer@nimikri.com>
Subject: brian@hourjar.com has invited you to New Event
MIME-Version: 1.0
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

ChrisF, вот тело сообщения:

<h1>Hour Jar</h1><h3>New Event</h3><p>To view the event, please go to hourjar.com/event?event.id=2&guest.id=2</p>

Чайтанья, да, каждое сообщение с моего сервера отправляется в спам.

BillThor, спасибо, что ответили на мой вопрос о rDNS. Я исправлю указанные вами проблемы и посмотрю, помогут ли они.

Джефф недавно опубликовал в своем блоге сообщение под названием Итак, вы хотели бы отправить электронное письмо (через код) в котором подробно описывается ряд методов, которые вы должны использовать, чтобы гарантировать доставку вашего письма. Коротко:

  • проверьте свою обратную запись DNS PTR
  • настроить DomainKeys для подписи исходящей электронной почты
  • настроить SenderID
  • проверьте, что вы сделали

Вам не хватает сопоставления rDNS. Это указывает на то, что ваш почтовый сервер неправильно настроен, и вы на пути к тому, чтобы быть отмеченным как СПАМ. Отсутствие записи SPF в DNS не поможет, но и не сильно помешает.

Нестандартное форматирование тела письма также создаст проблему. По умолчанию в Unix используется завершение строки с переводом строки. Стандарт требует завершения перевода строки возврата каретки. Также вам необходимо убедиться, что длина строк не превышает 80 символов.

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

SPF и ключи домена на самом деле не работают для того, чтобы ваши сообщения меньше походили на спам - они довольно часто есть у спамеров.

Главное, что нужно сделать:

  • У вас правильно настроен обратный DNS для почтового ретранслятора.
  • Ваше сообщение НЕ ЯВЛЯЕТСЯ СПАМом
  • Вы не передаете почтовый ретранслятор никому, кто действительно рассылает спам (это ключевой момент)
  • Вы не подделываете и не придумываете немаршрутизируемый адрес (а) отправителя (особенно отправителя конверта). Это кажется очевидным, но удивительно, как много людей пытаются отправить почту с веб-сервера @ localhost и задаются вопросом, почему она никогда не приходит. Задайте отправителем конверта домен, который вы контролируете; убедитесь, что если у вас настроен SPF, отправка разрешена. Не отправляйте сообщения, созданные одним из ваших пользователей с их адресом в качестве отправителя конверта (обязательно установите ответ, если хотите)

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

Если у вас есть проблема с репутацией, но вы не можете избавиться от нее, может быть проще выделить новый IP-адрес (но убедитесь, что в будущем вы не рассылаете с него спам - даже случайно)

Мы также видели проблемы, когда некоторые заблуждающиеся системные администраторы решают, что блоки IP, выделенные определенными реестрами IP, не «достаточно хороши» для отправки им почты. Эти введенные в заблуждение люди часто работают на крупные корпорации США и решают, что все IP-адреса, не относящиеся к ARIN, используются спамерами. К сожалению, нет никакого способа обойти это, кроме использования ARIN-зарегистрированного IP-пространства для ваших реле для ретрансляции сообщений этим проигравшим.

Отказ от ответственности: я работаю в охранной компании, которая фильтрует спам.

Убедитесь, что ваша система не находится в черном списке: http://www.mxtoolbox.com/blacklists.aspx

Публикуйте записи SPF для своего доменного имени, а также ключи домена, если можете (в большинстве случаев это не поможет, но почему бы и нет).

  • Избегайте любых строк, которые выглядят как спам.

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

  • Отправляйте отдельные сообщения каждому получателю вместо копий.

Лучше отправлять отдельное сообщение каждому получателю, чем использовать несколько адресов в поле BCC, потому что многие фильтры спама (и многие интернет-провайдеры) автоматически помечают нескольких получателей как спам.

  • Если возможно, отправляйте через почтовый сервер вашего интернет-провайдера, а не через локальный SMTP-сервер.

Сообщения, отправленные с почтового сервера, работающего на вашем компьютере, могут быть помечены как спам, потому что некоторые почтовые серверы будут пытаться связаться с исходным IP-адресом отправляющего сервера (что приведет к ошибке с локальным IP-адресом).

  • Попробуйте с меньшими партиями электронных писем.

Похоже, что некоторые из крупных почтовых хостов, такие как Hotmail, распознают, когда идентичное сообщение отправляется большому количеству подписчиков одновременно, поэтому вам следует чередовать доставку своих сообщений [...], чтобы отправлять сообщения маленькими партии.

  • Сведите к минимуму использование вложений.
  • Убедитесь, что компьютер, отправляющий электронное письмо, имеет обратную PTR-запись.

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

  • Настройте почту, идентифицированную с помощью ключей DomainKeys, в своем DNS и коде.

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

  • Настройте запись SenderID в своем DNS.

Если честно, SenderID - это немного «приятно иметь» по сравнению с двумя вышеупомянутыми. Но если вы зашли так далеко, то можете и дальше идти. SenderID, хотя и немного устаревший и вроде… ориентированный на Microsoft / Hotmail… не требует особых дополнительных усилий.

SenderID не сложен. Это еще одна запись TXT DNS в корне, скажем, example.com, которая содержит специально отформатированную строку, документирующую все разрешенные IP-адреса, с которых может приходить почта.

Источники и дополнительная информация: