Ken Lucke,Влад Никифоров. Все о заголовках электронных писем

Все о заголовках электронных писем

Автор: Ken Lucke

Перевод: Влада Никифорова

Этот документ дает всестороннее представление о том, какие бывают заголовки электронных писем. В первую очередь он предназначен для тех, кто пытается определить истинный источник незванных и раздражающих электронных посланий ("спама"), которые обычно подделываются; но он может помочь и жертвам любых других поддельных писем. Этот документ может может также оказаться полезным для читателей, интересующихся общей информацией об электронной почте и ее передаче в сети Интернет.

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

Данный документ содержит некоторое количество фиктивных доменных имен и ассоциированных с ними IP-адресов (Internet Protocol). Однако существует ненулевая вероятность, что эти доменные имена в будущем будут использованы. Аналогично, все IP-адреса, использованные в примерах и не существующие на момент написания, несомненно, будут рано или поздно задействованы. Естественно, содержание документа не предполагает никакой связи с будущими пользователями этих доменных имен и IP-адресов.

Этот раздел содержит краткий анализ жизни одного электронного письма. Небольшое лирическое отступление поможет понять, что же нам говорят заголовки.

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

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

Представим себе двух фиктивных пользователей: <rth@bieberdorf.edu> и <tmh@immense-isp.com>. tmh - клиент провайдера Immense ISP, Inc., связывающийся с ним по телефонной линии ("диалапный" клиент) и использующий почтовую программу Loris Mail (тоже, кстати, несуществующую); rth - студент Бибердорфского Института, на его столе стоит компьютер, соединенный с локальной сетью института.

Если rth хочет послать письмо tmh, он пишет это письмо на своем компьютере (который называется, допустим, alpha.bieberdorf.edu); отправленный текст затем передается на почтовый сервер, mail.bieberdorf.edu. (Это последний момент, когда rth видит свое письмо - теперь процесс доставки уже никак от него не зависит). Почтовый сервер, видя, что письмо предназначено кому-то на immense-isp.com, связывается с его почтовым сервером по имени, допустим, mailhost.immense-isp.com, и передает ему письмо. Теперь письмо будет лежать на mailhost.immense-isp.com до тех пор, пока tmh не позвонит со своего домашнего компьютера и не заберет почту - в этот момент почтовый сервер отдаст ему всю ожидающую его корреспонденцию, включая и письмо от rth.

В течение вышеупомянутого процесса к письму трижды будут добавлены заголовки: в момент создания письма той самой программой, которую использует rth, в момент передачи письма на mail.bieberdorf.edu и в момент передачи с бибердорфской машины на машину Immense (обычно диалапные узлы, забирая почту, никаких заголовков не добавляют). Давайте проследим появление этих заголовков:

В момент передачи только что созданного почтовой программой rth сообщения на mail.bieberdorf.edu:
From: rth@bieberdorf.edu (R.T. Hood)
To: tmh@immense-isp.com
Date: Tue, Mar 18 1997 14:36:14 PST
X-Mailer: Loris v2.32
Subject: Lunch today?

В момент передачи сообщения узлом mail.bieberdorf.edu на узел mailhost.immense-isp.com:
Received: from alpha.bieberdorf.edu (alpha.bieberdorf.edu [124.211.3.11]) by mail.bieberdorf.edu (8.8.5) id 004A21; Tue, Mar 18 1997 14:36:17 -0800 (PST)
From: rth@bieberdorf.edu (R.T. Hood)
To: tmh@immense-isp.com
Date: Tue, Mar 18 1997 14:36:14 PST
Message-Id: <rth031897143614-00000298@mail.bieberdorf.edu>
X-Mailer: Loris v2.32
Subject: Lunch today?

В момент, когда mailhost.immense-isp.com получает письмо и откладывает его для tmh:
Received: from mail.bieberdorf.edu (mail.bieberdorf.edu [124.211.3.78]) by mailhost.immense-isp.com (8.8.5/8.7.2) with ESMTP id LAA20869 for ; Tue, 18 Mar 1997 14:39:24 -0800 (PST)
Received: from alpha.bieberdorf.edu (alpha.bieberdorf.edu [124.211.3.11]) by mail.bieberdorf.edu (8.8.5) id 004A21; Tue, Mar 18 1997 14:36:17 -0800 (PST)
From: rth@bieberdorf.edu (R.T. Hood)
To: tmh@immense-isp.com
Date: Tue, Mar 18 1997 14:36:14 PST
Message-Id: <rth031897143614-00000298@mail.bieberdorf.edu>
X-Mailer: Loris v2.32
Subject: Lunch today?

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

