Замечания к выпуску SecurityGateway for Email Servers 4.5

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

Щелкните здесь для получения дополнительной информации по SecurityGateway for Email Servers.

SecurityGateway 4.5.0 - 4 апреля, 2017 года

ОСОБЫЕ ПРИМЕЧАНИЯ

[18161] Опция "Применять метод авторизации CRAM-MD5", доступная в меню "Настройка/ Пользователи| Настройка почты| Почтовый протокол" теперь отключена по умолчанию по техническим соображениям и соображениям безопасности. Использование TLS - предпочтительный способ предотвращения передачи паролей в открытом виде.

ИЗМЕНЕНИЯ И НОВЫЕ ФУНКЦИИ

ИСПРАВЛЕНИЯ

SecurityGateway 4.0.1 - 26 июля, 2016 года

ИЗМЕНЕНИЯ И НОВЫЕ ФУНКЦИИ

ИСПРАВЛЕНИЯ

SecurityGateway 4.0.0 – 14 июня, 2016 года

ОСНОВНЫЕ НОВЫЕ ФУНКЦИИ

[15999] Обновленный веб-интерфейс с более отзывчивым мобильным дизайном

Обновленный веб-интерфейс приложения теперь использует более отзывчивый мобильный дизайн. Список поддерживаемых браузеров ограничен IE10+, новейшими версиями Chrome и Firefox, а также самыми свежими версиями Safari для платформ Mac и iOS. Во встроенных браузерах на устройствах Android наблюдаются проблемы с прокруткой, однако в браузере Chrome для устройств Android веб-интерфейс работает вполне корректно.

В новом дизайне ключевое значение имеет такая характеристика, как размер рабочего окна. На любых пользовательских устройствах, включая ПК, телефоны или планшеты, при одинаковом размере окон их внешний вид будет полностью идентичным. Наиболее существенным изменением является переработанное меню. Если ширина меню составляет 956 пикселей или менее, этот интерфейсный элемент скрывается в левой части браузерного окна. Доступны два способа вызова меню. На устройствах с сенсорным дисплеем, дополнительное меню открывается «смахивающим» жестом слева направо. На всех типах устройств дополнительное меню также вызывается нажатием на одноименную кнопку в левом верхнем углу экрана. Касание или щелчок по заголовку меню отображает основное меню. В правом верхнем углу доступны кнопки для вызова справки, выход из системы и отображения информации о программе, вид этих кнопок изменяется в зависимости от ширины экрана. При ширине в 768 пикселей и больше, отображаются кнопки со словами «Справка», «О программе» и «Выход», а если ширина составляет от 481 до 767 пикселей на экране отображаются только пиктограммы. В случае если ширина не превышает 480 пикселей, перед глазами пользователя окажется иконка с изображением шестеренки при нажатии на которую открывается выпадающее меню с теми же пунктами. При отображении списка, состоящего из нескольких столбцов, становятся доступными кнопки для отображения или сокрытия колонок.

[11232] DMARC

Добавлена поддержка DMARC (Domain-based Message Authentication, Reporting, and Conformance). DMARC предлагает масштабируемый механизм, с помощью которого организация-отправитель может с использованием системы доменных имен определять политики уровня домена и выражать собственные предпочтения, касающиеся проверки подлинности почты, ее размещения и генерирования отчетов, организация-получатель, в свою очередь, может использовать эти политики и правила для более качественной обработки корреспонденции. Спецификацию DMARC и подробную информацию о работе данного механизма можно найти здесь: http://www.dmarc.org/.

С помощью DMARC владельцы доменов смогут выражать собственные пожелания, относительно обработки электронной корреспонденции, которая выдает себя за почту с принадлежащего им домена, в действительности не являясь таковой. Поддерживаются следующие настройки политик обработки сообщений: "none" - в этом случае SecurityGateway не будет предпринимать никаких действий, "reject" - SecurityGateway откажется принимать сообщение в рамках SMTP-сеанса или "quarantine" - в этом случае SecurityGateway добавит к каждому сообщению следующий заголовок: "X-MDDMARC-Fail-policy: quarantine", который упростит фильтрацию содержимого пользовательской папки нежелательных сообщений. Этот заголовок добавляется только в тех случаях, если сообщение не прошло проверку DMARC. Вы можете разрешить SecurityGateway принимать сообщения даже если оно должно быть отклонено в соответствии с политикой DMARC. Фактически, этот рабочий режим и является принятым по умолчанию. В таких случаях SecurityGateway добавит в сообщения заголовок "X-MDDMARC-Fail-policy: reject", что упростит их последующую фильтрацию и сортировку.

