серверу БУДЕТ использовать данную технологию. Данное расширение SMTP
крайне полезно, так позволяет серверам экономить пропускную способность
линий связи при передаче длинных сообщений электронной почты. Данное
расширение сегодня имеет статус стандарта.
Рассмотрим еще одно расширение SMTP, направленное на решение
проблемы, связанной с плохой пригодностью протокола SMTP для передачи
больших писем. Известно, что протокол SMTP НЕ предполагает возможности, в
случае обрыва TCP сеанса, докачать письмо на SMTP сервер с некоторого места,
установив новое TCP соединение. Причины того, что данная возможность не
была изначально реализована в протоколе, вполне ясны – SMTP предназначался
для передачи по сети небольших текстовых сообщений и потребности в
докачивании сообщений просто не было. Однако с появлением стандарта MIME,
когда в сообщении стало возможным передавать не только текст, но и
произвольные данные, невозможность произвести докачивание сообщения в
случае разрыва соединения стала актуальной. Действительно, предоставим
себе, что клиент подключается к серверу по медленной и не надежной
коммутируемой телефонной линии, организованной на базе аналоговой АТС.
Вполне возможна ситуация, когда скорость передачи данных поверх такого
канального уровня не превысит 3 Кбайт/сек, при этом в среднем каждый 30
минут связь обрывается (конечно, такая ситуация сегодня встречается все реже
и реже, но тем не менее встречается). Ограничение по скорости обмена данными
и по «времени жизни» канала связи накладывают ограничения на размер
письма, которое можно передать за время работы линии связи до обрыва (около
5 Мбайт), что делать пользователю, если ему нужно передать письмо большего
размера? Если пользователь подключился к своему почтовому серверу и
передал не все письмо, а только первые 2 Мбайта, то после разрыва TCP
соединения пользовательскому клиенту ничего другого не остается, как снова
передавать письмо сначала, и так может продолжаться долго!
Экспериментальное расширение, помогающее решить данную проблему мы
сейчас кратко рассмотрим. Данное расширение описано в RFC1845 и называется
Checkpoint/Restart. Сервер сообщает клиенту, что поддерживает данную
технологию, включая в положительный отклик на команду EHLO ключевое слово
CHECKPOINT, используемое без параметров. Если сервер поддерживает данную
технологию, клиент, в случае, если рассчитываем впоследствии докачивать
отправляемое письмо, включает в команду MAIL дополнительный параметр
TRANSID, аргументом которого должен является некоторый уникальный
идентификатор, сгенерированный клиентом, аналогичный Message-ID. После
подачи команды MAIL с новым параметром, клиент продолжает обычную
почтовую транзакцию, т.е. передает команды RCPT, DATA и т.д. В том случае,
если сеанс связи клиента и сервера будет разорван, а письмо не будет передано
полностью, клиент может снова установить соединение с сервером и снова
попытаться передать серверу то же письмо. Для того чтобы это было возможно,
сервер сохраняет все не до конца переданные ему сообщения, и
идентифицирует их с помощью значения параметра TRANSID, переданного
клиентом. Для того чтобы докачать ранее не полностью переданное сообщение
на сервер, клиент снова передаст серверу команду MAIL с тем же самым
значением параметра TRANSID, на что сервер может ответить откликом 355
(единственным откликом вида 3yz до сих пор был отклик 354, подаваемый в
ответ на команду DATA), при этом текстовый комментарий данного отклика
начинается с числа, которое клиент должен интерпретировать как количество
байт письма, которые уже сохранены на сервере. После этого клиент может
непосредственно передавать команду DATA, на которую сервер отвечает
обычным откликом 354, а затем клиент может передавать то сообщение, которое