Home

Page 128
Page 128
background image

серверу   БУДЕТ   использовать   данную   технологию.   Данное     расширение  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, а затем клиент может передавать то сообщение, которое 


Copyright © 2022 Файлообменник files.d-lan.dp.ua

Использование любых материалов сайта возможно только с разрешения автора.