Технические RFC заголовки email. Подмена заголовка письма

Технические заголовки

Согласно стандартам обмена электронными сообщениями, письма поддерживают некоторые заголовки, каждый из которых должен быть с новой строки. По умолчанию уже прописаны необходимые из них: MIME-Version, Content-Type, From, Reply-To, Subject, To. Записанные в поле заголовков новые, будут добавлены к имеющимся вшеуказанным.

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

Что такое служебные заголовки и зачем их настраивать

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

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

В случае использования платформ-рассыльщиков ситуация усложняется. Отправителем выступает ваш домен, например, site.ru, но рассылка ведётся с адреса mail.sendsay.ru, что вызовет у принимающего почтового сервера справедливые подозрения.

Sender Policy Framework

Чтобы снять подозрения почтовиков используется специальный механизм - SPF (Sender Policy Framework или инфраструктура политики отправителя). С его помощью сайт (всё тот же, site.ru) говорит принимающей стороне, что рассыльщик (sendsay.ru) действительно имеет права на отправку ваших писем.

Важно, что SPF работает только с заголовком письма и специальным обратным адресом (smtp.mailfrom), но не с тем адресом From, который видит человек. Так что мошенничество с подменой From никак не повлияет на проверку SPF.

Выходит, этот механизм не является действительно надёжной защитой: чаще всего провал SPF-проверки не является поводом отвергнуть письмо. Главная его задача - подтверждение отправителя, что важно для репутации домена в глазах почтовых платформ. Чем выше рейтинг домена, тем ниже шансы, что ваши письма будут признаны спамом. Если компания использует для рассылок несколько доменных имён (допустим, .ru и.com), то настраивать служебные заголовки придётся для каждого доменного имени отдельно. Проще всего выделить для рассылок специальное доменное имя (например, mail.stie.ru) и настроить SPF-запись под него.

При желании для рассылок можно воспользоваться и доменом sendsay.ru, но это имеет ряд побочных эффектов. В частности, использование стороннего отправителя явно отображается в веб-интерфейсе gmail.com: рядом с адресом отправителя появляется надпись о рассыльщике:

Не смертельно, но неприятно. В настройке SPF-записи поможет сетевой SPF-мастер .

Domain Keys Identified Mail

Следующим бастионом на пути проверки писем является цифровая подпись DKIM (Domain Keys Identified Mail - идентификация письма по ключу домена). DKIM - это специальная криптографическая подпись, которая позволяет надёжно идентифицировать вас как легитимного отправителя. Идеологически DKIM подобна водяным знакам на банкнотах.

Метод строится на паре ключей шифрования: открытом и закрытом. Закрытым ключом сообщение подписывается перед отправкой. Открытый ключ публикуется на DNS-сервере отправителя в TXT-записи.

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

Провал проверки DKIM обычно не является катастрофой: подобные письма доберутся до получателя, пусть и с пометкой «возможно мошенничество, мы не можем проверить подлинность отправителя» . Самое неприятное последствие проваленной DKIM-проверки - ущерб для репутации отправителя.

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

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

Domain-based Message Authentication, Reporting and Conformance

Domain-based Message Authentication, Reporting and Conformance (DMARC) - идентификация сообщений, создание отчётов и определение соответствия по доменному имени. DMARC - политика проверки сообщений, предназначенная для снижения числа нежелательных писем.

Возникшая всего пару лет назад (в марте 2015 года), DMARC строится на уже описанных SPF и DKIM, но имеет существенное отличие. Если базовые механизмы лишь говорят получающему почтовому серверу прошло ли письмо проверки, то DMARC объявляет как с такими сообщениями следует поступать.

Можно включить строгую политику и запретить доставку подобных писем, хотя не все почтовые сервисы следуют этим инструкциям буквально. В частности, почта Яндекса всё равно доставит письма, пусть и с пометкой, что это «возможно мошенничество». Есть у DMARC и возможность пропустить все письма без исключения, тогда проваленные проверки будут отражаться только в отчётах. Это бывает полезно при отладке технических заголовков.

В настройке DMARC-записей также поможет специальный сервис .

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

Итог

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

Согласно стандартам обмена электронными сообщениями, письма поддерживают некоторые заголовки, каждый из которых должен быть с новой строки. По умолчанию, в рассыльщике уже прописаны необходимые из них: MIME-Version, Content-Type, From, Reply-To, Subject, To . Записанные в поле заголовков новые RFC email , будут добавлены к имеющимся вшеуказанным.

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