Received: from mail.bieberdorf.edu
Это письмо было получено с компьютера, который назвался mail.bieberdorf.edu...
(mail.bieberdorf.edu [124.211.3.78])
...и который действительно называется mail.bieberdorf.edu (т.е., он идентифицировал себя верно - см. раздел "Заголовки конверта" для более подробного рассмотрения этого момента) и его IP-адрес 124.211.3.78.
by mailhost.immense-isp.com (8.8.5/8.7.2)
Принимал сообщение компьютер mailhost.immense-isp.com; на нем работала программа sendmail версии 8.8.5/8.7.2 (если вы не знаете, что эти номера означают - не обращайте на них внимания).
with ESMTP id LAA20869
Принимающий компьютер присвоил сообщению идентификационный номер LAA20869. (Эта информация будет использоваться только на данном компьютере, если его администратору потребуется найти это сообщение в протоколах; для всех остальных она обычно не имеет значения.)
for <tmh@immense-isp.com>;
Сообщение адресовано tmh@immense-isp.com. Отметим, что этот заголовок не связан со строчкой "To:" (см. раздел "Заголовки конверта").
Tue, 18 Mar 1997 14:39:24 -0800 (PST)
Передача письма производилась во вторник, 18 марта 1997 года в 14:39:24 по тихоокеанскому поясному времени (PST - Pacific Standard Time), отстающему от Гринвичского часового пояса на 8 часов, откуда и взялось "-0800".

Received: from alpha.bieberdorf.edu (alpha.bieberdorf.edu [124.211.3.11]) by mail.bieberdorf.edu (8.8.5) id 004A21; Tue, Mar 18 1997 14:36:17 -0800 (PST)
Эта строка свидетельствует о передаче письма с alpha.bieberdorf.edu (компьютер rth) на mail.bieberdorf.edu; эта передача произошла в 14:36:17 тихоокеанского поясного времени. Посылающая машина назвалась alpha.bieberdorf.edu, ее реальное имя также alpha.bieberdorf.edu и ее IP-адрес 124.211.3.11. На бибердорфском почтовом сервере работает программа sendmail версии 8.8.5 и она присвоила письму для своих внутренних нужд идентификационный номер 004A21.

From: rth@bieberdorf.edu (R.T. Hood)
Письмо было отправлено с адреса rth@bieberdorf.edu, назвавшего свое настояшее имя: R.T. Hood.

To: tmh@immense-isp.com
Письмо было адресовано tmh@immense-isp.com.

Date: Tue, Mar 18 1997 14:36:14 PST
Сообщение было создано во вторник, 18 марта 1997 года в 14:36:14 по тихоокеанскому поясному времени.

Message-Id: <rth031897143614-00000298@mail.bieberdorf.edu>
Сообщению был присвоен этот идентификационный номер (машиной mail.bieberdorf.edu). Этот номер отличается от номеров SMTP и ESMTP ID в заголовках "Received:", потому что он присваивается письму "на всю жизнь", в то время как остальные номера ассоциируются с конкретной операцией передачи письма на конкретной машине, таким образом, эти номера не имеют никакого смысла для остальных машин. Иногда (как в этом примере) номер Message-Id содержит адрес отправителя, но чаще он не несет в себе никакого видимого смысла.

X-Mailer: Loris v2.32
Сообщение было послано программой Loris версии 2.32.

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

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

Давайте вернемся к примеру в предыдущем разделе, конкретно, к месту, где mail.bieberdorf.edu соединяется с mailhost.immense-isp.com. В действительности в этот момент mail.bieberdorf.edu открывает соединение с портом 25 машины mailhost.immense-isp.com и посылает письмо через это соединение вместе со служебной информацией. Команды, которые он использовал для этого, и ответы принимающей системы являются более-менее читаемыми - это команды старого языка SMTP (Simple Mail Transfer Protocol). Если "подслушать" этот "разговор" между компьютерами, можно будет увидеть нечто вроде следующего (команды, передаваемые машиной mail.bieberdorf.edu выделены жирным шрифтом):
220 mailhost.immense-isp.com ESMTP Sendmail 8.8.5/1.4/8.7.2/1.13; Tue, Mar 18 1997 14:38:58 -0800 (PST)
HELO mail.bieberdorf.edu
250 mailhost.immense-isp.com Hello mail.bieberdorf.edu [124.211.3.78], pleased to meet you
MAIL FROM: rth@bieberdorf.edu
250 rth@bieberdorf.edu... Sender ok
RCPT TO: tmh@immense-isp.com
250 tmh@immense-isp.com... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
Received: from alpha.bieberdorf.edu (alpha.bieberdorf.edu [124.211.3.11]) by mail.bieberdorf.edu (8.8.5) id 004A21; Tue, Mar 18 1997 14:36:17 -0800 (PST)
From: rth@bieberdorf.edu (R.T. Hood)
To: tmh@immense-isp.com
Date: Tue, Mar 18 1997 14:36:14 PST
Message-Id: <rth031897143614-00000298@mail.bieberdorf.edu>
X-Mailer: Loris v2.32
Subject: Lunch today?

