Home

Page 122
Page 122
background image

Подключение к узлу утеряно.

При   передаче   в   систему   транспорта   почты   писем   с   использование 

механизма   кодирования  binary  использование   команды  BDAT  вместо   команды 
DATA  является   обязательным,   при   этом   никто   не   воспрещает   использование 
данной   команды   для   передачи   произвольных   почтовых   сообщений,   с   любым 
Content-Transfer-Encoding.   Почтовому   серверу   необходимо   реализовывать 
расширение  BINARYMIME  только  совместно  с расширением  CHUNKING,  однако 
расширение CHUNKING может использоваться и само по себе.

Рассмотрим   следующее   расширение.   Известно,   что   использование  MIME 

позволяет   передавать   в   электронном   письме   различные   данные,   а   не   только 
текстовые сообщения, что может приводить к тому, что клиенты будут создавать 
сообщения   электронной   почты   большой   длины.   С   другой   стороны   обработка 
сервером очень длинных сообщений не желательна по ряду причин. Во-первых, 
протокол  SMTP  не   предполагает   докачивания   сообщения   между   клиентом   и 
сервером в том случае, если сеанс связи  SMTP  разорван. Во-вторых, передача 
слишком больших сообщений предъявляет серьезные требования к пропускной 
способности   линий   связи,   тем   более,   что   сообщения   передаются   методом 
коммутации   сообщений   между   промежуточными   почтовыми   серверами,   а   не 
передаются от отправителя непосредственно к получателю (это приводит к тому, 
что передача письма объема N байт на самом деле означает передачу по сети во 
столько   раз   большего   количества   данных,   сколько   промежуточных   сервером 
используется при маршрутизации письма). В-третьих, необходимо понимать, что 
дисковые   ресурсы,   как   релейных   почтовых   серверов,   так   и   серверов, 
выполняющих функции  MX доменов также ограничены. В результате возникает 
необходимость   ограничивать   размер   электронных   писем,   передаваемых 
почтовыми   серверами.   Когда   почтовый   сервер   получает   от   клиента   письмо, 
превышающее   размер,   который   сервер,   в   соответствии   с   настройками 
администратора, может обработать, он может возвращать клиенту в ответ на это 
письмо   не   отклик   250,   а   отклик   452   (операция   временно   не   может   быть 
выполнена по причина нехватки дискового пространства) или 552   (операция 
принципиально   не   может   быть   выполнена   по   причина   нехватки   дискового 
пространства).   Чего   не   хватает   в   таком,   казалось   бы,   работающем   решении? 
Сервер   не   принимает   того   письма,   которое   превышает   разрешенный   объем, 
клиент получает уведомление о том, что произошло – чего не хватает? Проблема 
в   том,   что   клиент   УЖЕ   передал   серверу   неподходящее   письмо.   Это   заняло 
пропускную   способность   линий   связи, вычислительные   ресурсы   сервера, 
наконец время пользователя, которые дождавшись передачи письма на сервер, 
получает   информацию   о   том,   что   его   письмо   слишком   велико,   помимо   этого, 
пользователь,   пославший   письмо   НЕ   получает   информации,   КАКОГО   размера 
письмо он МОЖЕТ передать – только сведения о том, что ТАКОЕ письмо передать 
нельзя. Очевидно, для преодоления описанных недостатков необходимо, чтобы 
сервер УВЕДОМЛЯЛ отправителя о том, какого максимального размера письмо он 
имеет право отправить, желательно, ДО передачи самого письма. Кроме того, 
было   бы   полезно,   если   бы   клиент   ПЕРЕД   отправкой   письма   информировал 
сервер   о   том,   какого   размера   письмо   клиент   собирается   передать,   для   того, 
чтобы сервер отказался принимать письмо недопустимого размера ДО того, как 
оно   будет   передано.   Для   решения   описанных   задач   было   разработано 
расширение протокола SMTP, называемое Message Size Declaration. Когда клиент 
приветствует

сервер

командой

EHLO,

сервер,

поддерживающий

данное

расширение   должен   включить   в   ответ   ключевое   слово  SIZE,   которое   будет 
означать поддержку данного расширения. Если слово SIZE включено в ответ на 
команду  EHLO, это означает, что клиент, передавая письмо, может уведомить 


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

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