Популярные RFC заголовки письма

* - означает например. Cc: (Carbon Copy) * Cc: [email protected]

Этот заголовок является расширением поля "To:", он указывает дополнительных получателей письма. Различий между "To:" и "Cc:" в сущности нет, если не считать, что некоторые почтовые программы рассматривают их по-разному, генерируя ответ на сообщение.

Bcc: (Blind Carbon Copy) * Bcc: [email protected]

Если вы видите этот заголовок в полученном сообщении - значит, что-то не так. Этот заголовок используется так же, как и "Cc:" (см. ниже), но не появляется в списке заголовков. Основная идея этого заголовка заключается в возможности посылать копии письма людям, которые не хотят получать ответы или появляться в заголовках. Слепые копии очень популярны среди спаммеров, поскольку многие неопытные пользователи оказываются сбитыми с толку, получив письмо, которое вроде бы не было им адресовано.

List-Unsubscribe: * List-Unsubscribe: или List-Unsubscribe:

По описанному функционалу, поле должно автоматически отписывать пользователя, если он нажал на кнопку "СПАМ", но зачастую под это поле выводится отдельная кнопака "Отписаться". Заголовок воспринимается не всеми почтовыми программами, т.к. это отличная возможнотсь проверить email адреса на используемость.

Priority: (X-MSMail-Priority: Importance:) * Priority: 1

Заголовок, устанавливающий приоритет сообщения. Иногда указывается, как X-Priority:, X-MSMail-Priority:, Importance:, принимает значения "Higt", "Normal", "Urgent", "Non-urgent" или дляX-Priority "1", "3", "5". Большинство программ его игнорируют. Часто используется спаммерами с целью привлечения внимания к сообщению установив 1.

Comments: * Comments: Люблю книги

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

Organization: * Organization: ОАО Костоправ

Абсолютно свободный заголовок, обычно содержащий название организации, через которую отправитель сообщения получает доступ к сети. Отправитель, как правило, контролирует этот заголовок, поэтому там вполне может быть что-то вроде "Королевское Сообщество Постановки Одного Над Другим".

Precedence: * Precedence: bulk

Значения: "bulk", "junk", "list". Указывает принадлежность письма к массовой рассылке. Синонимы X-List:*, X-Mirror:*, X-Auto:*, X-Mailing-List:*.

List-Owner: * List-Owner:

Email адрес организатора массовой рассылки.

X-Mailer: * X-Mailer: ePochta Mailer Disposition-Notification-To: * Disposition-Notification-To: [email protected]

На указанные реквизиты будет отправлено уведомление о прочтении. Зачастую игнорируется почтовиками, в целях борьбы со спамом. Синонимы: X-Confirm-Reading-To:, Return-Receipt-To:

X-*** * X-List:, X-Mailer:, X-...

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

Предисловие:

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

Инструментарий:

Итак, что же нам понадобится:

Прога для создания письма.
Подойдёт любая: TheBat!, АутГлюк и т.д. Если
нужно отослать более одного письма,
рекомендую SendIt.
Прога для массовой рассылки
писем с поддержкой использования прокси (Advanced
Direct Remailer , G-Loch
EasyMail , Advanced
Mass Sender , Group
Mail Free , Mega-MailerPro ,
Beijing Express Direct
Email Blaster и т.
д.)
Прога для работы других прог
через прокси: Socks Chain
и т. д.
Ну, и письмо от чела, чьим "двойником"
станешь.

Все эти проги я описывать не буду.
Это выходит за рамки моей статьи. Описание
прог под пунктом "2" можно найти в
последнем номере журнала "Хакер" (ver 02.03
(50)).

Принцип работы

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

Формирование письма

Самый первый этап работы
заключается в правильном создании письма.
"А что сложного в создании писем?"
спросишь ты. Под "созданием письма" я
имею ввиду не текст письма, а создание
заголовков. Итак, всем известно, что при передачи письма
почтовому серверу тот вставляет свой
заголовок в начало. Т. е. самый первый
заголовок будет от сервака, где находится
твоё мыло, т.к. он последний получил письмо. Наша задача состоит в том, чтобы отправить
письмо серверу где находится мыло жертвы
напрямую, т.е. минуя другие сервера, и при
этом притворится настоящим отправляющим
сервером.