--rth
.
250 LAA20869 Message accepted for delivery
QUIT
221 mailhost.immense-isp.com closing connection

Весь сеанс связи прошел с использованием пяти команд, составляющих основу SMTP (существуют и другие, но они являются вспомогательными и не используются непосредственно в процессе передачи письма): HELO, MAIL FROM, RCPT TO, DATA и QUIT.

HELO идентифицирует посылающую машину. "HELO mail.bieberdorf.edu" следует читать как "Привет, я mail.bieberdorf.edu". Отправитель, однако, может солгать; ничто, в принципе, не помешает узлу mail.bieberdorf.edu сказать: "Привет, я frobozz.xyzzy.gov" (HELO frobozz.xyzzy.gov), или даже: "Привет, я криво настроенный компьютер" (HELO a misconfigured computer). Однако, в большинстве случаев получатель имеет возможность раскрыть истинную личность отправителя.

MAIL FROM инициирует обработку почты. Эта команда означает: "У меня есть почта от такого-то". Адрес, указанный в команде, впоследствии превращается в так называемую "конвертную" строчку "From" (см. раздел "Заголовки конверта"), причем этот адрес не обязан совпадать с настоящим адресом отправителя! Эта очевидная "дырка" в системе безопасности неизбежна (в конце концов, получающая машина не знает имен пользователей на отправляющей машине) и в некоторых случаях оказывается даже полезной.

RCPT TO - команда, парная к MAIL FROM, она указывает получателя письма. Одно и то же письмо может быть доставлено нескольким получателям посредством использования нескольких команд RCPT TO (см. раздел о перекладывании почты, где объясняется, как иногда этой возможностью злоупотребляют на плохо настроенных системах). Указанный адрес формирует "конвертную" строчку "To" (см. раздел "Заголовки конверта") и именно по этому адресу будет доставлено письмо вне зависимости от того, что написано в строчке "To:".

DATA начинает непосредственную передачу письма. Все, что вводится после команды DATA, считается частью сообщения. Никаких ограничений на вводимые данные нет. Начальные несколько строк (перед первой пустой строкой), начинающиеся словом с двоеточием, большинством почтовых программ расценивается как заголовки. Строка, состоящая из одной точки, завершает сообщение.

SMTP полностью описан в документе RFC 821. Копии документов RFC широко распространены и доступны в сети Интернет. RFC 821 может пролить много света на различные сложности в обработке почты.

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

Многие, может быть даже большинство организаций, имеющих подключенный к сети Интернет компьютеры защищаются так называемыми файрволлами (firewall). Файрволл - это компьютер, чья основная задача состоит в роли привратника, разделяющего компьютеры организации и все остальные компьютеры в огромной всемирной сети (так, например, взломщики не могут запросто подсоединиться к корпоративной сети IBM и украсть секреты компании). С точки зрения другого компьютера, пытающегося доставить почту системе, находящейся за файрволлом это означает, что он не может установить соединение непосредственно с этой системой; сначала он должен соединиться с файрволлом.

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

Если immense-isp.com использует файрволл, то заголовки в нашем примере будут выглядеть следующим образом. Обратите внимание на первую строчку "Received:". (Я здесь предполагаю, что машина-файрволл называется firewall.immense-isp.com; на самом деле присвоение машине имя вроде firewall означает вызов всем малолетним хакерам немедленно взломать эту машину, так что файрволлы обычно носят неприметные имена.)
Received: from firewall.immense-isp.com (firewall.immense-isp.com [121.214.13.129]) by mailhost.immense-isp.com (8.8.5/8.7.2) with ESMTP id LAA20869 for <tmh@immense-isp.com>; Tue, 18 Mar 1997 14:40:11 -0800 (PST)
Received: from mail.bieberdorf.edu (mail.bieberdorf.edu [124.211.3.78]) by firewall.immense-isp.com (8.8.3/8.7.1) with ESMTP id LAA20869 for ; Tue, 18 Mar 1997 14:39:24 -0800 (PST)
Received: from alpha.bieberdorf.edu (alpha.bieberdorf.edu [124.211.3.11]) by mail.bieberdorf.edu (8.8.5) id 004A21; Tue, Mar 18 1997 14:36:17 -0800 (PST)
From: rth@bieberdorf.edu (R.T. Hood)
To: tmh@immense-isp.com
Date: Tue, Mar 18 1997 14:36:14 PST
Message-Id: <rth031897143614-00000298@mail.bieberdorf.edu>
X-Mailer: Loris v2.32
Subject: Lunch today?

