SMTP

30.300203 (0.2996) vangogh.3874 > 140.252.13.33.25: S 2358367745:2358367745(0) ...

40.300620 (0.0004) 140.252.13.33.25 > vangogh.3874: R 0:0(0) ack 2358367746 win 0

Рисунок 28.5 Попытки установить контакт с неработающим SMTP сервером.

В строке 1 vangogh отправляет SYN на порт 25 на первый IP адрес хоста sun: 140.252.1.29. В

строке 2 мы видим отказ. SMTP клиент на vangogh пробует следующий IP адрес sun: 140.252.13.33 (строка 3), что также вызывает возврат RST (строка 4).

SMTP клиент не старается изменить свое поведение в результате ошибки, полученной на

активное открытие, которое он осуществлял в строке 1, именно поэтому он старается обратиться к другому IP адресу в строке 2. Если ошибка была подобна "хост недоступен" (host unreachable) для первой попытки, возможно, что вторая попытка сработает.

Если причина, по которой активное открытие SMTP клиента не сработало, заключается в том, что хост выключен, мы увидим, что клиент будет повторно выдавать SYN на IP адрес 140.252.1.29 в течение 75 секунд (примерно так же, как на рисунке 18.6), затем отправит еще три SYN на IP адрес 140.252.13.33 в течение других 75 секунд. После 150 секунд клиент

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

Команды VRFY и EXPN

Команда VRFY проверяет, в порядке ли адрес получателя, не посылая при этом реальной

почты. EXPN предназначена для расширения почтового псевдонима до почтового адреса. Большинство SMTP реализаций (такие как Sendmail) воспринимают эти команды абсолютно одинаково, однако мы уже отмечали, что более новые версии Sendmail проводят различие между ними.

В качестве простого теста мы можем подсоединиться к более новой версии Sendmail и посмотреть эти различия. (Мы удалили вывод клиента Telnet.)

sun % telnet vangogh.cs.berkeley.edu 25

220-vangogh.CS.Berkeley.EDU Sendmail 8.1C/6.32 ready at Tue, 3 Aug 1993 14:59:12 -0700 220 ESMTP spoken here

helo bsdi.tuc.noao.edu

250 vangogh.CS.Berkeley.EDU Hello sun.tuc.noao.edu [140.252.1.29], pleased to meet you

vrfy nosuchname

550 nosuchname... User unknown

vrfy rstevens

250 Richard Stevens <rstevens@vangogh.CS.Berkeley.EDU>

expn rstevens

250 Richard Stevens <rstevens@noao.edu>

Во-первых, обратите внимание на то, что мы специально напечатали неверное имя хоста для

команды HELO: bsdi вместо sun. Большинство SMTP серверов берут IP адрес клиента и осуществляют запрос указателя DNS (глава 14, раздел "Запросы указателя"), после чего сравнивают имена хостов. Это позволяет серверу зарегистрировать соединение клиента,

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

"почему бы вам не позвонить самому себе...". В этом примере мы видели, что сервер просто напечатал реальное имя домена из запроса указателя вместе с IP адресом.

Затем мы вводим команду VRFY для несуществующего имени, на что сервер отвечает

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

и печатает адрес перенаправления.

На многих хостах команды VRFY и EXPN отключены, может быть с точки зрения секретности и иногда из-за того, что администраторы считают, что в этом находится какая-то дырка в секретности. Например, мы можем попробовать воспользоваться этими командами на SMTP сервере Белого Дома (США):

sun % telnet whitehouse.gov 25

220 whitehouse.gov SMTP/smap Ready.

helo sun.tuc.noao.edu

250 (sun.tuc.noao.edu) pleased to meet you.

vrfy clinton

500 Command unrecognized

expn clinton

500 Command unrecognized

Будущее SMTP

В настоящее время почта Internet заметно меняется. Вспомните, что почта Internet состоит из трех частей: конверт, заголовки и тело сообщения. Появляются новые SMTP команды, которые изменяют конверт, в заголовках могут быть использованы не-ASCII символы, а к

телу добавляются структуры (MIME). В этом разделе мы по порядку рассмотрим расширение каждой из трех частей.

Изменения в конверте: расширенное SMTP

RFC 1425 [Klensin et al. 1993a] определяет основные расширения для SMTP. В результате

получилось то, что называется расширенным SMTP (ESMTP - extended SMTP). Как и другие

новые характеристики (уже описанные в тексте), эти изменения добавляются таким образом, что новые версии совместимы со старыми.

Клиент, которому необходимо использовать новые характеристики, открывает сессию с сервером с использованием команды EHLO вместо команды HELO. Совместимый сервер отвечает откликом с кодом 250. Этот отклик обычно содержит несколько строк, причем

каждая строка содержит ключевое слово и дополнительный аргумент. Ключевые слова указывают на расширения SMTP, поддерживаемые сервером. (В случае многострочного

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

Ниже показаны начальные стадии соединений с четырьмя SMTP серверами, три из которых

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

sun % telnet vangogh.cs.berkeley.edu 25

220-vangogh.CS.Berkeley.EDU Sendmail 8.1C/6.32 ready at Mon, 2 Aug 1993 15:47:48 -0700 220 ESMTP spoken here

ehlo sun.tuc.noao.edu

250-vangogh.CS.Berkeley.EDU Hello sun.tuc.noao.edu [140.252.1.29], pleased to meet you 250-EXPN

250-SIZE

250 HELP

Этот сервер выдает многострочный отклик 220 в виде приветственного сообщения. Расширенные команды, приведенные в отклике 250, на команду EHLO это EXPN, SIZE и HELP. Первая и последняя из исходной спецификации RFC 821, однако они являются дополнительными командами (необязательными). Сервера ESMTP помимо дополнительных команд из RFC 821 поддерживают также и более новые команды.

Ключевое слово SIZE означает, что сервер поддерживает то, что описано в RFC

1427 [Klensin, Freed, and Moore 1993]. Подобное расширение позволяет клиенту указывать

размер сообщения в байтах в командной строке MAIL FROM. Это позволяет серверу

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

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

sun % telnet ymir.claremont.edu 25

220 ymir.claremont.edu -- Server SMTP (PMDF V4.2-13 #4220)

ehlo sun.tuc.noao.edu

250-ymir.claremont.edu

250-8BITMIME

250-EXPN

250-HELP

Изменения в заголовках: использование не-ASCII символов

RFC 1522 [Moore 1993] указывает способы передачи не-ASCII символов в заголовках

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

Поле заголовка может содержать закодированные слова. При этом формат следующий:

=? charset ? encoding ? encoded text ?=

charset это спецификация набора символов. Приемлемые значения это две строки us-ascii и iso-8859-X, где X это одна цифра, как, например, iso-8859-1.

encoding это один символ, который указывает метод кодирования. Поддерживаются два значения.

1.Q означает quoted-printable и предназначен для латинского набора символов. Большинство символов передаются как NVT ASCII (старший бит установлен в 0,

естественно). Любой отправляемый символ, у которого восьмой бит не равен 0,

посылается как три символа: первый символ =, после чего следуют две шестнадцатиричные цифры. Например, символ й (бинарное 8-битное значение которого равно 0xe9) передается как три символа =E9. Пробелы всегда отправляются либо как подчеркивание, либо как три символа =20. Такое кодирование используется

для текста, который в основном состоит из ASCII с небольшим количеством

специальных символов.

2.B означает кодирование по основанию 64. Три последовательных байта текста (24

бита) кодируются как четыре 6-битных значения. Для того, чтобы представить каждое

из возможных 6-битных значений, используется, 64 символа NVT ASCII, как показано на рисунке 28.6.

Рисунок 28.6 Кодирование 6-битных значений (кодирование на основе 64).

Когда количество символов, которые необходимо кодировать, не кратно трем, в качестве

символов заполнения используются знаки равно.

Следующий пример этих двух типов кодирования взят из RFC 1522:

From: =?US-ASCII?Q?Keith_Moore?= <moore@cs.utk.edu>

To: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= <keld@dkuug.dk> CC: =?ISO-8859-1?Q?Andr=E9_?= Pirard <PIRARD@vm1.ulg.ac.be> Subject: =?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?=

=?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg==?=

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

From: Keith Moore <moore@cs.utk.edu>

To: Keld Jorn Simonsen <keld@dkuug.dk>

CC: Andre Pirard <PIRARD@vm1.ulg.ac.be>

Subject: If you can read this you understand the example.

Для того чтобы посмотреть, как работает кодирование на основе 64, посмотрите на первые 4 закодированных символа в строке темы: SWYg. Напишем 6-битные значения для этих 4

символов в соответствии с рисунком 28.6 (S=0x12, W=0x16, Y=0x18 и g=0x20) в двоичном виде:

010010 010110 011000 100000

Затем перегруппируем эти 24 бита в три 8-битных байта:

которые в виде ASCII представляют собой I, f и пробел.

Изменения в теле сообщения: Многофункциональные расширения почты Internet

(MIME - Multipurpose Internet Mail Extensions)

Мы говорили, что RFC 822 описывает тело сообщения как строки NVT ASCII текста, без структуры. RFC 1521 [Borenstein and Freed 1993] определяет расширения, которые позволяют вводить структуру в тело сообщения. Это называется многофункциональным расширением почты Internet (MIME - Multipurpose Internet Mail Extensions).

MIME не требует тех расширений, что мы описали ранее в этом разделе (расширенный SMTP или не-ASCII заголовки). MIME просто добавляет некоторые новые заголовки (в соответствии

с RFC 822), которые сообщают получателю о структуре тела сообщения. Тело сообщения

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

вполне уместны при использовании вместе с MIME - команда SIZE расширенного SMTP, так

как MIME сообщения могут быть довольно большими, и не-ASCII заголовки, эти расширения не требуются для MIME. Все что требуется для обмена MIME сообщениями с другой

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

MIME определяет пять новых полей заголовков:

Mime-Version:

Content-Type:

Content-Transfer-Encoding:

Content-ID:

Content-Description:

В качестве примера, приведены две строки заголовка, которые могут присутствовать в почтовом сообщении Internet:

Mime-Version: 1.0

Content-Type: TEXT/PLAIN; charset=US-ASCII

Текущая версия MIME - 1.0, в которой сообщения выглядят как простой ASCII текст, что является форматом по умолчанию для почты Internet. Слово PLAIN определяет подтип типа содержимого (TEXT), а строка charset=US-ASCII это параметр.

Text это всего лишь один из семи определенных в MIME типов содержимого. На рисунке 28.7 приводится краткое описание 16 различных типов содержимого и подтипов, определенных в RFC 1521. Для конкретных типов содержимого и подтипов может быть определено большое

количество параметров.

Тип содержимого и кодирование при передаче, применяемое к телу сообщения, независимы друг от друга. Здесь указаны поле заголовка Content-Type (тип содержимого) и поле заголовка Content-Transfer-Encoding (кодирование содержимого при передаче). В RFC 1521

определено пять различных форматов кодирования.

1.7bit, что является NVT ASCII, по умолчанию.

2.quoted-printable, как мы видели в примере, приведенном ранее, используется с неASCII заголовками. Подобный тип кодирования применим, только когда небольшое

количество символов имеет установленный восьмой бит.

3.base64, показан на рисунке 28.6.

4.8bit содержит строки символов, некоторые из которых не-ASCII и имеют установленный

восьмой бит.

5.binary кодирование, используется в случае 8-битных данных, которые не содержат строк.

Рисунок 28.7 Типы и подтипы содержимого MIME.

Только первые три из приведенных приемлимы для MTA работающих по правилам RFC 821, так как в этих трех случаях генерируется содержимое тела сообщения в виде только

NVT ASCII символов. При использовании расширенного SMTP с 8BITMIME, поддерживается

8bit кодирование.

Так как тип содержимого и кодирование независимы, RFC 1521 рекомендует quoted-printable

для text с не-ASCII данными, и base64 для данных типа image, audio, video и octet-stream

приложений. При этом гарантируется максимальная совместимость с MTA, работающими по правилам RFC 821. Типы содержимого multipart и message должны быть кодированы как 7bit.

На рисунке 28.8 показано почтовое сообщение, содержащее список распространяемых RFC, тип содержимого - multipart. Подтип - mixed, это означает, что каждая часть должна быть обработана последовательно, разделители между частями выглядят как строка NextPart, перед которой стоят два дефиса в начала строки.

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

Так как за первым разделителем следуют пустые строки и не указаны поля заголовка, между

первым и вторым разделителями подразумевается тип содержимого данных text/plain с набором символов us-ascii. Это текстовое описание нового RFC.

За вторым разделителем, однако, следуют поля заголовков. Они определяют следующее сообщение как multipart, с разделителем OtherAccess. Подтип - alternative, причем

присутствует два альтернативных варианта. Первый OtherAccess предназначен для получения RFC с использованием электронной почты, а второй для получения с