Сообщение не может быть отправлено незарегистрированный sender id
Обновлено: 05.07.2024
Создайте рассылку в конструкторе за 15 минут. Отправляйте до 1500 писем в месяц бесплатно.
Принцип работы Sender ID
В отличие от SPF, задачей которого является создание барьера для спама, Sender ID позволяет существенно расширить диапазон проверок доменов, тем самым препятствует мошенничеству и спуфингу. Работа Sender ID включает в себя несколько этапов:
Если же PRA успешно определяется, то следующим шагом становится извлечение сервером предполагаемого домена отправителя (PRD), с помощью которого сервер может составить запрос DNS, предназначенный для записи Sender ID (Email Policy Document).
Преимущества и недостатки применения Sender ID для email-рассылок
Что нужно знать перед началом работы
Предполагаемое время для завершения каждой процедуры: 5 минут
Для выполнения этой процедуры (процедур) необходимы соответствующие разрешения. Чтобы узнать, какие разрешения вам нужны, см. в разделе "Антиспамские функции" в разделе Разрешения antispam и antimalware .
Для выполнения этой процедуры можно использовать только PowerShell. Сведения о том, как открыть командную консоль Exchange в локальной организации Exchange, см. в статье Open the Exchange Management Shell.
Сочетания клавиш для процедур, описанных в этой статье, приведены в статье Сочетания клавиш в Центре администрирования Exchange.
Возникли проблемы? Попросите помощи на форумах Exchange. Перейти на форумы можно по следующим ссылкам: Exchange Server, Exchange Online или Exchange Online Protection.
Используйте оболочку Exchange, чтобы включить или отключить ID отправитель
Чтобы отключить идентификацию отправителей, выполните следующую команду:
Чтобы включить идентификацию отправителей, выполните следующую команду:
При отключении идентификации отправителей, соответствующий агент идентификации все еще включен. Чтобы отключить агент отправитель, запустите команду: Disable-TransportAgent "Sender ID Agent" .
Как убедиться, что все получилось?
Чтобы убедиться, что вы успешно включили или отключили технологию Sender ID, выполните следующую команду, чтобы проверить значение свойства Enabled:
Используйте оболочку Exchange, чтобы включить или отключить ИД отправитель для внешних подключений
По умолчанию технология Sender ID включена для внешних (не прошедших проверку подлинности) SMTP-подключений.
Чтобы отключить фильтрацию отправителей для внешних подключений, выполните следующую команду:
Чтобы включить идентификацию отправителей для внешних подключений, выполните следующую команду:
Как проверить, что все получилось?
Чтобы убедиться, что вы успешно включили или отключили технологию Sender ID для внешних SMTP-подключений, выполните следующую команду, чтобы проверить значение свойства ExternalMailEnabled:
Используйте оболочку Exchange, чтобы включить или отключить ID отправитель для внутренних подключений
Чтобы включить идентификацию отправителей для внутренних (прошедших проверку подлинности) SMTP-подключений, выполните следующую команду:
Чтобы отключить идентификацию отправителей для внешних подключений, выполните следующую команду:
Как проверить, что все получилось?
Чтобы убедиться, что вы успешно включили или отключили технологию Sender ID для внутренних SMTP-подключений, выполните следующую команду, чтобы проверить значение свойства InternalMailEnabled:
Как убедиться, что все получилось?
Используйте Exchange для настройки действия отправитель ID для временных ошибок
Чтобы настроить действие Sender ID для временных ошибок, используйте следующий синтаксис:
Обратите внимание StampStatus , что это значение по умолчанию для параметра TempErrorAction .
Как убедиться, что все получилось?
Чтобы убедиться, что вы успешно настроили действие Sender ID для временных ошибок, выполните следующую команду, чтобы проверить значения свойства TempErrorAction:
Используйте оболочку Exchange для настройки исключений домена получателя и отправитель
Чтобы заменить существующие значения, выполните следующую команду:
Чтобы добавить или удалить записи, не изменяя другие существующие значения, используйте следующий синтаксис:
В этом примере настраивается агент Sender ID со следующими параметрами:
Как проверить, что все получилось?
Чтобы убедиться, что вы успешно настроили исключения доменов получателей и отправителей, выполните следующую команду, чтобы проверить значения свойств:
Чтобы бороться со спамом, используются разные технологии, и Sender ID — одна из них.
Sender ID позволяет определять отправителя электронного письма, не допуская подделки обратного адреса.
Пример фишинга. Письмо пришло не от официального Instagram компании, а от поддельного почтового ящика
Как работает Sender ID
Технология Sender ID создана на основе двух других технологий — Caller ID и SPF (Sender Policy Framework — подпись с информацией о серверах, которые могут отправлять почту с вашего домена).
Sender ID в свою очередь определяет отправителя, а потом сопоставляет IP его письма с IP домена, в котором находится его почтовый адрес. Если IP совпадают, то письмо проходит, если нет, то блокируется.
Преимущества и недостатки Sender ID
Преимущества
Sender ID помогает бороться со спамом. Он отслеживает почтовые адреса отправителя и препятствует распространению нежелательных писем.
Недостатки
Чтобы технология работала, необходимо, чтобы Sender ID поддерживали почтовые сервера, с которых приходят письма. Ведь письма, которые пришли с серверов без Sender ID, автоматически попадают в спам.
Подведём итог
Sender ID препятствует распространению спама, фишинговых атак. В итоге пользователи почты в безопасности: они не откроют поддельные письма от хакеров, не перейдут по ссылке и не скачают на свой компьютер вирус или вредоносную программу.
Однако Sender ID работает, если его используют большое количество почтовых серверов. В противном случае, если письмо пришло с почты, которая не использует Sender ID, оно будет заблокировано. Однако многие почтовые серверы, например, Яндекс, используют Sender ID.
Аутентификация отправителей e-mail и борьба со спамом
Технология аутентификации отправителей электронной почты позволяет резко сократить поток почтового мусора. Мы проанализировали три разновидности такой технологии.
Что у спамеров на уме?
Спамеры очень любят открытые ретрансляторы (open relays) — серверы, доставляющие почту нелокальным пользователям, поскольку такой ретранслятор позволяет замаскировать идентифицирующую спамера информацию. Ответственные почтовые администраторы все чаще и чаще закрывают такие ретрансляторы на своих системах. Призванные отслеживать открытые ретрансляторы сервисы, получившие название “черные списки реального времени”, вместе с серверным ПО, блокирующим приходящую с известных источников спама почту, немного ослабили возможности ретрансляции, вынудив спамеров искать другие методы распространения почтового мусора.
Но к их счастью, популяризация широкополосного доступа и слабая защита конечных узлов открыли им дорогу к сотням тысяч постоянно действующих компьютеров, подключенных к Интернету по высокоскоростным соединениям. Используя уязвимости в системе сетевой защиты (обычно путем инфицирования домашних ПК “троянами” или вирусами), спамеры инсталлируют на домашние компьютеры ПО ретрансляции e-mail, превращая их в почтовые серверы открытой ретрансляции. Чтобы противостоять спамерам, Интернет-провайдеры начали заносить в “черные списки” IP-адреса из пулов DHCP других Интернет-провайдеров, поскольку почту следует ретранслировать, задействуя лишь свои SMTP-серверы исходящей почты. Однако, зная, что Интернет-провайдеры не смогут заблокировать SMTP-серверы без полной остановки службы e-mail, спамеры усовершенствовали ПО ретрансляции таким образом, чтобы почта доставлялась на исходящие SMTP-серверы своих Интернет-провайдеров.
Технологии аутентификации отправителей e-mail нацелены на дальнейшее сокращение потоков спама. На рассмотрение Инженерной группы по развитию Интернета (Internet Engineering Task Force — IETF) в свое время были представлены разнообразные предварительные версии таких технологий; наиболее интересными из них являются SPF (Sender Policy Framework), Sender ID и DKIM (Domain Keys Identified Mail). В 2003 г. производитель специализированных e-mail-устройств — компания IronPort опубликовала информацию еще по одной технологии аутентификации e-mail — SMTPi, правда, сегодня эти сведения можно найти лишь посредством поисковых машин в Web-архивах.
Аутентификация отправителей e-mail не позволяет избавиться от спама полностью, да она и не предназначена для этого. Но если бы все Интернет-сообщество взяло ее на вооружение, то мы стали бы свидетелями резкого сокращения объемов спама, хотя ничто не мешает спамерам со временем приспособиться и к аутентификации e-mail. Тем не менее результативность таких простых методов, как подделка адресов в поле “from” и использование инфицированных компьютеров с широкополосным доступом к Интернету, практически сошла бы на нет.
Вам ничего не стоит позволить принимающим серверам e-mail читать ваши SPF-записи. Однако, чтобы заставить ваш сервер принимать к рассмотрению SPF-записи других серверов, вам придется модифицировать ваше ПО электронной почты. Технологию SPF поддерживают ПО безопасности e-mail, противоспамные устройства и обычное ПО MTA (Message Transfer Agent), но, для того чтобы они смогли корректно обрабатывать информацию SPF, настраивать их придется очень тщательно. Если ваш шлюз SMTP не поддерживает SPF, то вам необходимо приобрести новый: согласно исследованиям компании Forrester, от 25 до 30% всех доменов e-mail публикуют записи SPF, и это свидетельствует о том, что данная технология аутентификации отправителей e-mail является сегодня самой популярной.
Записи SPF публикуются не только поставщиками услуг e-mail, включая AOL, Hotmail и RoadRunner, но и крупными компаниями, подобными Bank of America, eBay и Ticketmaster. Ticketmaster возвращает любому проверяющему ее записи SPF лицу значение уровня доверия fail, AOL — neutral, а все другие — softfail.
Можно просмотреть записи SPF, используя инструментальные средства генерации запросов DNS и определяя тип записей ресурсов как TXT. SPF-запись Bank of America выглядит следующим образом:
Хотя мы призываем всех сконфигурировать записи SPF для своих почтовых доменов (в конце концов, вы ничего не теряете), эта технология все же имеет свои ограничения. Самое важное из них — недостаточно эффективное подавление фишинга, обусловленное проверкой адреса отправителя (envelope return address), а не адреса, указанного в поле “from”, который пользователи видят в окне своего почтового клиента. Таким образом, при фишинге спамер сможет легко обойти SPF, используя корректный адрес в поле “from” конверта и корректный исходящий сервер e-mail, обманув при этом пользователя ложными контентами и адресами “from”, отображаемыми в окне почтового клиента.
Как следствие, технология Sender ID подавляет фишинг более эффективно, чем SPF, поскольку проверяет адреса “from”, которые пользователи видят в окнах своих e-mail-клиентов. Начать использовать Sender ID так же просто, как и SPF: все, что вам нужно,— это добавить записи в DNS, дав возможность другим просматривать их. Однако, как и SPF, Sender ID нарушает функционирование университетских служб переадресации e-mail и создает неудобства для мобильных пользователей, использующих различные серверы SMTP.
Но самая крупная проблема Sender ID связана с бесплатным лицензионным соглашением Royalty-Free Sender ID Patent License Agreement компании Microsoft. Ряд организаций, в том числе и Apache Software Foundation, AOL, Free Software Foundation (FSF) и Open Source Initiative (OSI), выразили недовольство комитету IETF по поводу содержащихся в соглашении формулировок, что, очевидно, замедлило темпы внедрения технологии Sender ID. В этих организациях считают, что ни одной компании не следует предоставлять право интеллектуальной собственности на столь фундаментальные спецификации, лежащие в основе сети Интернет. Microsoft и поставщики ПО с открытым исходным кодом, похоже, погрязли в таких терминах, как “непередаваемый”, “не подлежащий сублицензированию”, и в формулировках, которые при смене торговой марки или редистрибуции технологии Sender ID заставляют конкурентов контактировать с Microsoft, предоставляя этому софтверному гиганту прекрасную возможность завладевать чужими коммерческими секретами.
Мы рекомендуем вам внедрить SPF и подождать, когда решатся разногласия по патентной лицензии Microsoft. Как SPF, так и Sender ID являются предварительными спецификациями IETF, однако мы считаем, что внедрение SPF идет более быстрыми темпами, и поэтому уверены в том, что первым стандартом IETF станет технология SPF.
Как насчет DKIM?
Читайте также: