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

Жалобы на управление доставкой электронной почты

Вопрос, который у меня есть, может быть более принципиальным, чем что-либо еще, но вот моя дилемма.

Я управляю почтовой системой для небольшой компании (около 20 почтовых пользователей). У нас есть простое буквенное доменное имя .com через Network Solutions. Наша служба электронной почты размещена в Google Apps.

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

Один клиент связался со своим провайдером электронной почты по поводу проблемы. Поставщик рекомендовал нам отправить форму для включения в белый список их домена.

Вот где начинается моя проблема. Я чувствую, что это спуск по скользкой дорожке. Разве это не подрывает сам принцип электронной почты? Если это уместное действие в этих ситуациях, чем это закончится? Теоретически (следуя этой модели) можно было бы утверждать, что в конечном итоге нужно будет сначала «занести в белый список» (или более подходящее название «аутентифицировать») себя на почтовом хосте, прежде чем отправлять какие-либо сообщения. Более того, что мешает «плохим» спамерам делать то же самое ...? Мы только что прошли полный круг.

Я знаю, что избегать мер по борьбе со спамом - это большая игра в кошки-мышки, но я думаю, что это неправильный способ «исправить» проблему. Стандарты электронной почты гласят, что сообщения не должны исчезать просто так. У меня проблема с поддержкой модели, в которой говорится "ты должен сделать <это> чтобы убедиться, что ваши электронные письма не игнорируются ".

У меня есть идея позвонить провайдеру и озвучить свою жалобу, хотя я чувствую, что она, вероятно, останется без внимания. Я что-то упустил? Это приемлемый подход к проблемам со спамом в электронной почте? какой должен Я делаю?

Здесь мало кто может сказать, чтобы вам помочь - ваша проблема не техническая, как вы упомянули: это вопрос принципа.

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

Я не обязательно согласен с этим сам - это противоречит духу взаимного сотрудничества, благодаря которому электронная почта (и Интернет в целом) работает, - но с учетом того факта, что примерно 50% почты, которая приходит мой домены являются спамом и отбрасываются путем фильтрации. Я это понимаю. Фактически, когда мы получаем жалобы на то, что клиенты не могут отправлять нам электронные письма, мы следуем аналогичным процедурам при сборе действительного списка отправляющих серверов и внесении их домена в белый список. Это некрасиво, но позволяет контролировать объем нежелательной почты во входящих.

В качестве утешительного приза я предлагаю вам копию лекции по электронной почте, которую я читаю новым специалистам службы поддержки, когда они присылают мне свой первый «X говорит, что Y не может получать от них электронную почту» - это определенно не то, что вы можете сказать своим клиентам / пользователей, но это может рассмешить вас в мрачные времена устранения неполадок электронной почты. Не стесняйтесь приукрашивать по мере необходимости :-)

EMail is not a reliable delivery system.  There is no guarantee that any message
sent by party A will be received by its intended recipient, or by anyone at all.

EMail depends upon the cooperation of the sender & recipient's servers, as well
as potentially dozens of other servers that will handle your message along the way.
Each server has its own standards for what is or is not an acceptable message, and
may delay or discard your email for any reason, or for no reason at all, and they
probably will not tell you (or your sysadmin) what they're doing.

If your correspondence is time-sensitive or critically important email may not be
the best medium. Consider a telephone call, or if sending lots of documents
FedExing a CD.

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

  • Запись PTR отсутствует или неверна.
  • Запись для PTR не указывает на исходный IP-адрес.
  • Имя, используемое в команде HELO, имеет недопустимый домен верхнего уровня, например local, lan или localdomain.
  • Имя, используемое в команде HELO, не имеет записи A.
  • Запись A для имени в команде HELO не возвращает используемый IP-адрес.
  • Нет записи SPF для домена, используемого в команде HELO.
  • Для домена отправителя конверта не настроен SPF.
  • SPF для домена отправителя конверта запрещает использование IP-адреса, используемого для отправки электронной почты.
  • Домен не указан на DNSWL.org.
  • Настройка адреса почтового сервера в качестве домена второго уровня (example.com), а не домена третьего или четвертого уровня (mail.example.com).
  • Не принимает почту к почтмейстеру.

Избегайте всего вышеперечисленного, и у вас будет намного больше шансов получить почту.

РЕДАКТИРОВАТЬ: Я обнаружил, что у Port25 Solutions Inc. есть очень хорошая служба автоматической проверки, указанная на их E-mail аутентификация страница. Большое спасибо им за прекрасное обслуживание. Он предназначен для проверки подписей DKIM, но дает отличную обратную связь по большинству пунктов, перечисленных выше. Зайдите в раздел ресурсов Port25 и используйте соответствующий адрес электронной почты, чтобы получить результаты по почте на желаемый адрес электронной почты. Помните, что если вам нужно внести изменения в DNS, это может занять день или около того, чтобы они отразились во всех кэшах. В худшем случае значение параметра Time to Live должно быть в два раза больше.

Я понимаю ваше разочарование, но я также понимаю, почему постоянно увеличивающееся число систем перестает работать со спамом. Так обстоят дела, и нравится нам это или нет, мы просто должны с этим жить. Спам - серьезная проблема, на которую тратятся огромные суммы денег.

В большинстве случаев вам не нужно запрашивать белый список, если ваша собственная система хорошо настроена. Под хорошей конфигурацией я подразумеваю наличие вещей, которые на самом деле могут не требоваться никакими стандартами, но ожидаются при обычном использовании. Такие вещи, как правильные записи SPF, DKIM и / или DomainKeys и т. Д.

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