Русский
Русский
English
Статистика
Реклама

Smtp

Перевод Окей, Гугл, опубликуй свои секретные ключи DKIM

20.11.2020 12:14:59 | Автор: admin


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

В этом посте раскрывается вопрос Domain Keys Identified Mail (DKIM), безвредного крошечного антиспам-протокола, который каким-то образом превратился в монстра. Моя просьба проста, вкратце её можно сформулировать так:

Уважаемый Google: пожалуйста, реализуйте периодическую ротацию и публикацию ваших секретных ключей DKIM. Благодаря этому весь Интернет станет намного безопаснее, ведь у преступников пропадёт сильный стимул кражи электронных писем и организации их утечек. Исправление практически не будет вам ничего стоить и выбьет из рук воров мощнейший инструмент.

Это краткая версия. Ниже представлена более подробная.

Что это за DKIM, и как он защищает мою электронную почту?


Электронная почта была создана в те времена, когда Интернет ещё назывался ARPANET. Это были гораздо более спокойные дни, когда современные меры безопасности, да и, честно говоря, само понятие того, что Интернету потребуется безопасность, оставались далёким, научно-фантастическим будущим.

Первые протоколы электронной почты (типа SMTP) работали на основе системы доверия. Электронные письма могли поступать на ваш почтовый сервер непосредственно с почтового сервера отправителя или передаваться через посредников. Как бы то ни было, если в письме указано, что оно пришло от вашей подруги Алисы, то вы верите, что оно действительно от Алисы. Зачем кому-то вообще лгать о подобном?

Широкое распространение электронной почты показало, что такое отношение дало сильный сбой. Всего за несколько лет пользователи Интернета узнали, что есть множество людей, желающих солгать о том, кем они являются. В большинстве своём это были почтовые спамеры, находившиеся в восторге от того, что SMTP позволял им выдавать себя почти за любого отправителя вашу подругу Алису, вашего босса, налоговую службу, дружелюбного нигерийского принца. Без надёжного механизма, способного предотвратить рассылку такого спама, электронная почта оказалась ужасно уязвимой к спуфингу.

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

Решение задачи авторизации источника, как и почти остальные исправления базовых Интернет-протоколов, напоминало ремонт изолентой. Поставщиков услуг почты попросили подключить (дополнительное) новое криптографическое расширение под названием Domain Keys Identified Mail, или DKIM. DKIM запекает в каждое отправленное почтовым сервером письмо цифровые подписи. Когда почтовый сервер получателя принимает подписанное DKIM письмо, заявляющее, что оно, допустим, поступило от Google, то сначала он при помощи Domain Name System (DNS) находит публичный ключ Google. Получатель теперь может проверить подпись, чтобы убедиться, что письмо аутентично и не модифицировано, ведь подпись связана с содержимым и большинством заголовков. После этого такое знание можно использовать в качестве входных данных для фильтрации спама. (Подобные гарантии обеспечивает похожий протокол под названием ARC.)

Разумеется, такое решение неидеально. Поскольку DKIM необязателен, злонамеренные посредники могут вырезать подписи DKIM из письма, чтобы убедить получателей, что оно никогда не было подписано DKIM. Похожий протокол под названием DMARC, использует DNS, чтобы позволить отправителям почты передавать свои предпочтения, принуждающие проверять подписи их электронных сообщений. Совместное использование этих двух протоколов, по сути, должно полностью избавить Интернет от спуфинга.


Пример подписи DKIM одного из полученных мной сегодня автоматизированных писем.

В чём проблема DKIM/ARC/DMARC и что такое оспоримость?


В качестве меры защиты от спама DKIM, ARC и DMARC не имеют никаких особых проблем. Сложность в том, что подписывание DKIM обладает неожиданным побочным эффектом, распространяющимся дальше, чем изначальная задача фильтрации спама. Если вкратце:

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

Эта новая особенность отсутствия возможности аннулирования изначально не задумывалась как цель DKIM. Проектировщики не планировали её, никто не обсуждал, будет ли это хорошей идеей, и большинство она застала врасплох. Хуже того эта неожиданная особенность имела весьма серьёзные последствия: она делает нас более уязвимыми к вымогательству и шантажу.

Чтобы понять, в чём проблема, стоит рассмотреть цели DKIM.

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