Аналогично, если вся исходящая почта от bieberdorf.edu пересылается через файрволл, в заголовках будет появляться еще одна строчка "Received:", добавляемая этим файрволлом. Точно таким же образом любой компьютер, не обязательно файрволл, может быть одним из пунктов в маршруте почты. У immense-isp.com может быть много расположены далеко друг от друга компьютеров, несколько отдельных почтовых серверов - и все они используют один компьютер (названный, например, mailgate.immense-isp.com), решающий, через какой из серверов пересылать входящую почту. Так что следующий пример, хоть он и является несколько искусственным, все же вполне возможен:
Received: from mailgate.immense-isp.com (mailgate.immense-isp.com [121.214.11.102]) by mailhost3.immense-isp.com (8.8.5/8.7.2) with ESMTP id LAA30141 for <tmh@immense-isp.com>; Tue, 18 Mar 1997 14:41:08 -0800 (PST)
Received: from firewall.immense-isp.com (firewall.immense-isp.com [121.214.13.129]) by mailgate.immense-isp.com (8.8.5/8.7.2) with ESMTP id LAA20869 for <tmh@immense-isp.com>; Tue, 18 Mar 1997 14:40:11 -0800 (PST)
Received: from firewall.bieberdorf.edu (firewall.bieberdorf.edu [124.211.4.13]) by firewall.immense-isp.com (8.8.3/8.7.1) with ESMTP id LAA28874 for <tmh@immense-isp.com>; Tue, 18 Mar 1997 14:39:34 -0800 (PST)
Received: from mail.bieberdorf.edu (mail.bieberdorf.edu [124.211.3.78]) by firewall.bieberdorf.edu (8.8.5) with ESMTP id LAA61271; Tue, 18 Mar 1997 14:39:08 -0800 (PST)
Received: from alpha.bieberdorf.edu (alpha.bieberdorf.edu [124.211.3.11]) by mail.bieberdorf.edu (8.8.5) id 004A21; Tue, Mar 18 1997 14:36:17 -0800 (PST)
From: rth@bieberdorf.edu (R.T. Hood)
To: tmh@immense-isp.com
Date: Tue, Mar 18 1997 14:36:14 PST
Message-Id: <rth031897143614-00000298@mail.bieberdorf.edu>
X-Mailer: Loris v2.32
Subject: Lunch today?

Историю жизни письма можно восстановить, читая заголовки "Received:" снизу вверх. Письмо ушло от alpha.bieberdorf.edu на mail.bieberdorf.edu, затем через firewall.bieberdorf.edu, firewall.immense-isp.com и mailgate.immense-isp.com пришло на mailhost3.immense-isp.com, где и осталось ждать, пока tmh заберет его.

Вот пример заголовка письма с несколько другим "жизненным циклом" по сравнению с ранее рассмотренными:
Received: from unwilling.intermediary.com (unwilling.intermediary.com [98.134.11.32]) by mail.bieberdorf.edu (8.8.5) id 004B32 for <rth@bieberdorf.edu>; Wed, Jul 30 1997 16:39:50 -0800 (PST)
Received: from turmeric.com ([104.128.23.115]) by unwilling.intermediary.com (8.6.5/8.5.8) with SMTP id LAA12741; Wed, Jul 30 1997 19:36:28 -0500 (EST)
From: Anonymous Spammer <junkmail@turmeric.com>
To: (здесь должен быть список получателей)
Message-Id: <w45qxz23-34ls5@unwilling.intermediary.com>
X-Mailer: Massive Annoyance
Subject: WANT TO MAKE ALOT OF MONEY???

Многое в этом заголовке указывает на то, что перед нами пример "электронного мусора", но сконцентрировать свое внимание следует прежде всего на строчках "Received:". Это письмо пришло с узла turmeric.com, прошло через unwilling.intermediary.com, а уже оттуда было доставлено к месту назначения на mail.bieberdorf.edu. Все хорошо и здорово, но как сюда попал узел unwilling.intermediary.com, ведь он не относится ни к отправляющей системе, ни к принимающей?

Ответ потребует некоторого углубления в протокол SMTP. По существу, turmeric.com просто соединился через SMTP-порт с узлом unwilling.intermediary.com и сказал ему: "Отправбь это сообщение по адресу rth@bieberdorf.edu". И сделал он это, очевидно, передав команду RCPT TO: rth@bieberdorf.edu. В этот момент узел unwilling.intermediary.com взял на себя обработку этого сообщения. Поскольку его попросили отправить письмо по адресу, находящемуся в другом домене (bieberdorf.edu), он выяснил имя почтового сервера для этого домена и передал письмо обычным порядком. Этот процесс известен как перекладывание почты (mail relaying).

Исторически разрешение на перекладывание почты имеет свои причины. Вплоть до конца 80-х в большей части мировой сети, компьютеры редко общались непосредственно друг с другом. Вместо этого они формировали некоторый маршрут и передавали почту по этому маршруту, шаг за шагом. Это была довольно громоздкая и неудобная схема (особенно с учетом того, что часто отправителю приходилось самому разрабатывать маршрут). В качестве аналогии представьте себе маршрут реального письма из Сан-Франциско в Нью-Йорк, выглядящий примерно так:
Сан-Франциско, Сакраменто, Рено, Солт-Лейк-Сити, Рокспрингс, Лереми, Северный Платт, Линкольн, Омаха, Де-Мойн, Сидар-Рапидс, Дубьюк, Рокфор, Чикаго, Гэри, Элкхарт, Форт Уэйн, Толидо, Кливлэнд, Эри, Эльмира, Уильямспот, Ньюарк, Нью-Йорк, деревня Гринвич, Десолейшн-Роу 12-35, Циммерманну Р.А.
С точки зрения почтальона система понятна: например, почтовому отделению в городе Гэри штата Индиана проще связаться только с соседними отделениями в Чикаго и Элкхарте, чем самостоятельно пытаться доставить почту в Нью-Йорк (также понятно, почему эта схема не очень хороша с точки зрения отправителя, и почему электронная почта более не отсылается таким способом). Именно так и отправлялась раньше электронная почта: узлам было необходимо уметь сказать: "У меня есть письмо для rth@bieberdorf.edu, ты должен послать его по маршруту turmeric.com, galangal.org, asafoetida.com, bieberdorf.edu". Отсюда и пошло перекладывание почты.

Однако сейчас перекладывание используется неэтичными рекламщиками в качестве метода сокрытия источника своих сообщений, перенаправляя поток жалоб со своего провайдера на ни в чем не повинный узел, на который была переложена обязанность по отправке почты. (Это также избавляет машину спаммера от обработки адресов получателей и попытки установить связь с их почтовыми серверами и перекладывает эту работу на промежуточный сервер. Подобное использование перекладывания, особенно при широкомасштабных массовых рассылках, фактически "крадет" машинное время сервера у его клиентов, заставляя его проделывать массу ненужной ему работы.) Здесь важно отметить, что за содержимое письма отвечает отправитель, - в данном примере это turmeric.com; помежуточный же узел, unwilling.intermediary.com, становится лишь невольным посредником. Он не имеет влияния на отправителя, равно как и почтовое отделение в Гэри не властно над отправителем письма из Сан-Франциско (Он, однако, может отключить возможность перекладывания почты на свой узел!).

Следует еще кое-что отметить: строка "Message-Id:" была вписана не отправляющей машиной (turmeric.com), а "перекладной" (unwilling.intermediary.com). Это обычная ситуация для перекладываемой почты; она всего лишь иллюстрирует, что отправляющая машина не указала Message-Id.

В разделе, рассматривающем протокол SMTP, содержатся упоминания о различии между "заголовками сообщения" и "заголовками конверта". Здесь мы рассмотрим эти различия более подробно.

Грубо говоря, "конвертный" заголовок - это заголовок, созданный не отправителем сообщения, а компьютером, через который прошло это сообщение. Исходя из такого определения, все строчки "Received:" являются заголовками конверта, однако обычно этим термином называют только "конвертные" строчки "From" и "To".

Конвертный заголовок "From" формируется на базе информации, полученной от команды MAIL FROM. Например, если отправляющая машина говорит MAIL FROM: ginger@turmeric.com, получающая машина сгенерирует строчку следующего вида:
>From ginger@turmeric.com
Отметим, что после слова "From" нет двоеточия. Чаще всего конвертные заголовки не содержат двоеточий; и, хотя это не повсеместная практика, она достаточно распространена, чтобы обращать на это внимание.

Аналогично, конвертный заголовок "To" порождается командой RCPT TO. Если отправитель сказал RCPT TO: tmh@bieberdorf.edu, то конвертный "To" будет содержать адрес tmh@bieberdorf.edu. Эта информация часто идет не отдельным заголовком, а включается в заголовок "Received:".

Из существования конвертных заголовков вытекает важное следствие: информация, заключенная в заголовках сообщения "From:" и "To:" не имеет никакого значения. Содержимое заголовков "From:" и "To:" предоставляется отправителем. Пересылка почты базируется только на конвертных заголовках "To" и никогда - на заголовках сообщения "To:".

