3. Терминология, относящаяся к фильтрации и безопасности
Как было отмечено во введении, усилия по контролю или ограничению нежелательного трафика могут приводить к дополнительным ограничениям сервиса Internet. К нежелательному трафику может относиться незапрошенная электронная почта различных видов (включая спам), программные черви, вирусы и (в некоторых случаях) определенные типы информации (контента).
В общем случае максимальные ограничения очевидно будут связаны с такими типами сервиса, как Web-подключение и подключение без предоставления публичного адреса, но некоторые рекомендации предлагают применять ограничения ко всем уровням сервиса. Некоторые ограничения для электронной почты не позволяют клиента передавать почту напрямую (однако можно передавать почту через сервер провайдера), запрещают пользователю устанавливать произвольный обратный адрес в письмах и могут даже закрывать доступ к серверам электронной почты (за исключением предоставленных провайдером) по протоколам типа POP3 или IMAP4. Поскольку пользователям может требоваться доступ к файловым серверам и удаленным почтовым серверам (хотя бы для того, чтобы можно было пользоваться своим электронным адресом из разных мест), важно, чтобы провайдеры указывали доступные при подключении службы и вводимые ограничения.
Некоторые вопросы фильтрации электронной почты имеют особую важность и рассмотрены ниже:
Динамические адреса.
Множество систем, включая некоторые «черные списки» (blacklist), работают на основе допущения, что значительная часть незапрошенной почты поступает от хостов с динамическими адресами, особенно от компьютеров с коммутируемым доступом по телефонным линиям или домашних систем, подключенных по широкополосным каналам. Следовательно, предпринимаются попытки предотвратить передачу почты с таких адресов (за исключением передачи сообщений через серверы провайдера).
Для идентификации систем с динамическими адресами используются различные методы, включая анонсирование провайдерами динамически распределяемых блоков держателям «черных списков», эвристические методы, преобразование адресов в доменные имена и проверка наличия в полученном имени подстрок типа "dsl" или "dial". В некоторых случаях отсутствие реверсной записи DNS трактуется как принадлежность адреса к числу динамических. Отметим, что метод запрета соединений FTP с адресов, для которых отсутствует возможность обратного преобразования DNS, был разработан несколько лет назад и показал свою несостоятельность (множество ложных срабатываний и частый пропуск действительно динамических адресов). Провайдерам следует описывать свои требования (действия) в данном направлении как для входящего, так и для исходящего трафика. Пользователей следует предупреждать о том, что анонсирование провайдером динамических адресов может делать невозможной прямую передачу электронной почты даже для сервиса типа Full Internet Connectivity.
Приватные адреса и трансляция NAT
Системы NAT, используемые для преобразования приватных адресов в публичные (и обратно) позволяют подключаться к удаленным почтовым службам и передавать почтовый трафик в обоих направлениях, но соглашения с провайдерами зачастую запрещают использование серверов, не относящихся к сети провайдера, а также использование клиентских станций в качестве почтовых серверов (обычно это требование не определено достаточно четко).
Фильтрация провайдером исходящего трафика по портам
Другим распространенным способом блокирования соединений с серверами за пределами сети провайдера является фильтрация соединений с портами TCP. Разные провайдеры имеют различные «теории» на сей счет. Некоторые запрещают своим клиентам использовать внешние серверы SMTP для отправки сообщений, но позволяют использовать такие функции при наличии аутентификации отправителя [3]. Другие провайдеры пытаются блокировать все связанны с отправкой почты соединения (такой подход реже используется для клиентов с публичными адресами, нежели для клиентов с приватными адресами и NAT). При использовании такой фильтрации, особенно для сервиса типа "Client only, public address" или "Full Internet Connectivity", провайдер должен сообщать об этом клиентам (см. также главу 4).
Некоторые провайдеры могут перенаправлять исходящий почтовый трафик на свои серверы и теоретически это избавляет от необходимости изменять конфигурацию мобильных хостов, которые могут подключаться к разным провайдерам. О таком перенаправлении почтового трафика провайдеры должны оповещать своих пользователей (особенно в тех случаях, когда это оказывает существенное влияние на безопасность и конфиденциальность).
Фильтры, которые блокируют передачу (или получение) почты полностью или частично, а также пытаются перенаправлять почтовый трафик на серверы провайдера, становятся все более распространенными и о них следует оповещать пользователей.