Вот тут нам понадобятся две проги (или
одна — смотря какими пользуешься): любой
почтовик и одна из прог под пунктом 2.

В почтовике составляем текст
письма. Это уж как-нибудь без меня. После
того, как письмо написано, его нужно
перенаправить к проге ADR (Advanced Direct Remailer). Для
этого в настройках почтовика заполняем
поле SMTP сервера как "localhost" (без кавычек) и отправляем письмо. Теперь
заходим в ADR, кликаем правой кнопкой мыши на
письмо и выбираем "Посмотреть сообщение".
У нас высвечивается Блокнот, в котором
показаны текст письма и заголовки
почтовика. Текст письма не трогаем, а вот
заголовки удаляем и вставляем нужные. Для
этого надо открыть письмо того чела, кем мы
будем прикидываться и настроить почтовик
на показ заголовков (например, в русском TheBat!
это делается так: вид-> показывать
заголовки (RFC-822)).

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

Теперь лезем в настройки ADR.
Заходим в раздел "Доставка" и в поле
"Домен для "HELO"" пишем название
сервака, который отправляет почту (в
заголовках письма оно указано рядом с его IP).
Далее нам понадобится Socks Chain. В настройках
устанавливаем, через сколько проксей нужно
отправить письмо до того, как оно попадёт на
SMTP (хватит и одного). Не закрывая SC снова
лезем в настройки ADR-> "Прокси". Здесь
указываем адрес прокси как 127.0.0.1 и порт,
который стоит в настройках SC (по умолчанию
1081).

Всё, отправляем письмо.

From [email protected] Sun Dec 08 09:04:04 2002
Envelope-to: [email protected]
Delivery-date: Sun, 08 Dec 2002 09:04:04 +0300
Received: from (helo=webserver2.kaspersky-labs.com)
by mx5.mail.ru with smtp (Exim
SMTP.5)
id 18KuXr-000GQc-00
for [email protected]; Sun, 08 Dec 2002
09:04:04 +0300
From:
To: [email protected]
Subject: Тест.
Mime-Version: 1.0
Content-Type: text/plain; charset=windows-1251
Message-Id:
Date: Sun, 08 Dec 2002 09:04:04 +0300

Думаю, не для кого не секрет, кем я
хотел представиться 🙂

Проблемы

Иногда почтовые сервера с высокой
степенью защиты от спама не принимают почту,
если указать в "Домене для "HELO"" не
настоящее имя сервера, с которого пришло
письмо (такое было с mail.ru и hotbox.ru). Вероятно,
сервер сравнивает IP с какого идёт письмо (в
случае с использованием прокси — его адрес)
с IP сервера, на котором находится ящик
отсылающего. В этом случае письмо попадает
в "Плохие" с ошибкой "Почтовый ящик
не существует на этом сервере". Вероятные
решения этой проблемы:

Заменить имя домена на настоящее
(в случае использования прокси — указать
его IP)

Попытаться использовать IP-спуфинг

Сделать имя своего компа таким
же, как и у хоста, который указывается в
"Домен для "HELO" (на тот случай, если
твою машину при соединении регистрируют
в сети прова).

При отправке письма напрямую,
некоторые сервера отказываются работать,
если используется их служба, а в строке "От"
указан ящик, чей аккаунт находится у
другого сервера (такое было у mail.ru).

Сервер отказывается принять
письмо, если указан несуществующий
обратный адрес.

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

Плюсы и минусы данного способа

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

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

Заключение

Ну, вот и всё. Желаю тебе побед в
нелёгкой борьбе против ламеров.

Однако мало кто обращает внимание на заголовки сообщений. Некоторые из них пользователи видят при чтении электронной почты постоянно, это строки, начинающихся с To:, From: и Subject:. Однако заголовки содержат не только дружественные подсказки почтовой программы, но и другую, весьма содержательную информацию. Из заголовков можно узнать название и номер версии вашего почтового клиента, а также тип операционной системы, наименование и номер версии почтового сервера, внутренние IP-адреса и тип используемого в вашей организации брандмауэра (если он используется).

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

СТАНДАРТЫ

Заголовки электронной почты, как и все компоненты Internet, должны соответствовать стандартам, в данном случае - стандарту RFC 822. Отдельный стандарт, RFC 821, определяет формат «конверта» и описывает протоколы передачи почтовых сообщений, но это не относится к теме данной статьи. Спецификация RFC 822 была предложена для замены более раннего стандарта (RFC 733), с целью обеспечения передачи сообщений электронной почты между различными сетями. Обсуждаемые в данной статье заголовки необходимы для пересылки любого почтового сообщения через Internet или же между двумя внутренними серверами электронной почты, если они используют для этого стандартные протоколы TCP/IP. Эти понятия пояснены на Рисунке 1.

Возможно, ваша почтовая программа позволяет просматривать заголовки сообщений. Например, в случае Outlook, выбрав в меню View подменю Show Fields, вы увидите диалоговое окно с наименованиями некоторых из возможных полей, которые могут появляться в почтовых сообщениях.

Каждый заголовок начинается с наименования поля, за которым всегда следует двоеточие и пробел, например To: или Received:. Длинные строки заголовков «свернуты», или представлены несколькими строками, причем каждая дополнительная строка начинается как минимум с одного пробела. На Рисунке 1 первым полем заголовка является Received:, которое в действительности распространяется на три строки, за ним следует другое трехстрочное поле Received:.

Некоторые из названий полей, такие, как Date:, To:, Subject: и From:, сами говорят о своем назначении. Например, после имени поля From: расположен обратный адрес, а после To: - адрес получателя. Протокол SMTP (RFC 821) не требует, чтобы помещенный в поле From: адрес точно представлял отправителя. SMTP не располагает реальными средствами проверки того, что отправитель использует свой собственный адрес, хотя большинство почтовых серверов проверяет, как минимум, факт существования домена отправителя. Отсутствие контроля облегчает фальсификацию адресов отправителей сообщений, характерную, в частности, для спама.

ПОЛУЧАТЕЛИ

С точки зрения получения реальной информации об отправителе почтового сообщения заголовки Received: представляют существенно больший интерес, чем заголовки From:, которые легко фальсифицируются. Вообще говоря, любая строка заголовка может быть в какой-то мере подделана, так как заголовки представляют собой лишь текстовые данные, и только те из них, которые формируются вызывающими доверие серверами, могут считаться достоверными. Заголовки Received: добавляются каждым почтовым сервером, ретранслирующим данное сообщение, причем самый последний в цепочке почтовый сервер находится на первой позиции, а первый сервер, ретранслировавший сообщение, - на последней. На Рисунке 1 первый заголовок Received: показывает, что сервер bear.spirit.com получил сообщение для адресата [email protected] от узла 0nus.l0pht.com.

Первый заголовок предоставляет и другую интересную информацию. Данные в скобках, например (0nus.l0pht. com ), воспринимаются в качестве комментариев совместимыми почтовыми серверами. В данном случае программа sendmail на узле bear.spirit. com проверила, что система отправителя на самом деле имеет имя 0nus.l0pht.com и IP-адрес 199.201.145.3. Просмотр параметров соединения TCP/IP дал sendmail возможность определить IP-адрес, а затем поиск в системе DNS позволил узнать доменное имя сервера.

Второй заголовок Received: более интересен. Заметьте, что сообщение получено от , т. е. указан абсолютный IP-адрес системы 0nus, причем он одновременно показан как 199.201.145.3. В соответствии со стандартом RFC 1918 адреса IP, начинающиеся с 172.16, зарезервированы для частных сетей, поэтому они не предназначены для передачи через Internet и могут повторяться. В нашем примере заголовок Received: говорит о том, что 0nus функционирует в качестве брандмауэра домена l0pht (или его части) и осуществляет преобразование сетевых адресов (Network Address Translation, NAT). Вместе с тем, этот заголовок Received: информирует о том, что в домене 0nus работает Postfix - новый почтовый сервер, который компания Wietse Venema разработала для обеспечения максимально возможного уровня безопасности.

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

К настоящему моменту по информации заголовков Received: мы определили два почтовых сервера: sendmail и Postfix. Другие почтовые серверы Unix, а также Microsoft Exchange и Lotus Notes тоже оставляют свои отметки в заголовках Received:.