Технология DMARC способна заменить механизм ADSP и некоторые функции SPF. Впрочем, вы можете использовать эти механизмы в сочетании с DMARC. Если верификация DMARC включена, то обработка средствами ADSP и SPF теперь выполняется после нее.

DMARC частично зависит от использовании каталога публичных суффиксов. Публичным суффиксом называется доменный суффикс, под которым пользователи Интернета могут напрямую регистрировать доменные имена. Примерами публичных суффиксов являются .com, .co.uk и pvt.k12.ma.us. "Каталог публичных суффиксов" - это список, содержащий все известные публичные суффиксы. SecurityGateway использует каталог, поддерживаемый сообществом Mozilla Foundation, который можно найти здесь: https://publicsuffix.org/. Копия списка устанавливается в папку \App\ folder в виде файла effective_tld_names.dat. Исчерпывающего списка публичных суффиксов на данный момент не существует, как и единого авторитетного источника таких каталогов, что является проблемой для всего Интернет-сообщества. Со временем этот файл устаревает и подлежит замене на более свежую версию, которую необходимо загрузить с сайта https://publicsuffix.org/list/effective_tld_names.dat и сохранить в папку \App\ folder. SecurityGateway будет автоматически загружать и устанавливать этот файл в рамках ежедневной процедуры обслуживания. Обновление файла осуществляется примерно раз в две недели. Управлять выполнением этой операции можно с помощью специальных элементов интерфейса, доступных в новом окне настройки параметров DMARC. Результаты обновления и сведения о других операциях, связанных с обработкой почты средствами DMARC, можно найти в журнал DMARC и в новом окне DMARC во вкладке "Безопасность". Вы можете указать другой URL-адрес для загрузки файла, однако загружаемые данные должны соответствовать формату, опеределяемому Mozilla. Более подробную информацию вы найдете по приведенной выше ссылке. SecurityGateway строго следует алгоритму синтаксического анализа, определенному Mozilla. Создайте пустой файл под названием "PUBLICSUFFIX.SEM" и поместите его в папку \App, если вы заменили или модифицировали файл effective_tld_names.dat и хотите выполнить его повторную загрузку без перезапуска SecurityGateway.

Для использования DMARC в качестве отправителя электронной почты вы должны опубликовать запись DMARC TXT в настройках DNS вашего домена. Сведения о содержимом и структуре этой записи можно найти здесь: http://www.dmarc.org. После публикации записи DMARC в DNS домена вы начнете получать по электронной почте отчеты DMARC из разных источников. Эти отчеты предоставляются в виде сжатого файла XML, формат которого определяется спецификацией DMARC. Обработка генерируемых отчетов выходит за рамки возможностей той реализации DMARC, которая предлагается пользователям SecurityGateway. Однако, данные из этих отчетов позволят получить более полное представление о почтовых потоках домена, ненадлежащем использовании домена, целостности DKIM-подписей, а также о точности и полноте путей сообщений SPF. Почтовые адреса, на которые будут поступать отчеты, указываются вами при создании записи DMARC.

При настройке записи DMARC для одного или нескольких доменов будьте осторожны с использованием правила p=reject. Особое внимание следует проявлять в тех случаях, если ваш домен предоставляет пользователям почтовые учетные записи для повседневного использования. Если пользователи подписаны на почтовые рассылки, используют сервис переадресации почты или привыкли делиться интересными статьями с друзьями, вам стоит знать, что политика DMARC p=reject может сделать эти привычные вещи абсолютно невозможным и рано или поздно вы узнаете об этом. Правило DMARC p=reject может быть исключительно уместным и полезным, но только в тех случаях, если речь идет о почтовых доменах со строгим контролем за использованием учетных записей (в качестве примера можно упомянуть транзакционные почтовые системы, автоматизированные учетные записи (не принадлежащие живым пользователям) или корпоративные политики, запрещающие использование учетной записи за пределами организации).

В соответствии со спецификацией DMARC SecurityGateway будет хранить данные, которые могут впоследствии пригодиться для создания сводных отчетов DMARC. SecurityGateway игнорирует тег DMARC "ri=" и производит только сводные отчеты, охватывающие период с 00:00:00 UTC до 23:59:59 UTC указанного дня. В полночь по всемирному координированному времени (которая может и не совпадать с полуночью по местному времени) SecurityGateway воспользуется этими сохраненными данными для генерирования отчетов. Необходимо, чтобы SecurityGateway работал в указанное время, в противном случае вы столкнетесь с бесцельным и бесконечным накоплением данных. Таким образом, если SecurityGateway 24/7 не работает в режиме 24/7, вам не следует включать механизм создания сводных отчетов DMARC. Генерирование сводных отчетов по умолчанию отключено в настройках DMARC.

Для обеспечения поддержки отчетов об отказах DMARC, реализована поддержка следующих стандартов: RFC 5965 "An Extensible Format for Email Feedback Reports", RFC 6591 "Authentication Failure Reporting Using the Abuse Reporting Format", RFC 6652 "Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format", RFC 6651 "Extensions to DomainKeys Identified Mail (DKIM) for Failure Reporting" и RFC 6692 "Source Ports in Abuse Reporting Format (ARF) Reports". Отчеты об отказах создаются в режиме реального времени, непосредственно в момент инцидента. SecurityGateway генерирует отчеты об отказах в формате AFRF, а не IODEF. Таким образом, для тега DMARC "rf=" можно использовать только значение "afrf". Для получения более подробной информации смотрите спецификацию DMARC. Одно единственное сообщение может инициировать создание нескольких отчетов об отказах, в зависимости от количества получателей, указанных в теге "ruf=", значения тэга "fo=" и количества независимых ошибок авторизации, возникших в процессе обработки сообщения. Когда тег DMARC "fo=" запрашивает отчет об отказах, связанных с работой SPF, SecurityGateway отправляет такой отчет в соответствии со спецификацией RFC 6522. Следовательно, расширения данной спецификации должны быть представлены в SPF-записи домена. Отчеты об отказах SPF не отправляются независимо от обработки DMARC или при отсутствии расширений RFC 6522. Когда тег DMARC "fo=" запрашивает отчет об отказах, связанных с работой DKIM SecurityGateway отправляет отчеты об отказах DKIM и ADSP в соответствии со спецификацией RFC 6651. Таким образом, расширения этой спецификации должны быть представлены в заголовке DKIM-Signature и домен должен опубликовать действительную TXT-запись DKIM reporting в DNS и/или действительное расширение ADSP в TXT-записи ADSP . Отчеты об отказах DKIM и ADSP не отправляются независимо от обработки DMARC или в отсутствии расширений RFC 6651. Для получения более подробной информации изучайте упомянутые выше спецификации. Генерирование отчетов об отказах DMARC отключено по умолчанию.

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

DMARC требует использования расширения протокола STARTTLS всякий раз, когда получатель отчета предоставляет такую возможность, однако не существует способа спрогнозировать соблюдение данного требования или добиться его выполнения с помощью политик. Так или иначе, вам необходимо разрешить использование STARTTLS если вы не сделали этого ранее (нужные опции можно найти в окне «Настройка / пользователи | Система | Шифрование»).

Заголовок Authentication-Results был расширен и теперь включает в себя результаты обработки DMARC. Обратите внимание, что в заголовке Authentication-Results содержатся некоторые данные, предназначенные для отладочных нужд, включая политику DMARC, запрашиваемую владельцем домена, которая не обязательно означает применение к сообщению соответствующих мер. К примеру, если проверка DMARC была пройдена успешно, то содержание политики DMARC не имеет значения, поскольку она применялась бы только в случае проваленной проверки Точно так же, если проверка DMARC была провалена, а в настройках политики выбрано действие "reject", сообщение все же может быть принято в соответствии с локальной политикой. Если вы собираетесь использовать этот заголовок для фильтрации сообщений, вышесказанное следует принимать во внимание. Заголовки "X-MDDMARC-Fail-policy: quarantine" или "X-MDDMARC-Fail-policy: reject" позволят отфильтровывать сообщения в папках со спамом или решать другие задачи. MDaemon вырезает заголовок "X-MDDMARC-Fail-policy:" из каждого входящего сообщения.

В соответствии со спецификацией DMARC (раздел 15.1) сообщения должны содержать заголовок RFC 5322. From или они не будут обрабатываться. Это означает, что отсутствие единственного правильно оформленного (в соответствии со спецификациями RFC ) поля RFC5322. From сделает сообщение несоответствующим требованиям и непригодным для обработки DMARC.

В окне «Безопасность | Защита от подделки» доступны новые элементы управления, с помощью которых можно настроить некоторые параметры DMARC.

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

[3961] Привязка домена к IP-адресу

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

Для домена также можно указать имя хоста SMTP. Это значение является полным именем домена FQDN (Fully Qualified Domain Name), которое используется в SMTP-командах HELO/EHLO при отправке почты домена. Для входящих соединение будет использоваться то же значение, за исключением случаев, когда к IP-адресу привязано несколько доменов, в такой ситуации будет использовано имя FQDN, связанное с первым доменом из списка, в котором домены перечислены в алфавитном списке.

ИЗМЕНЕНИЯ И НОВЫЕ ФУНКЦИИ

ИСПРАВЛЕНИЯ

Copyright ©2008-2016 Alt-N Technologies, Ltd.