Однако после завершения передачи почты цель DKIM оказывается выполненной. То есть гарантия аутентичности должна сохраняться только в течение короткого промежутка времени. Поскольку обычно для получения письмам требуется всего несколько минут (в редких случаях часов), гарантия аутентичности не должна длиться годами, а эти подписи не должны быть открыты пользователям. Тем не менее, происходит именно так.

До недавнего времени никто об этом не задумывался. На самом деле, первые конфигурации DKIM походили на дурную шутку: поставщики услуг почты выбирали ключи подписи DKIM, которые было очень легко взломать нападающему с достаточной мотивацией. В 2012 году исследователь систем безопасности Закари Харрис выяснил, что Google и множество других компаний использовали для подписывания DKIM 512-битный RSA. Он показал, что такие ключи на арендованном облачном оборудовании можно взломать за считанные часы, а затем использовать их для фальсифицирования писем от Ларри и Сергея.

Реакцию Google и других поставщиков услуг электронной почты на весь этот конфуз с Ларри и Сергеем предсказать несложно. Не обдумав хорошенько последствия, они быстро усилили ключи, повысив их до 1024-битного или 2048-битного RSA. Это предотвратило фальсификации, однако непреднамеренно превратило безобидный протокол антиспама в пожизненный штамп криптографической аутентичности, который можно использовать для подтверждения любого дампа электронной почты вне зависимости от того, как он попал в руки подтверждающего.

Ты сошёл с ума, никто не использует DKIM для аутентификации писем.


Как бы там ни было, штамп аутентификации по DKIM широко использовался прессой, в основном в контексте взлома электронной почты политиков. Это реально, важно и значимо.

Самый знаменитый пример, вызвавший в то же время серьёзные разногласия: в 2016 году Wikileaks опубликовал набор писем, украденных из аккаунта Google Джона Подеста. Поскольку источник этих писем был мутным, WikiLeaks столкнулся с тяжкой задачей подтверждения подлинности этих сообщений. Изящным решением стал DKIM: каждое письмо, представленное на страницах Wikileaks, публично указывает статус подтверждения прикреплённых подписей DKIM. Также сайт предоставляет полезную страницу ресурсов для журналистов, объясняющих, как DKIM доказывает реальность писем.

Однако письмами Подеста история с DKIM не закончилась. В 2017 году ProPublica использовал DKIM для проверки аутентичности писем, предположительно отправленных критику личным адвокатом президента Трампа Марком Касовицем. В 2018 году Associated Press снова использовала его для проверки подлинности утечки писем, связывающих российского юриста с Дональдом Трампом-младшим. И это же произошло снова в этом году, когда получатели предполагаемого ноутбука Хантера Байдена передали Робу Грэму для проверки по DKIM одного письма 2015 года, чтобы преодолеть скептицизм журналистов относительно источников их информации.

Кто-то может сказать, что верификация по DKIM не важна, и что верить или не верить в утёкшие письма можно только на основании их содержимого. Однако то, что многочисленные новостные организации решили положиться на DKIM, чётко демонстрирует, насколько ошибочно такое предположение. Новостные организации, в том числе и Wikileaks, косвенно признают, что спорные источники получения писем приводят к сомнениям: вероятно, к таким сильным, что убедительная публикация в национальной новостной организации оказывается из-за этого невозможной. DKIM позволяет обойти эту проблему и устранить подобные помехи.

Агентство Associated Press даже выложило инструмент для проверки DKIM.

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

Но он не даёт никаких преимуществ вам.

Что же можно с этим поделать?


DKIM никогда не предназначался для долговременной аутентификации писем. Обеспечиваемые им гарантии безопасности важны, но должны существовать только в течение нескольких часов (возможно, дней) с момента передачи письма почтовым сервером. Сам факт, что DKIM по-прежнему может использоваться для доказательства подлинности украденного письма, написанного ещё в 2015 году, по сути, является провалом: результатом неправильного использования и настройки поставщиками услуг почты, которые должны были думать головой.

К счастью, существует простое решение.

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

Разумеется, простая замена пар ключей DKIM сама по себе ничего не решит: хитрецы из Интернета постоянно архивируют публичные ключи DKIM. На самом деле, именно так было подтверждено в 2020 году письмо на ящик Google из 2015 года: ключ, который Google использовал для подписывания писем DKIM в тот давно прошедший период (с 2012 по 2016 год использовался один и тот же ключ серьёзно, Google, что это за раздолбайство!), уже больше не используется, но был кэширован во многие места в Интернете.

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

(Те, у кого есть собственные почтовые сервера, могут реализовать это автоматически при помощи этого замечательного скрипта.)

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

(Читатель-параноик может также учесть возможность того, что мотивированные нападающие могли уже украсть у Google старые секретные ключи DKIM. В конечном итоге, ключи подписи DKIM не являются королевскими драгоценностями экосистемы Google, поэтому Google вряд ли прикладывает максимальные усилия для обеспечения их безопасности. В таком случае сохранением секретности ключей Google просто создаёт ситуацию, в которой определённые акторы могут безнаказанно фальсифицировать письма.)

Но аутентификация по DKIM отличная штука! Разве мы не хотим иметь возможность проверки утекшей у политиков почты?


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

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

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

Тот факт, что мне приходится спорить об этом, очень меня печалит.

Временные метки, улучшенная криптография и другие формальные возражения


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

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

Кто-то даже предложил возможность хитрой атаки, при которой получатели (или хакеры, имеющие постоянный доступ к вашему аккаунту электронной почты) используют публичный сервис создания временных меток, например, блокчейн, для надёжного штемпелевания на любом получаемом ими письме времени получения. Это позволяет таким получателям доказать, что они подписали письмо до публикации секретного ключа DKIM шах и мат.

Это отличный умный теоретический хак, но он, по сути, не относится к нашей теме в том смысле, что обращается к более сильной модели угроз. Самая критическая проблема DKIM сегодня заключается в том, что подписи DKIM находятся внутри вашего архивированного почтового ящика. Это означает, что хакер, взломавший мой аккаунт Gmail сегодня, сможет продемонстрировать подписи DKIM на письмах, которые я отправлял/получал годы назад. Публикация старых секретных ключей DKIM мгновенно решит эту проблему. Решение теоретической проблемы хакера в реальном времени может подождать своей очереди.

Иногда я слышу и другое возражение: криптографическая аутентификация это полезная функция. И при определённых условиях я с этим согласен. Проблема DKIM в том, что ни одного клиента не спросили, нужна ли ему по умолчанию эта функция в его коммерческом аккаунте почты. Если люди захотят криптографически подтверждать свои письма, то для этой цели можно воспользоваться удобным набором инструментов.

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

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



На правах рекламы


Виртуальный сервер от VDSina с защитой от DDoS-атак позволит разместить любой проект всё будет работать без сбоев и с высоким uptime! Подобрать параметры сервера можно самостоятельно с помощью удобного конфигуратора.

Подробнее..

Настройка собственного почтового сервера

26.02.2021 20:18:58 | Автор: admin

Есть три основных шага, чтобы установить и настроить собственный почтовый сервер.

  • Настройка IP и DNS

  • Выбор и запуск приложения почтового сервера

  • Добавление своего почтового сервера в белые списки

Настройка IP и DNS

Обеспечение внешнего статического IP-адреса, публичного домена и записи PTR

Это основные требования для запуска собственного почтового сервера.

  • Публичный статический IP-адрес
    IP-адрес почтового сервера должен быть общедоступным и постоянным во времени. Убедиться в этом можно у хостинг или Интернет-провайдера.

  • Доменное имя указывает на IP
    DNS-запись публичного доменного имени почтового сервера должна указывать на этот IP-адрес. Им можно управлять в настройках DNS провайдера доменного имени.

  • IP указывает на доменное имя
    Самое главное, обратная DNS-запись (именуемая PTR) должна указывать на доменное имя почтового сервера по IP-адресу. Можно попросить своего хостинг-провайдера или поставщика интернет-услуг настроить его. Его можно легко проверить по IP-адресу онлайн (например, тут), или с помощью команды nslookup в Windows и команды host в системах на основе UNIX.

Настройка MX записи в DNS

Запись почтового обмена (MX) указывает почтовый сервер, ответственный за прием сообщений электронной почты от имени домена.

Например, если наш домен - mycompany.com, почтовый сервер - mail.mycompany.com, то запись DNS для mycompany.com будет:

Type

Host

Value

Priority

TTL

MX

@

mail.mycompany.com

10

1 min

