
те или иные расширения 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, это означает, что данный сервер
поддерживает работу с такими письмами и клиент может передавать письма с