Рассмотрим пример сеанса SMTP:
HELO galangal.org
250 mail.bieberdorf.edu Hello turmeric.com [104.128.23.115], pleased to meet you
MAIL FROM: forged-address@galangal.org
250 forged-address@galangal.org... Sender ok
RCPT TO: tmh@bieberdorf.edu
250 tmh@bieberdorf.edu... Recipient OK
DATA
354 Enter mail, end with "." on a line by itself
From: another-forged-address@lemongrass.org
To: (your address suppressed for stealth mailing and annoyance)
.
250 OAA08757 Message accepted for delivery
А вот получившийся в результате заголовок письма (приведен не полностью для простоты):
>From forged-address@galangal.org
Received: from galangal.org ([104.128.23.115]) by mail.bieberdorf.edu (8.8.5) for <tmh@bieberdorf.edu>...
From: another-forged-address@lemongrass.org
To: (your address suppressed for stealth mailing and annoyance)
Отметим, что содержимое заголовка конверта From, а также заголовков сообщения "From:" и "To:" продиктовано отправителем, и не имеет ничего общего с действительностью! Этот пример иллюстрирует тот факт, что никогда нельзя доверять заголовкам "From", "From:" и "To:" в письмах, которые могут оказаться фальшивыми, так как эти заголовки очень легко подделать.

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

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

Если, например, машина turmeric.com, IP-адрес которой 104.128.23.115, посылает сообщение машине mail.bieberdorf.edu, но пытается ее обмануть, сказав HELO galangal.org, заголовок "Received:" получится следующим:
Received: from galangal.org ([104.128.23.115]) by mail.bieberdorf.edu (8.8.5)...
(Остаток строки опущен для ясности.) Отметим, что хоть компьютер bieberdorf.edu и не говорит, что galangal.org не является на самом деле отправителем, он, тем не менее, протоколирует настоящий IP-адрес отправителя. Если получатель письма решит, что появление имени galangal.org в заголовке является результатом фальсификации, он может запросить имя, соответствующее IP-адресу 104.128.23.115 (например, с помощью UNIX-команды nslookup) и узнать, что на самом деле этот адрес принадлежит turmeric.com, а не galangal.org. Иными словами, протоколирование IP-адреса отправляющей машины предоставляет достаточно информации, чтобы подтвердить или опровергнуть подозрения о подделке.

Многие современные почтовые программы автоматизируют этот процесс, запрашивая соответствие имени самостоятельно (этот процесс называется "обратным DNS" (от Domain Name Service); обратным, потому что он является обратным обычному процессу разрешения имен в IP-адреса, производимому при маршрутизации). Если mail.bieberdorf.edu использует подобное программное обеспечение, то строчка "Received" будет начинаться примерно так:
Received: from galangal.org (turmeric.com [104.128.23.115]) by mail.bieberdorf.edu...
Здесь подделка сразу выводится на чистую воду. Данная строка говорит: "машина turmeric.com, чей адрес 104.128.23.115, назвалась galangal.org". Излишне говорить, что эта информация исключительно ценна при идентификации и отслеживании поддельных писем! (Именно по этой причине спаммеры стараются избегать использования "перекладных" машин, которые протоколируют информацию запроса обратного DNS. Иногда им даже удается найти машины, которые не протоколируют даже IP-адрес, как это было описано выше; но таких машин в сети уже почти не осталось.)

Другая распространенная уловка, которая становится все более популярной при подделке писем, заключается в добавлении ложных заголовков "Received:" перед отправлением поддельного письма. Например, если такое письмо отправлено с компьютера turmeric.com, заголовки "Received:" могут выглядеть так:
Received: from galangal.org ([104.128.23.115]) by mail.bieberdorf.edu (8.8.5)...
Received: from nowhere by fictitious-site (8.8.3/8.7.2)...
Received: No Information Here, Go Away!
Очевидно, две последние строки являются ложью, написанной отправителем и добавленной к сообщению перед отправкой.

Поскольку отправитель не имеет контроля над письмом с момента его отправки с turmeric.com, а заголовки "Received:" всегда добавляются сверху, то поддельные строки обязательно окажутся внизу списка. Это означает, что, читая строки сверху вниз, отслеживая историю сообщения, можно спокойно отбросить все, что находится ниже первой поддельной строки. Даже если все последующие строчки "Received:" выглядят правдоподобно, они, несомненно, являются подделкой.

