Вы получаете почту, которую «не заказывали»? Я — да, и совершенно уверен, что прекрасно обошелся бы без нее. Чаще всего я просто прошу отправителя удалить мой адрес из списка рассылки, но если речь идет о рекламе и другом мусоре — так называемом «спаме», так просто отделаться не удастся. Более того, отправители таких посланий обычно маскируются, чтобы избежать наказания за свою малопочтенную деятельность.

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

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

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

Например, во многих организациях используется Sendmail для NT — популярный почтовый сервер, перенесенный с UNIX на Windows. У конфигурации Sendmail есть раздел «Allowed Mail Relays» (Разрешенная ретрансляция), где администратор может перечислить все домены и IP-адреса, пользователям которых разрешается отправлять почту через этот сервер. Post.Office, другой широко распространенный почтовый сервер для Windows-платформ, также позволяет ограничить ретрансляцию в разделе «Restrict Mail Relaying»системной конфигурации.

Многие из вас, скорее всего, пользуются Microsoft Exchange Server и его коннектором SMTP Relay. В декабре прошлого года компания Microsoft опубликовала документ, в котором подробно рассмотрен вопрос о защите этого коннектора от попыток ретрансляции почты www.microsoft.com/TechNet/exchange/relay.asp, который я настоятельно рекомендую прочитать всем администраторам Microsoft Exchange Server.

Если, проверив свой сервер, вы пришли к выводу, что невольно стали орудием в руках спамеров, проверьте базу данных Web-сайта системы защиты от открытой ретрансляции (Open Relay Behavior-Modification System, ORBS) по адресу http://www.orbs.org/. Эта организация ведет базу данных, в которой перечислены серверы, разрешающие ретрансляцию почты. Получив уведомление о том, что какой-то сервер разрешает ретрансляцию, система ORBS сообщает об этом администратору сервера. Если по истечении 30 дней после уведомления ретрансляция все еще открыта, ORBS публикует сведения о сервере в своей базе данных. Этой базой данных часто пользуются спамеры, однако предназначена она не для них, а для администраторов почтовых серверов. Загрузив базу данных ORBS, можно явным образом запретить ретрансляцию почты от перечисленных в ней источников. Если же в базу данных ORBS попал ваш сервер, запретите ретрансляцию, свяжитесь с администрацией ORBS и попросите убрать свой сервер из базы данных.

ORBS предоставляет и еще одну ценную услугу — используя ее базу данных для создания зоны DNS, можно защитить свой почтовый сервер от атак спамеров. Подробное описание процедуры настройки зоны DNS приведено в документе www.orbs.org/usingindex.html. Прочитайте и еще один документ ORBS — рекомендации по защите IIS SMTP Relay, Netscape Messaging Server и других популярных почтовых серверов от атак спамеров (www.orbs.org/otherresources.html). И, наконец, познакомьтесь с рекомендациями Инженерной комиссии Интернет по предотвращению неавторизованной ретрансляции почтовых сообщений (RFC 2505, «Anti-Spam Recommendations for SMTP MTAs», info.internet.isi.edu/in-notes/rfc/files/rfc2505.txt).