Протокол SMTP

Протокол SMTP

O В этой главе:

O Основные команды протокола

O Серверы-ретрансляторы

O Непосредственная пересылка

O Автоматизация почтовой рассылки и спам

O Анонимная рассылка писем

Для доставки почты в большинстве случаев используется протокол SMTP (Simple Mail Transfer Protocol).

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

Современные SMTP-сервера используют различные защитные механизмы, препятствующие отправке корреспонденции неизвестными пользователями. Подробно об этом рассказывается в главе «Почтовый сервер изнутри».

В терминологии SMTP-протокола нет таких понятий как «клиент» и «сервер». Вместо этого говорят об отправителе (sender) и получателе (receiver). То, что большинство называют «SMTP-сервером», является одновременно и отправителем, и получателем. Когда клиент устанавливает с ним соединение для передачи письма, сервер выступает в роли получателя, а когда доставляет сообщение абоненту, становится отправителем.

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

Приведенный ниже пример демонстрирует, как посредством протокола SMTP отправить абоненту сообщение. Первым шагом необходимо запустить telnet-клиента и, установив соединение с выбранным SMTP-сервером (например, mail.aport.ru) по двадцать пятому порту, дождаться выдачи приглашения.

Рисунок 009 Подключение к серверу mail.aport.ru

· 220 camel.mail.ru ESMTP Exim 3.02 #107 Sun, 26 Mar 2000 17:36:24 +0400

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

Для передачи корреспонденции одного лишь TCP-соединения не достаточно, и необходимо установить еще одно, так называемое SMTP-соединение. Это достигается возвращением ответного приветствия серверу [193] с указанием имени узла клиента (если у него есть имя) или IP-адреса (если у клиента нет имени).

Далеко не всегда требуется указывать свой точный адрес. Часто достаточно ввести произвольную текстовую строку, например “ABDCEF”

· 220 camel.mail.ru ESMTP Exim 3.02 #107 Sun, 26 Mar 2000 17:36:24 +0400

· HELO ppp-15.krintel.ru

· 250 camel.mail.ru Hello ppp-15.krintel.ru [195.161.41.239]

Ответное приветствие осуществляется командой “HELO [194]”. Сервер, установив SMTP-соединение, возвращает код успешного завершения операции (250) и в большинстве случаев определяет IP-адрес клиента или его доменное имя.

Следующим шагом требуется указать отправителя сообщения. Для этого необходимо воспользоваться командой «MAIL FROM» с указанием собственного почтового адреса при желании заключенного в угловые скобки.

Например:

· 220 camel.mail.ru ESMTP Exim 3.02 #107 Sun, 26 Mar 2000 17:36:24 +0400

· HELO ppp-15.krintel.ru

· 250 camel.mail.ru Hello ppp-15.krintel.ru [195.161.41.239]

· MAIL FROM:«kpnc@aport.ru»

· 250 «kpnc@aport.ru» is syntactically correct

Затем указывается получатель сообщения, передаваемый с помощью команды “RCPT TO”, пример использования которой продемонстрирован ниже:

· 220 camel.mail.ru ESMTP Exim 3.02 #107 Sun, 26 Mar 2000 17:36:24 +0400

· HELO ppp-15.krintel.ru

· 250 camel.mail.ru Hello ppp-15.krintel.ru [195.161.41.239]

· MAIL FROM:«kpnc@aport.ru»

· 250 «kpnc@aport.ru» is syntactically correct

· RCPT TO:«kpnc@aport.ru»

· 250 «kpnc@aport.ru» verified

При возникновении потребности в отправке одного и того же сообщения нескольким респондентам, достаточно вызвать “RCPT TO” еще один (или более) раз (максимальное количество получателей обычно не ограничено). Если кому-то из них сервер не возьмется доставить сообщение, он вернет ошибку, никак, однако не сказывающуюся на остальных получателях.

Команда “DATA”, вызываемая без аргументов, переводит сервер в ожидание получения текста письма.

· DATA

· 354 Enter message, ending with "." on a line by itself

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

Пример использования команды “DATA” приведен ниже:

· 220 camel.mail.ru ESMTP Exim 3.02 #107 Sun, 26 Mar 2000 17:36:24 +0400

· HELO ppp-15.krintel.ru

· 250 camel.mail.ru Hello ppp-15.krintel.ru [195.161.41.239]

· MAIL FROM:«kpnc@aport.ru»

· 250 «kpnc@aport.ru» is syntactically correct

· RCPT TO:«kpnc@aport.ru»

· 250 «kpnc@aport.ru» verified

· Hello, Sailor!

·.

· 250 OK id=12ZDEd-000Eks-00

Команда “QUIT” завершает сеанс и закрывает соединение.

· quit

· 221 camel.mail.ru closing connection

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

· From kpnc@aport.ru Sun Mar 26 17:38:03 2000

· Received: from ppp-15.krintel.ru ([195.161.41.239])

· by camel.mail.ru with smtp (Exim 3.02 #107)

· id 12ZDEd-000Eks-00

· for kpnc@aport.ru; Sun, 26 Mar 2000 17:37:59 +0400

· Message-Id: «E12ZDEd-000Eks-00@camel.mail.ru»

· From: kpnc@aport.ru

· Date: Sun, 26 Mar 2000 17:37:59 +0400

·

· Hello,Sailor!

Ниже будет показано, каким образом злоумышленники находят и используют чужие сервера исходящей почты. Один из способов поиска общедоступных SMTP-серверов заключается в анализе заголовков приходящей корреспонденции. Среди узлов, оставивших свои адреса в поле “Received”, порой встречаются сервера, которые не требуют аутентификации пользователя для отправки писем.

Например, ниже показан заголовок письма, вытащенного автором этой книги из его собственного почтового ящика:

· From irt@chiti.uch.net Wed Mar 22 16:57:03 2000

· Received: from gate.chiti.uch.net ([212.40.40.141])

· by msk2.mail.ru with esmtp (Exim 3.02 #116)

· id 12Xld1-0008jx-00

· for kpnc@aport.ru; Wed, 22 Mar 2000 16:56:59 +0300

· Received: from 13.chiti.uch.net ([192.168.223.13])

· by gate.chiti.uch.net (8.8.8/8.8.8) with SMTP id PAA29678

· for «kpnc@aport.ru»; Wed, 22 Mar 2000 15:51:47 +0200 (EET)

· From: "irt" «irt@chiti.uch.net»

Анализ заголовка позволяет установить, что письмо было отправлено с адреса 13.chiti.uch.net через сервер исходящей почты gate.chiti.uch.net. Если попробовать установить с ним соединение, то результат может выглядеть так:

· 220 gate.chiti.uch.net ESMTP Sendmail 8.8.8/8.8.8; Sun, 26 Mar 2000 16:21:53 +0300 (EEST)

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

· 220 gate.chiti.uch.net ESMTP Sendmail 8.8.8/8.8.8; Sun, 26 Mar 2000 16:21:53 +0300 (EEST)

· HELO kpnc.krintel.ru

· 250 gate.chiti.uch.net Hello kpnc.krintel.ru [195.161.41.239], pleased to meet you

· MAIL FROM:«kpnc@id.ru»

· 250 «kpnc@id.ru»… Sender ok

· RCPT TO:«kpnc@aport.ru»

· 250 «kpnc@aport.ru»… Recipient ok

Код успешного завершения операции (250) и срока «Recipient ok» свидетельствуют о том, что сервер согласился на пересылку. Остается ввести текст послания и можно отправлять письмо. Спустя какое-то время (обычно не превышающее одной минуты) сообщение должно прийти по назначению. А его заголовок может выглядеть, например, так:

· From kpnc@id.ru Sun Mar 26 17:28:33 2000

· Received: from gate.chiti.uch.net ([212.40.40.141])

· by camel.mail.ru with esmtp (Exim 3.02 #107)

· id 12ZD5a-000Dhm-00

· for kpnc@aport.ru; Sun, 26 Mar 2000 17:28:30 +0400

· Received: from kpnc.krintel.ru (kpnc.krintel.ru [195.161.41.239])

· by gate.chiti.uch.net (8.8.8/8.8.8) with SMTP id QAA02468

· for «kpnc@aport.ru»; Sun, 26 Mar 2000 16:22:44 +0300 (EEST)

· (envelope-from kpnc@id.ru)

· Date: Sun, 26 Mar 2000 16:22:44 +0300 (EEST)

· From: kpnc@id.ru

· Message-Id: «200003261322.QAA02468@gate.chiti.uch.net»

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

Один из анонимных серверов расположен (точнее, был когда-то расположен на момент написания этой главы) по адресу dore.on.ru. Однако его использование посторонними лицами запрещено, что и демонстрирует следующий эксперимент:

· 220 WITHELD FTGate server ready -Fox Mulder

· HELO kpnc.krintel.ru

· 250 Ready

· MAIL FROM:«konc@aport.ru»

· 250 «konc@aport.ru» Sender Ok

· RCPT TO:«kpnc@aport.ru»

· 550 Relaying denied for «kpnc@aport.ru»

Сервер, действительно, не делает никаких видимых попыток определить адрес клиента, но в то же время пересылать его корреспонденцию за пределы сервера наотрез отказывается. Причем достоверно известно, что владельцы этого сервера используют его для рассылки сообщений по нелокальным адресам. Отсюда вытекает существование механизма, позволяющего отличить «своих» от «чужих». Права «чужих» ограничиваются доставкой писем по локальным адресам, а «своим» разрешается отправлять сообщения и за пределы сервера. Ввиду отсутствия в протоколе SMTP средств аутентификации пользователей, отличить одних от других помогает IP адрес клиента. Локальные пользователи, находящиеся в одной подсети с сервером, считаются «своими», и наоборот [195].

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

Клиент дважды указывает свой адрес: приветствуя сервер, командой “HELO” он сообщает свой домен, а в поле “MAIL FROM” приводит собственный обратный адрес. Некоторые сервера проверяют одно из этих значений, а некоторые оба одновременно.

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

· 220 WITHELD FTGate server ready -Fox Mulder

· HELO dore.on.ru

· 250 Ready

· MAIL FROM:«fox@dore.on.ru»

· 250 «fox@dore.on.ru» Sender Ok

· RCPT TO:«kpnc@aport.ru»

· 250 Recipient Ok

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

Для массовой рассылки лучшего способа и придумать невозможно, но вот для обычной переписки такая методика не подходит. Ведь ответ на письмо возвратится по адресу fox@dore.on.ru! Этого можно избежать, если добавить в заголовок поле “Reply-To”, содержащее истинный адрес отправителя (тот, который он захотел оставить сам). Это может выглядеть, например, таким образом:

· 220 WITHELD FTGate server ready -Fox Mulder

· HELO dore.on.ru

· 250 Ready

· MAIL FROM:«fox@dore.on.ru»

· 250 «fox@dore.on.ru» Sender Ok

· RCPT TO:«kpnc@id.ru»

· 250 Recipient Ok

· data

· 354 Start mail input; end with «CRLF».«CRLF»

· Subject:TEST

· Reply-To:«kpnc@hotmail.com»

·

· Hello!

·.

· 250 Ok Message queued

· quit

· 221 dore.on.ru Service closing transmission channel

Заголовок такого письма должен выглядеть приблизительно так:

· Received: from relay1.aha.ru ([195.2.83.105] verified)

· by aha.ru (CommuniGate Pro SMTP 3.1b2)

· with ESMTP id 3882573 for kpnc@id.ru; Mon, 05 Jul 1999 20:01:40 +0400

· Received: from warlock.miem.edu.ru (miem-as.ins.ru [195.19.18.226])

· by relay1.aha.ru (8.9.3/8.9.3/aha-r/0.04B) with ESMTP id UAA07173

· for «kpnc@id.ru»; Mon, 5 Jul 1999 20:01:40 +0400 (MSD)

· Received: from dore.miem.edu.ru (rtuis.miem.edu.ru [194.226.32.50])

· by warlock.miem.edu.ru (8.9.3/8.9.3) with ESMTP id UAA00637

· for «kpnc@id.ru»; Mon, 5 Jul 1999 20:00:42 +0400 (MSD)

· Received: from fox by dore.on.ru (FTGate 2, 1, 2, 1);

· Mon, 05 Jul 99 20:02:30 +0400

· Message-ID: «000301bec6ff$c87f5220$16fe7dc1@fox»

· From: «fox@dore.on.ru»

· To: «KPNC@id.ru»

· Subject: TEST

· Reply-To:«kpnc@HotMail.com»

· Date: Mon, 5 Jul 1999 20:02:29 +0400

·

· Hello!

При попытке ответить отправителю, почтовый клиент получателя извлечет содержимое поля “Reply-To” и отправит письмо по указанному в нем адресу. Именно этим и пользуются спамеры для достижения полной анонимности с одной стороны, и возможности получения ответов от заинтересованных лиц - с другой.

Если внимательно посмотреть на заголовок письма, в нем можно обнаружить несколько строк “Received”. Их оставили транзитные сервера, иначе называемые Релеями (от английского relay).

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

Например, чтобы отправить письмо для kpnc@computerra.ru с помощью “OutLock Express” придется зайти в «Учетные записи» (меню «Сервис»), выбрать «Свойства» и перейти к закладке «Серверы», задав для исходящей почты сервер «computerra.ru».

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

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

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

Но протокол SMTP позволяет отправителю самостоятельно задавать маршрут пересылки сообщения Параметр команды “RCPT TO” может содержать не только адрес получателя, но и путь ретрансляции!

Формат его следующий:

· RCPT TO:«@s1,@s2,@s3,@sn:name@host»

где s1,s2,s3,sn - имена (или IP адреса) промежуточных хвостов, а name@host почтовый ящик получателя. В первую очередь сообщение передается узлу s1 - самому левому серверу в цепочке. Он модифицирует параметр команды RCPT TO, «выкусывая» из нее имя своего узла:

· RCPT TO:«@s2,@s3,@sn:name@host»

Затем, извлекается адрес следующего получателя - s2. Если сервер s1 не берется за доставку корреспонденции серверу s2, письмо возвращается назад отправителю с сообщением об ошибке. В противном случае процесс повторяется до тех пор, пока сообщение не окажется в почтовом ящике получателя.

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

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

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

Узнать какие именно команды поддерживаются конкретным SMTP сервером можно с помощью «HELP», а подробнее о назначении каждой из них “HELP command”.

Для получения детальной информации о командах протокола SMTP можно обратиться к RFC-788, RFC-821, RFC-822, RFC-1341, RFC-1342, RFC-1426, RFC-1521, RFC-1806, RFC-1830, RFC-2045, RFC-2046, RFC-2047, RFC-2048, RFC-2049, RFC-2076.