где:

  • Priority (приоритет) используется, когда в домене более одного почтового сервера.

  • TTL (время жизни) можно установить любое предпочтительное значение, а наименьшее значение используется для применения конфигурации DNS как можно скорее при отладке настроек.

Настройка DKIM записи в DNS

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

Понадобятся приватный и открытый ключи. Их можно создать с помощью онлайн-инструментов, например Power DMARC Toolbox - DKIM Record Generator, или с помощью команд OpenSSL (приведен пример для Windows):

  • Создать приватный ключ
    openssl.exe genrsa -out private.key 2048

  • Создать публичный ключ из приватного
    openssl.exe rsa -in private.key -pubout -outform der 2>nul | openssl base64 -A > public.key.txt

И запись DNS будет выглядеть так:

Type

Host

Value

TTL

TXT

selector._domainkey

v=DKIM1; k=rsa; p=public_key

1 min

где:

  • selector - самостоятельно выбранный идентификатор (например, mysrv), который будет использоваться в приложении почтового сервера (смотрите ниже).

  • public_key - открытый ключ, закодированный алгоритмом base64 (содержимое public.key.txt).

  • TTL (время жизни) имеет то же значение, что и в предыдущем разделе.

Настройка SPF записи в DNS

Инфраструктура политики отправителя (SPF) это стандарт проверки подлинности электронной почты, который проверяет IP-адрес отправителя по списку авторизованных IP-адресов владельца домена для проверки входящей электронной почты.

Тут запись DNS будет выглядеть так:

Type

Host

Value

TTL

TXT

@

v=spf1 a mx include:relayer_name -all

1 min

где:

  • relayer_name - имя необязательного внешнего почтового сервера-ретранслятора (смотрите ниже). Если не нужно - убирается вместе с "include:".

  • TTL (время жизни) имеет то же значение, что и в предыдущем разделе.

Можно использовать удобный онлайн-генератор записи SPF.

Дополнительные записи DNS

Некоторые поля не обязательны, но желательно иметь.

  • DMARC
    Запись доменной проверки подлинности сообщений, отчетов и соответствия (DMARC) позволяет собственному почтовому серверу декларировать политику того, как другие почтовые серверы должны реагировать на недостоверные сообщения от него.

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

  • TLS-RPT
    TLS-отчетность (TLS-RPT) дает ежедневные сводные отчеты с информацией о электронных письмах, которые не зашифровываются и не доставляются.

Все эти записи могут быть созданы с помощью Power DMARC Toolbox.

Выбор и запуск приложения почтового сервера

Конечно, хостинг должен позволять устанавливать программное обеспечение. Можно использовать любое подходящее приложение для почтового сервера. Например, есть бесплатный hMailServer для Windows, который предоставляет все необходимые функции с минимальным использованием ресурсов. Для систем на базе UNIX существует множество бесплатных почтовых серверов, таких как Exim Internet Mailer или iRedMail.

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

Инициализация

Когда программное обеспечение выбрано и установлено, самое время его настроить.

  • Домен и пользователи
    Нужно добавить домен и начальный набор пользователей почтового сервера.

  • Безопасность
    Чтобы обеспечить соответствующий уровень безопасности, мы должны добавить сертификат SSL для домена.

  • Подпись сообщений
    Далее, следует настроить DKIM. Нужно указать полученные выше приватный ключ и селектор. Кроме того, методы заголовка и тела должны быть установлены на расслабленный, алгоритм подписи должен быть установлен на SHA256, иначе на некоторых SMTP серверах не проходит проверка (например, google).

  • Защита от спама
    Наконец, нужно настроить антиспам-проверку специальными узлами черных списков, такими как spamhaus.org, чтобы защитить пользователей почтового сервера от нежелательных сообщений.

Протоколы электронной почты

Нужно настроить три протокола электронной почты, которые необходимы для её отправки и получения.

SMTP

SMTP используется для приема входящей и исходящей почты с/на другие почтовые серверы. И это позволяет пользователям домена отправлять свои сообщения.

  • 25 порт
    Этот порт необходим для управления входящими подключениями от других почтовых серверов. Метод безопасности следует установить в STARTTLS.

  • 587 порт
    Он нужен для почтовых клиентов собственного почтового сервера. Метод безопасности следует установить в STARTTLS.

  • 465 порт
    Он не является официальным и может потребоваться для старых почтовых клиентов. И метод безопасности следует установить в SSL/TLS.