С определенной долей вероятности 0nus.l0pht.com представляет собой брандмауэр домена l0pht. В некоторых случаях можно не только догадываться, но и точно определить факт присутствия брандмауэра. Иногда он будет называться «firewall», «eagle», «fw1» или каким-либо другим легко распознаваемым именем, что найдет отражение в заголовках Received:. Некоторые брандмауэры, например компании Interlock, явно заявляют о своем присутствии, добавляя комментарий к строке Received:. Брандмауэр другого производителя помещает в это поле гораздо менее информативную строку, указывая, что «частная информация была удалена». Тем не менее, так как только этот производитель использует данный специфический комментарий, присутствие его брандмауэра становится почти таким же очевидным, как и брандмауэра Interlock.

ИСЧЕЗАЮЩИЕ ЗАГОЛОВКИ

Заголовки Received: предназначены для анализа проблем доставки электронной почты. Удаление этих заголовков не считается в Сети признаком хорошего тона, но некоторыми брандмауэрами они все же удаляются по желанию администратора. Я считаю удаление таких заголовков в сообщениях, покидающих вашу организацию, обоснованным действием: если вы несете ответственность за проблемы с электронной почтой в пределах вашей организации, то у вас вряд ли появится желание предоставить посторонним лицам возможность анализировать структуру вашей почтовой системы (и сети). Пока еще не все брандмауэры позволяют это сделать. (Как правило, только межсетевые экраны со шлюзами приложений настолько «умны», чтобы корректно осуществлять подобные операции.)

Спецификация RFC 822 требует наличия в сообщении заголовков Received:, поэтому их удаление может расцениваться как противоречие стандарту Internet. В частной переписке по электронной почте с персоналом поддержки Web-узла sendmail.org консультант порекомендовал такой метод избирательного удаления заголовков Received: - модификацию sendmail и создание файла конфигурации, где содержатся удаляемые адреса серверов. В то же время служба поддержки sendmail признала подобную модификацию противоречащей духу стандарта RFC и порекомендовала скрывать частные данные в заголовках посредством их замены на хэшированные записи.

ЭТО ЕЩЕ НЕ ВСЕ

Некоторые из известных атак оказались возможны благодаря использованию ошибок синтаксического разбора заголовков. Совсем недавно Microsoft выпустила «заплатку» для модуля inetcomm.dll, к которому программы Outlook и Outlook Express обращаются для анализа, помимо прочего, заголовок Date:. При переполнении поля Date: в этих почтовых программах наблюдались сбои или даже выполнение произвольного кода (если переданные данные использовали переполнение буфера).

Как можно узнать, с какой программой работает данный пользователь: Outlook, Outlook Express или какой-либо другой? Посмотрите на заголовок x-mailer:. В случае, изображенном на Рисунке 1, отправитель Джолли пользовался почтовым клиентом Claris Emailer, что говорит также о том, что он работает на компьютере Macintosh (пакет прикладных программ Claris доступен только для Macintosh).

Почта Internet, как и большая часть его элементов, не разрабатывалась для отражения внутренних атак. Многие годы Internet был средством общения энтузиастов, объединяя компьютеры на основе общих протоколов, определенных стандартами RFC. Безопасность же и исходная цель Internet - обеспечение межсоединения - находятся в противоречии друг с другом.

Средства шифрования и цифровой подписи для электронной почты, такие, как, например, PGP (Pretty Good Privacy), не решают проблемы, так как они только обеспечивают конфиденциальность почтовых сообщений и аутентифицируют отправителя. Для предотвращения злоупотреблений, с которыми мы сталкиваемся сегодня, стандарты почтовых сообщений должны быть изменены радикально. Но уже сейчас заголовки исходящей электронной корреспонденции вашей организации можно фильтровать, удаляя из них внутреннюю информацию, которой может воспользоваться внешний злоумышленник.

Рик Фэрроу - независимый консультант по вопросам безопасности. С ним можно связаться по адресу: [email protected] .

Ресурсы Internet

Стандарт Internet на заголовки почтовых сообщений опубликован по адресу: http://www.faqs.org/rfcs/rfc822.html .

Почтовый сервер Postfix компании Wietse Venema расположен на странице http://www.porcupine.org/postfixmirror/start.html .

Рекомендации Microsoft относительно ошибок в модуле inetcomm.dll для разбора ряда заголовков почтового сообщения можно найти по адресу: http://www.microsoft.com/technet/security/bulletin/ms00-043.asp .

Полезные советы по использованию sendmail для маскировки (перезапись заголовков сообщений так, чтобы все они содержали адрес домена, а не адреса внутренних систем вашего домена) можно найти по адресу: