Возможно, самым важным документом, посвященным расширениям SMTP, является RFC 1425, «Расширения службы SMTP» (SMTP Service Extensions, Klensin et al, 1993). Вдобавок к расширениям SMTP, в RFC 1425 описываются способы проектирования новых расширений, так сказать, на будущее. Реализация SMTP, работающая в соответствии с расширениями RFC 1425, называется «расширенный SMTP» или просто ESMTP (Extended SMTP). Расширенный SMTP работает почти так же, как и обычный SMTP, однако команда-приветствие у него другая: EHLO (Extended hello) вместо уже знакомого HELO. Чтобы выяснить, поддерживает ли МТА-сервер спецификацию ESMTP, МТА-клиент посылает команду EHLO. Если сервер поддерживает ESMTP, он отвечает кодом 250. Если нет, следует сообщение о синтаксической ошибке. В ответ на сообщение об ошибке, клиент может выдать обычную команду HELO и далее выполнять стандартные операции SMTP. Если сервер умеет обслуживать ESMTP, в ответ на приветствие, как правило, он выдает многострочный ответ (в известном вам формате). Каждая строка ответа содержит дополнительную команду ESMTP, с которой сервер знает, как работать. Вот пример реакции ESMTP-сервера в ответ на команду EHLO:

250-mail.server.com

250-EXPN

250-HELP

250 TURN

Вторая, третья и четвертая строки ответа содержат названия дополнительных команд сервера. Как видим, этот сервер обеспечивает обработку перечисленных в табл. 3.10 дополнительных команд. На самом деле в качестве расширений RFC 1425 перечислены только дополнительные SMTP-команды. Другими словами, первыми шестью расширениями SMTP в RFC 1425 являются команды: EXPN, HELP, TURN, SEND, SGML и SAML. Существует также расширение SIZE, описанное в RFC 1427, «Расширения службы SMTP, касающиеся размеров сообщений» (SMTP Service Extension for Message Size Declaration, Klensin et al, 1993), позволяющее SMTP-клиенту и серверу сообщать друг другу размеры передаваемого сообщения. Если в ответе на команду EHLO присутствует ключевое слово SIZE, значит, данное расширение обрабатывается. Как известно, существует предел размеров передаваемого сообщения для сервера. Если клиент МТА попытается передать сообщение, превышающее этот предел, почтовая транзакция не состоится (закончится с ошибкой). Максимальная длина сообщения ограничивается по нескольким причинам.

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

К сожалению, обыкновенный МТА-клиент не имеет возможности знать заранее, хватит ли места на сервере, чтобы положить туда все сообщение. Предположим, что вы разрабатываете почтовое приложение для пересылки больших мультимедиа-файлов. Если МТА-клиент этой системы не умеет работать с ESMTP, а значит, не знает команды SIZE, вы постоянно будете сталкиваться с такой ситуацией: клиент передает несколько мегабайт информации и только потом узнает, что на диске сервера не хватило 100 килобайт места для хранения файла. Если вы планируете пересылать большие документы (графику, звук или видео), вам настоятельно рекомендуется команда SIZE (ее полное название: Message Size Declaration service extension). Ее задача — выдать клиенту максимальный размер сообщения, который сервер в состоянии принять от клиента. Максимальный размер сообщения следует сразу за кодом ответа 250.

 Вот пример ответа SIZE для размера в 100 мегабайт (Мб):

250   SIZE  100000000

Клиент МТА анализирует ответ SIZE и в случае необходимости предпринимает соответствующие действия. Дополнительно клиент может указывать длину сообщения в команде MAIL. В следующей ESMTP-команде клиент объявляет, что длина сообщения равна 500 килобайтам (Кб):

MAIL FROM:<happy@jamsa.com> SIZE=500000

МТА-сервер ESMTP анализирует аргумент SIZE и решает, принимать ему сообщение такой длины или сообщить об ошибке. Все это происходит еще до начала передачи (однако в RFC 1427 описано несколько случаев, когда ошибка происходит уже во время передачи). Остальные несколько расширений SMTP, в общем, подчиняются тем же правилам, что и рассмотренная только что команда SIZE. To есть команда-расширение выдается в ответе сервера по запросу клиента EHLO. Расширения можно использовать в ваших программах в соответствии со спецификацией. В некоторых случаях расширение является просто дополнительной возможностью. В других случаях расширение — дополнительный аргумент к существующей команде (как в случае только что рассмотренной команды SIZE).

Местные расширения

По определению местным расширением является любое поле, команда или название опции, начинающееся с буквы X. Например, в почтовом сообщении из предыдущего раздела имеется поле заголовка под названием «X-Special-action»:

X-Special-action: This  is a sample of user-defined field-names. There could also be a field-name  "Special-action", but its name might  later be preempted

Имя этого поля начинается с X, поэтому оно местное, то есть задано пользователем. Разумеется, пользователь может придумать любое название поля, какое ему нравится. Однако при этом существует риск, что в дальнейших стандартах Интернет будет определено то же самое имя, но с другим значением. При этом пользовательское и стандартное приложения вступят в конфликт. Поэтому при разработке собственных расширений почтовой системы необходимо, чтобы имена всех новых объектов начинались с буквы X. Например, пользовательский вариант декодирования тела сообщения должен называться не DECODE, как можно было бы предположить, a XDECODE. SMTP-сервер организации при этом должен включить местное расширение XDECODE в список, выдаваемый по команде EHLO (с кодом ответа 250):

250   XDECODE