ANTISPAM.RU |
О спаме
Пользователям
Специалистам
Статьи
Программы Ссылки Поиск на сервере О проекте |
Чтение заголовков электронных писем (перевод)
Все о заголовках электронных писем
ВведениеЭтот документ дает всестороннее представление о том, какие бывают заголовки электронных писем. В первую очередь он предназначен для тех, кто пытается определить истинный источник незванных и раздражающих электронных посланий ("спама"), которые обычно подделываются; но он может помочь и жертвам любых других поддельных писем. Этот документ может может также оказаться полезным для читателей, интересующихся общей информацией об электронной почте и ее передаче в сети Интернет. Несмотря на то, что в документе намеренно избегается тема "как подделывать письма", кое-какая информация, содержащаяся в нем, все же может быть использована в этих целях. Автор не одобряет фальсификаций электронной почты, и любое использование информации из данного документа в этих целях противоречит предназначению документа. Данный документ содержит некоторое количество фиктивных доменных имен и ассоциированных с ними 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)
В момент передачи сообщения узлом 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)
В момент, когда 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 Этот последний набор заголовков и видит 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.
Subject: Lunch today?Говорит само за себя.
Почтовые протоколыЭтот раздел содержит несколько большее количество технической информации, чем остальные, и фокусируется на детальном рассмотрении того, как письмо переходит из одной точки в другую. Вам не обязательно понимать каждое слово, но общее знакомство с предметом поможет вам прояснить некоторые непонятные ситуации. Поскольку спаммеры часто намеренно создают запутанные заголовки (частично с целью сбить с толку своих жертв), способность разобрать такие заголовки может оказаться полезной. Для связи по сети компьютеры часто используют "точки входа", называемые портами; порт представляет собой канал, через который компьютер может соединяться с сетью. Для того, чтобы установить несколько одновременных соединений, компьютеру потребуется несколько портов; чтобы их различать, их обычно нумеруют. В системах, работающих в сети Интернет (или в любых других системах, использующих для электронной почты тот же самый протокол) порт 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) Весь сеанс связи прошел с использованием пяти команд, составляющих основу 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, считается частью сообщения. Никаких ограничений на вводимые данные нет. Начальные несколько строк (перед первой пустой строкой), начинающиеся словом с двоеточием, большинством почтовых программ расценивается как заголовки. Строка, состоящая из одной точки, завершает сообщение. QUIT завершает соединение. 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) Аналогично, если вся исходящая почта от 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:" снизу вверх. Письмо ушло от 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:". Это письмо пришло с узла 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А вот получившийся в результате заголовок письма (приведен не полностью для простоты): >From forged-address@galangal.orgОтметим, что содержимое заголовка конверта From, а также заголовков сообщения "From:" и "To:" продиктовано отправителем, и не имеет ничего общего с действительностью! Этот пример иллюстрирует тот факт, что никогда нельзя доверять заголовкам "From", "From:" и "To:" в письмах, которые могут оказаться фальшивыми, так как эти заголовки очень легко подделать.
Важность заголовков "Received:"Мы уже видели на рассмотренных раньше примерах, что заголовоки "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)...Очевидно, две последние строки являются ложью, написанной отправителем и добавленной к сообщению перед отправкой. Поскольку отправитель не имеет контроля над письмом с момента его отправки с turmeric.com, а заголовки "Received:" всегда добавляются сверху, то поддельные строки обязательно окажутся внизу списка. Это означает, что, читая строки сверху вниз, отслеживая историю сообщения, можно спокойно отбросить все, что находится ниже первой поддельной строки. Даже если все последующие строчки "Received:" выглядят правдоподобно, они, несомненно, являются подделкой. Разумеется, отправитель не будет писать откровенный мусор. Настоящий спаммер создаст правдоподобный список строк "Received:" вроде следующего: Received: from galangal.org ([104.128.23.115]) by mail.bieberdorf.edu (8.8.5)...В этом примере единственной точкой опоры является неверный IP-адрес узла galangal.org в первой строчке "Received:". Подделку было бы еще труднее выловить, если бы спаммер вписал верные IP-адреса узлов lemongrass.org и graprao.com, но все равно несоответствие IP-адреса в первой строчке неопровержимо указывало бы на то, что все оставшиеся строки ложные, и письмо было отправлено с узла с IP-адресом 104.128.23.115 (т.е., turmeric.com). Однако, большинство подделок не столь качественны, и чаще всего ложные строчки "Received:" содержат очевидный мусор.
Список стандартных заголовков
© 1997 Ken Lucke - all rights reserved
|
||
![]() © 1999-2005 Хостинг сайта - "Зенон Н.С.П." :: Администрация |