POP3, IMAP

POP3 и IMAP используются отдельными почтовыми клиентами, такими как Outlook на ПК или любой почтовый клиент на мобильных телефонах. Это позволяет пользователям домена управлять своими сообщениями.

Порт 993 следует использовать для защищенных соединений IMAP, а порт 995 - для POP3. Для обеспечения совместимости с большинством клиентов метод безопасности следует установить в SSL/TLS (не STARTTLS).

Также можно настроить порты 143 для IMAP и 110 для POP3, но они не шифруются и сейчас их уже мало кто использует.

Проверка

Итак, когда все настроено, нужно протестировать почтовый сервер, отправив письмо кому-нибудь из списка пользователей. Кроме того, в некоторых почтовых приложениях есть функция самодиагностики (см. ниже пример от hMailServer).

Теперь пора проверить отправку на внешний адрес.

Аккаунт Gmail.com

Если есть учетная запись Gmail.com (что наверняка), можно отправить тестовое письмо на свой адрес Gmail. Затем открываем свою электронную почту в браузере и нажимаем Показать подробности.

Если есть подписано: домен, подпись DKIM настроена правильно. Если есть отправлено по почте: домен, SPF в порядке.

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

Также, в Outlook можно видеть те же заголовки в свойствах сообщения.

Специальные онлайн-сервисы

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

  • AppMailDev
    Этот сервис позволяет тестировать конфигурацию почтового сервера, такую как DKIM и SPF, отправляя электронное письмо на указанный сгенерированный почтовый адрес. Нужно просто следовать инструкциям на экране и результаты теста будут отображены там же.

  • DKIMValidator
    Предоставляет те же функции, что и предыдущая служба. Результаты тестирования будут отправлены на адрес отправителя.

  • HAD Email Auth Tester
    Чтобы проверить отправку сообщения здесь, нужно отправить специальное сообщение на tester@email-test.had.dnsops.gov. Результаты тестирования будут отправлены на адрес отправителя.

  • PowerDMARC
    Этот сервис предоставляет только облегченную проверку всех атрибутов, но у него есть удобные инструменты, указанные в ссылках выше.

Итак, если всё настроено правильно, но сервер присутствует в чёрных списках спама, нужно внести его в белый список.

Добавление почтового сервера в белые списки

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

Внесение в белый список в публичных источниках

Итак, сначала проверим IP (и, если необходимо, домен) онлайн на наличие в каких-либо черных списках. Его можно проверить в любом онлайн-чекере, который можно найти через поиск. Например, MXToolBox проверяет самые популярные черные списки. Также, multirbl.valli.org показывает много источников черного списка и доверие к каждому из них.

Затем нужно последовательно просмотреть каждый элемент в результатах и прочитать рекомендации о том, как внести IP-адрес в белый список в конкретном источнике черного списка. Но не все из них могут позволить это сделать бесплатно, например, немецкий UCEPROTECT-Network.

Кстати, на тут на habr обсуждалась автоматизация мониторинга IP в блэклистах.

Внесение в белый список определенных почтовых серверов

Некоторые серверы, такие как Outlook, имеют свои собственные черные списки. Проверка проста - приложение почтового сервера уведомит о неудачной доставке в почтовом клиенте. Большинство почтовых серверов предоставляют в ответе URL-адреса разблокировки. Таким образом, нужно открыть такой URL и следовать инструкциям, например, как этот.

Обход черных списков

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

  • MailerSend
    Один из самых дешевых - позволяет бесплатно отправлять 20 тысяч писем в месяц и имеет низкую стоимость дополнительной отправки. Но есть особенность: поля CC и BCC пока не поддерживаются.

  • SendInBlue
    Это еще один хороший сервис, который позволяет бесплатно отправлять 9 тысяч писем в месяц с лимитом 200 в день. Но есть нюансы: встроенное отслеживание электронной почты нельзя отключить и высоковатая цена сверх бесплатного лимита.

В каждой службе нужно зарегистрироваться и получить подтверждение почтового домена. После подтверждения, каждый из них дает указания на то, что должно быть настроено для DNS (DKIM, SPF и DMARK) и почтового приложения (адрес сервера ретрансляции SMTP, порт и учетные данные).

Заключение

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

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru