те   или   иные   расширения  SMTP,   подключаясь   к   серверу,   использует   команду 
EHLO  вместо   команды  HELO.   В   ответ   на   данную   команду   сервер   сообщает 
клиенту с помощью многострочного отклика 250, какие именно расширения он 
поддерживает.   Впоследствии   клиент   должен   ожидать,   что   все   расширения, 
заявленные сервером в ответ на команду EHLO поддерживаются в данном сеансе 
связи с сервером и может использовать новые команды или функциональные 
возможности в данном сеансе связи. Все расширения, не включенные сервером 
в ответ на команду EHLO, НЕ должны использоваться клиентом, если сервер не 
поддерживает расширений  SMTP  (или говорят  ESMTP), то  в ответ на  команду 
EHLO сервер должен ответить откликом 500. Рассмотрим пример подключения к 
серверу SMTP в режиме EHLO (файл ehlo.cap).

Известно, что как в заголовке, так и в теле письма можно использовать 

только   символы   набора  US-ASCII.   В   случае,   когда  Content-Transfer-Encoding: 
8bit,   это   означает,   что   в   теле   письма/части   письма   могут   встретиться 
произвольные   байты,   но   выдерживаются   ограничения   на   длину   строк, 
введенные в RFC2821, в случае, если Content-Transfer-Encoding: binary, в письме 
не только могут встретиться произвольные байты, но и ограничения на длину 
строк могут не выполняться. ВООБЩЕ ГОВОРЯ, использование обоих механизмов 
кодирования   (7-bit  или   8-bit)   недопустимо   (так   как   не   все   сервера   смогут 
передать   такие   письма),   хотя   и   возможно,   рассмотрим   примеры   такой 
конфигурации.   Если   сервер   готов   принимать   сообщения   с   механизмом 
кодирования   8bit,   то   говорят,   что   сервер   поддерживает   расширение  SMTP 
называемое 8BITMIME. Если сервер сообщает клиенту в ответе на команду EHLO 
строку, содержащую ключевое слово 8BITMIME, это означает, что данный сервер 
поддерживает работу с такими письмами и клиент может передавать письма с