Разумеется, отправитель не будет писать откровенный мусор. Настоящий спаммер создаст правдоподобный список строк "Received:" вроде следующего:
Received: from galangal.org ([104.128.23.115]) by mail.bieberdorf.edu (8.8.5)...
Received: from lemongrass.org by galangal.org (8.7.3/8.5.1)...
Received: from graprao.com by lemongrass.org (8.6.4)...
В этом примере единственной точкой опоры является неверный IP-адрес узла galangal.org в первой строчке "Received:". Подделку было бы еще труднее выловить, если бы спаммер вписал верные IP-адреса узлов lemongrass.org и graprao.com, но все равно несоответствие IP-адреса в первой строчке неопровержимо указывало бы на то, что все оставшиеся строки ложные, и письмо было отправлено с узла с IP-адресом 104.128.23.115 (т.е., turmeric.com). Однако, большинство подделок не столь качественны, и чаще всего ложные строчки "Received:" содержат очевидный мусор.

Apparently-To: Сообщения с большим количеством получателей иногда имеют длинный список заголовков вида "Apparently-To: rth@bieberdorf.edu" (по одной строчке на получателя). Эти заголовки нетипичны для нормальных сообщений, они обычно являются признаком массовой рассылки. В последнее время для массовых рассылок используется программное обеспечение, достаточно "умное", чтобы не плодить гигантские списки из этих заголовков.
Bcc: (Blind Carbon Copy - слепая копия) Если вы видите этот заголовок в полученном сообщении - значит, что-то не так. Этот заголовок используется так же, как и "Cc:" (см. ниже), но не появляется в списке заголовков. Основная идея этого заголовка заключается в возможности посылать копии письма людям, которые не хотят получать ответы или появляться в заголовках. Слепые копии очень популярны среди спаммеров, поскольку многие неопытные пользователи оказываются сбитыми с толку, получив письмо, которое вроде бы не было им адресовано.
Cc: (Carbon Copy - копия) Этот заголовок является расширением поля "To:", он указывает дополнительных получателей письма. Различий между "To:" и "Cc:", в сущности, нет, если не считать, что некоторые почтовые программы рассматривают их по-разному, генерируя ответ на сообщение.
Comments: Этот заголовок не является стандартным, может содержать любую информацию. Чаще всего используется в виде "Comments: Authenticated sender is <rth@bieberdorf.edu>". Подобные заголовки добавляются некоторыми почтовыми программами (в частности, популярной программой Pegasus) для идентификации отправителя, но часто прописывается и вручную спаммерами, так что относиться к нему следует с осторожностью.
Content-Transfer-Encoding: Этот заголовок относится к MIME, стандартному методу помещения в письмо нетекстовой информации. Он не имеет никакого отношения к доставке почты, отвечает только за то, как программа-получатель интерпретирует содержимое сообщения.
Content-Type: Еще один MIME-заголовок, сообщающий почтовой программе о типе данных, хранящихся в сообщении.
Date: Назначение этого заголовка очевидно: он указывает дату создания и отправления сообщения. Если этот заголовок не был создан на компьютере отправителя, то, возможно, его добавит почтовый сервер или какой-нибудь другой компьютер, через который пройдет письмо. Его ни в коем случае нельзя принимать за непреложную истину, и дело даже не в возможности подделки - в мире чудовищно большое количество компьютеров с неверно идущими часами.
Errors-To: Указывает адрес для отсылки автоматически генерируемых сообщений об ошибке, таких как "нет такого пользователя". Это редко используемый заголовок, так как большинство отправителей обычно хотят получать сообщения об ошибках на исходящий адрес, который используется почтовыми серверами по умолчанию.
From (без двоеточия) Это заголовок конверта, о котором говорилось выше.
From: (с двоеточием) Это заголовок сообщения, о котором говорилось выше.
Message-Id: (также Message-id: или Message-ID:) Заголовок Message-Id представляет более или менее уникальный идентификатор, присваиваемый каждому сообщению, чаще всего первым почтовым сервером, который встретится у него на пути. Обычно он имеет форму "abrakadabra@bieberdorf.edu", где "abrakadabra" может быть абсолютно чем угодно, а вторая часть - имя машины, присвоившей идентификатор. Иногда, но редко, "abrakadabra" включает в себя имя отправителя. Любое письмо, где структура идентификатора нарушена (например, пустая строка или отсутствует знак @), или вторая часть идентификатора не является реальным интернет-сайтом, - скорее всего, подделка.
In-Reply-To: Заголовок Usenet, который иногда появляется и в письмах. "In-Reply-To:" указывает идентификатор некоего сообщения, на которое данное сообщение является ответом. Этот заголовок нетипичен для писем, если только письмо действительно не является ответом на сообщение в Usenet. Спаммеры иногда им пользуются, возможно, чтобы обойти фильтрующие программы.
Mime-Version: (или MIME-Version:) Еще один MIME-заголовок, обозначающий версию MIME-протокола, который использовался отправителем. Как и остальные MIME-заголовки, его вполне можно игнорировать: все современные почтовые программы разберутся, что с ним делать.
Newsgroups: Этот заголовок появляется только в письмах, связанных с Usenet: либо в копии отправленного в Usenet сообщения, или в ответе на эти сообщения. В первом случае он указывает конференцию(и), в которые сообщение было послано, а во втором - конференции(ю), в которые было послано сообщение, на которое данное письмо является ответом. Семантика этого заголовка является предметом вялотекущей "священной войны" за то, что в ближайшем будущем обе семантики сообщений будут использоваться совместно.
Organization: Абсолютно свободный заголовок, обычно содержащий название организации, через которую отправитель сообщения получает доступ к сети. Отправитель, как правило, контролирует этот заголовок, поэтому там вполне может быть что-то вроде "Королевское Сообщество Постановки Одного Над Другим".
Priority: Исключительно свободный заголовок, устанавливающий приоритет сообщения. Большинство программ его игнорируют. Часто используется спаммерами в форме "Priority: urgent" (или что-нибудь в этом роде) с целью привлечения внимания к сообщению.
Received: Детально обсуждался выше.
References: Заголовок "References:" редко используется в почтовых сообщениях, за исключением копий Usenet-сообщений. Он используется в Usenet для прослеживания "дерева ответов", к которому принадлежит данное сообщение. Если он появился в письме, то это письмо является копией Usenet-сообщения. Он также может появляться в почтовых ответах на Usenet-сообщения, присваивая идентификатор и отвечаемому сообщению, и всем его "вышестоящим предкам".
Reply-To: Указывает адрес, на который следует посылать ответы. Несмотря на то, что этот заголовок имеет множество способов цивилизованного применения, он также используется спаммерами для отведения удара от себя. Может быть, какой-нибудь наивный спаммер и захочет собирать ответы на свои письма и укажет верный заголовок "Reply-to:", но большинство указывает там либо несуществующий адрес, либо адрес невинной жертвы.
Sender: Этот заголовок нетипичен для писем (обычно используется "X-Sender:"), но иногда появляется в копиях Usenet-сообщений. Предполагает идентификацию отправителя, в случае с Usenet-сообщениями является более надежным, чем строчка "From:".
Subject: Полностью свободное поле, заполняемое отправителем, и указывающее, естественно, тему сообщения.
To: Заголовок сообщения "To:" рассматривался выше. Отметим, что поле "To:" не обязано содержать адрес получателя!
X-заголовки - отдельный набор заголовков, начинающихся с заглавной X с последующим дефисом. Существует договоренность, согласно который X-заголовки являются нестандартными и добавляются только для дополнительной информации. Соответственно, любой нестандартный информативный заголовок должен иметь имя, начинающееся на "X-". Эта договоренность, однако, часто нарушается.
X-Confirm-Reading-To: Этот заголовок запрашивает автоматическое подтверждение того, что письмо было получено или прочитано. Предполагается соответствующая реакция почтовой программы, но обычно он игнорируется.
X-Distribution: В ответ на возникшие проблемы со спаммерами, использующими его программы, автор Pegasus Mail добавил этот заголовок. Любое сообщение, посланное с помощью Pegasus и имеющее достаточно большое число получателей, получает заголовок "X-Distribution: bulk". Это позволяет получателям фильтровать такие письма.
X-Errors-To: Как и "Errors-To:", этот заголовок указывает адрес, на который следует отсылать сообщения об ошибках. Он реже соблюдается почтовыми серверами.
X-Mailer: (или "X-mailer:") Свободное поле, в котором почтовая программа, с помощью которой было создано данное сообщение, идентифицирует себя (в рекламных или подобных целях). Поскольку спам часто рассылается специальными почтовыми программами, это поле может служить ориентиром для фильтров.
X-PMFLAGS: Этот заголовок добавляется программой Pegasus Mail. Его семантика неочевидна, но он появляется во всех сообщениях, созданных с помощью этой программы. Сложно сказать, какую информацию, помимо той, что содержится в заголовке "X-Mailer:", он несет пользователю.
X-Priority: Еще одно поле для приоритета сообщения (обычно он отображается при графическом представлении сообщения).
X-Sender: Почтовый аналог Usenet-заголовка "Sender:". Предполагалось, что он будет доставлять более надежную информацию об отправителе, чем поле "From:", однако в действительности его так же легко подделать, и относиться к нему следует соответственно.
X-UIDL: Уникальный идентификатор, используемый в POP-протоколе при получении сообщений с сервера. Обычно он добавляется между почтовым сервером получателя и собственно почтовой программой получателя. Если письмо пришло на почтовый сервер уже с заголовком "X-UIDL:", это скорее всего спам (никакой очевидной выгоды в использовании этого заголовка нет, но по непонятным причинам спаммеры иногда его добавляют).