POP

POP (Post Office Protocol) - это стандартный почтовый протокол прикладного уровня, используемый клиентами электронной почты для получения почты с удалённого сервера по TCP-соединению.

POP и IMAP (Internet Message Access Protocol) являются наиболее распространёнными интернет-протоколами для извлечения почты. Практически все современные клиенты и серверы электронной почты поддерживают оба стандарта. Протокол POP был разработан в нескольких версиях, нынешним стандартом является третья версия (POP3). Большинство поставщиков услуг электронной почты (такие как Hotmail, Gmail и Yahoo! Mail) также поддерживают IMAP и POP3. Предыдущие версии протокола (POP, POP2) устарели.

Альтернативным протоколом для сбора сообщений с почтового сервера является IMAP.

Общие сведения

POP поддерживает простые требования «загрузи-и-удали» для доступа к удалённым почтовым ящикам. Хотя большая часть POP-клиентов предоставляет возможность оставить почту на сервере после загрузки, использующие POP клиенты обычно соединяются, извлекают все письма, сохраняют их на пользовательском компьютере как новые сообщения, удаляют их с сервера, после чего разъединяются.

Другие протоколы, в частности IMAP, предоставляют более полный и комплексный удалённый доступ к типичным операциям с почтовым ящиком. Многие клиенты электронной почты поддерживают как POP, так и IMAP; однако, гораздо меньше интернет-провайдеров поддерживают IMAP.

POP3-сервер прослушивает порт 110. Шифрование связи для POP3 запрашивается после запуска протокола, с помощью команды STLS (если она поддерживается), либо POP3S, которая соединяется с сервером используя TLS или SSL по TCP-порту 995.

Доступные сообщения клиента фиксируются при открытии почтового ящика POP-сессией и определяются количеством сообщений для сессии, или, по желанию, с помощью уникального идентификатора, присваиваемого сообщению POP-сервером. Этот уникальный идентификатор является постоянным и уникальным для почтового ящика и позволяет клиенту получить доступ к одному и тому же сообщению в разных POP-сессиях. Почта извлекается и помечается для удаления с помощью номера сообщения. При выходе клиента из сессии помеченные сообщения удаляются из почтового ящика.

История

POP1 определён в стандарте RFC 918 (1984), POP2 в RFC 937 (1985). Первоначальная спецификация POP3 была представлена в RFC 1081 (1988). Нынешняя же описана в RFC 1939, обновлена механизмом расширения (RFC 2449) и механизмом аутентификации (RFC 1734).

Версии POP2 был назначен порт 109.

Изначальная спецификация POP3 поддерживала только незашифрованный механизм входа в систему USER/PASS или управление доступом .rhosts. На данный момент, POP3 поддерживает различные методы аутентификации для предоставления разных уровней защиты от незаконного доступа к пользовательской почте. Большинство из них предоставлены механизмами расширения POP3. Клиенты POP3 поддерживают методы SASL через расширение AUTH. В рамках проекта Массачусетского технологического института «Афина» также был введён метод на основе Кербероса. RFC 1460 ввёл APOP в основной протокол. APOP — протокол вида «запрос/ответ», использующий функцию хэширования MD5. Среди клиентов, реализующих APOP, можно выделить Mozilla Thunderbird, Opera Mail, Eudora, Windows Live Mail, PowerMail, Apple Mail, и т. д.

Было высказано неофициальное предложение для спецификации «POP4», с рабочей реализацией сервера. Это предложение добавило основные функции управления папками, поддержку составных сообщений, а также управление флагами сообщений. Однако, никакого прогресса «POP4» не наблюдается с 2003 г.

Расширения

Механизм расширений был предложен в RFC 2449 для размещения новых расширений, а также организованного объявления о поддержке опциональных команд, таких как TOP и UIDL. RFC не намеревались поощрять расширения и подтвердили, что роль POP3 заключается в предоставлении простой поддержки в основном для требования «загрузи-и-удали».

Расширения выводятся списком командой CAPA. За исключением APOP, все опциональные команды были включены в изначальный набор возможностей. Как и в стандарте ESMTP (RFC 5321), возможности, начинающиеся с "X" являются локальными.

STARTTLS

Расширение STARTTLS позволяет использовать TLS (Transport Layer Security) или SSL (Secure Sockets Layer) для связи с помощью команды STLS, по стандартному POP3-порту. Некоторые клиенты и сервера используют метод альтернативного порта, работающий с TCP-портом 995 (POP3S).

SDPS

Британский провайдер Demon Internet ввёл расширение POP3, позволяющее иметь несколько учётных записей для каждого домена и ставшее известным как SDPS (Standard Dial-up POP3 Service). Для доступа к каждой учётной записи имя пользователя включает в себя имя хоста, например, john@hostname или john+hostname.

Google Apps используют тот же метод.

Сравнение с IMAP

Клиенты, которые оставляют почту на серверах, обыкновенно используют команду UIDL для получения текущего соответствия между количеством сообщений и сообщением, определяемым его уникальным идентификатором. Идентификатор произволен и может повторяться, если на ящике есть идентичные сообщения. Напротив, IMAP использует 32-битный уникальный идентификатор (UID), присваиваемый сообщениям по возрастанию (но не обязательно подряд) по мере их получения. При извлечении новых сообщений IMAP-клиенты запрашивают UID больший, чем наивысшее значение UID среди всех ранее извлечённых сообщений, в то время как POP-клиент должен выбирать из всей карты UIDL. Для больших почтовых ящиков это может потребовать значительной обработки.

MIME служит в качестве стандарта для вложений и не-ASCII текста в электронных сообщениях. Хотя ни POP3, ни SMTP не требуют MIME-отформатированного сообщения, по существу, все не-ASCII сообщения идут в формате MIME, поэтому POP-клиенты должны также «понимать» и использовать MIME. IMAP, по определению, принимает MIME-форматированные сообщения.

Состояния сеанса

В протоколе POP3 предусмотрено 3 состояния сеанса:

Авторизация

Клиент проходит процедуру Аутентификации.

Транзакция

Клиент получает информацию о состоянии почтового ящика, принимает и удаляет почту.

Обновление

Сервер удаляет выбранные письма и закрывает соединение.

Команды протокола

Основные команды POP3

STAT

В ответ на команду STAT сервер возвращает количество сообщений в почтовом ящике и общий размер ящика в октетах. Сообщения, помеченные для удаления, при этом не учитываются. Например, ответ " +OK 4 223718" означает, что в почтовом ящике имеется 4 сообщения общим объемом 223718 октет.

LIST

Ответ на команду LIST без аргумента: список сообщений в почтовом ящике, содержащий их порядковые номера и размеры в октетах.

Пример:

C: LIST

S: +OK 4 visible messages (223718 octets)

S: 1 333

S: 2 111293

S: 3 111285

S: 4 807

S: .

В данном примере в ящике имеется 4 сообщения, длины которых, соответственно, 333, 111293, 111285 и 807 октет.

Обратите внимание, что, поскольку ответ состоит из нескольких строк, заканчивается он строкой, состоящей из одной точки.

Если в качестве аргумента команды LIST указать номер сообщения, то в ответе будет содержаться информация только об одном запрошенном сообщении:

C: LIST 2

S: + OK 2 1112931.3

RETR

Требует в качестве аргумента номер существующего и не помеченного для удаления сообщения.

В ответ сервер присылает запрошенное сообщение.

DELE

Требует в качестве аргумента номер существующего и не помеченного для удаления сообщения. Указанное сообщение помечается для удаления. До конца сеанса обращаться к нему становится невозможно. После окончания диалога, когда сеанс переходит в состояние обновления, сообщение удаляется окончательно.

NOOP

На эту команду сервер должен дать положительный ответ. Никаких других действий не производится.

RSET

Сервер снимает все установленные ранее пометки для удаления.

QUIT

Завершение сеанса. Если в ходе сеанса какие-то сообщения были помечены для удаления, то после выполнения команды QUIT они удаляются из ящика.

Дополнительные возможности POP3

Кроме обязательных команд, перечисленных выше, программное обеспечение, реализующее взаимодействие по протоколу POP3, поддерживает дополнительные возможности (capabilities), вводящие новые команды, влияющие на исполнение основных команд, облегчающие взаимодействие клиента и сервера, информирующие об особенностях реализации сервера и хранилища сообщений.

В число дополнительных возможностей входят, например, команды авторизации. Хотя бы один механизм авторизации должен быть реализован, так как доступ к почтовому ящику предоставляется только после аутентификации. Но, поскольку таких механизмов несколько, и их выбор оставляется на усмотрение разработчиков и администраторов, соответствующие команды не входят в число обязательных.

Предусмотрена команда САРА, позволяющая клиенту получить информацию о дополнительных возможностях, реализованных на сервере, и их параметрах. Ответ на эту команду аналогичен ответу на команду EHLO протокола SMTP .

Команда САРА

В ответ на команду САРА сервер присылает клиенту список ключевых слов, соответствующих дополнительным возможностям протокола POP3, поддерживаемым сервером, и, при необходимости, параметры этих возможностей.

Стандартные ключевые слова не могут начинаться с буквы Х. Эта буква зарезервирована для ключевых слов, соответствующих дополнительным возможностям, вводимым разработчиками и не описанным в официальных стандартах.

Эта команда может выполняться на любом этапе диалога клиента и сервера, причем результаты ее выполнения до и после авторизации могут различаться, так как параметры некоторых дополнительных возможностей могут быть различными для разных пользователей.

Команда САРА описана в RFC 2449 . Там же описан и ряд дополнительных команд протокола POP3.

Пример:

C: CAPA

S: +OK Capability list follows

S: TOP

S: USER

S: SASL CRAM-MD5 KERBEROS_V4

S: RESP-CODES

S: LOGIN-DELAY 900

S: EXPIRE 60

S: UIDL

S: IMPLEMENTATION Shlemazle-Plotz-v302

S: .

USER – авторизация по паролю

Простейший механизм авторизации, описанный в RFC 1939 , предусматривающий передачу имени пользователя и пароля открытым текстом.

Сначала клиент направляет серверу команду USER . В качестве аргумента команды используется имя, под которым на сервере зарегистрирован ящик, к которому запрашивается доступ. Если такой ящик существует, сервер дает положительный ответ, а клиент посылает команду PASS с паролем для доступа к данному ящику в качестве аргумента.

Пример:

C: USER lonk

S: +OK Password required for lonk.

C: PASS my_password

S: +OK lonk has 4 visible messages (0 hidden) in 223718 octets.

Авторизация по зашифрованному паролю

Серьезный недостаток использования команд USER и PASS – необходимость передавать пароль по сети открытым текстом. Это дает потенциальному злоумышленнику возможность перехватить пароль. Опасность возрастает, если пользователь часто проверяет свою почту: в этом случае соединение устанавливается регулярно, с небольшим интервалом, и каждый раз по сети передается пароль.

В качестве альтернативного способа авторизации RFC 1939 рекомендует команду APOP, предполагающую отправку пароля в зашифрованном виде, причем в каждом сеансе используется новый ключ.

Сервер, поддерживающий команду APOP, в начальном приветствии посылает клиенту уникальный идентификатор, содержащий метку времени в формате msg-id, описанном в RFC 822. Поскольку наличие такой метки уже свидетельствует о поддержке сервером команды APOP , ключевого слова, соответствующего этой команде, возвращаемого в ответе сервера на команду САРА, не предусмотрено.

Клиент в качестве аргументов команды APOP передает серверу имя пользователя и шестнадцатизначную последовательность шестнадцатиричных чисел в нижнем регистре, вычисляемую по алгоритму MD5, описанному в RFC 1321 . В качестве исходного текста для вычисления этой последовательности берется строка, состоящая из переданного сервером уникального идентификатора и пароля пользователя. Чем длиннее строка пароля, тем сложнее злоумышленнику вычислить ее на основании передаваемой в команде APOP последовательности. Рекомендуется использовать пароли, содержащие не меньше восьми символов.

Пример :

S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>

C: APOP mrose c4c9334bac560ecc979e58001b3e22fb

S: +OK maildrop has 1 message (369 octets)

Здесь

уникальный идентификатор: <1896.697170952@dbc.mtview.ca.us>

имя пользователя: mrose

пароль: tanstaaf

Имя пользователя передается открытым текстом в первом аргументе команды APOP второй аргумент: c 4 c 9334 bac 560 ecc 979 e 58001 b 3 e 22 fb вычисляется по алгоритму MD5 из строки <1896.697170952@dbc.mtview.ca.us>tanstaaf, состоящей из уникального идентификатора и пароля.

Авторизация с использованием SASL

Команда AUTH , предложенная в RFC 1734 . Ответы сервера предваряются символами плюс и пробел: "+ ". Если клиент хочет прервать аутентификацию, он посылает символ звездочка: "*".

В строке ответа сервера на команду САРА после ключевого слова " SASL" сервер передает список ключевых слов, соответствующих поддерживаемым сервером механизмам авторизации. Ключевые слова разделяются пробелами.

Например:

SASL CRAM - MD5 KERBEROS_V4

STLS – криптографическая защита сеанса POP3 с использованием протокола TLS

Команда AUTH, описанная выше, предоставляет простейший механизм шифрования данных, передаваемых по протоколу POP3. Более надежный способ криптографической защиты обеспечивается протоколом TLS. Его использование совместно с протоколом POP3 описано в RFC 2595 .

Для начала защищенного сеанса клиент посылает серверу команду STLS. После этого клиент и сервер согласуют параметры взаимодействия в соответствии с протоколом TLS . Выполнять команду STLS следует на этапе авторизации до передачи аутентификационных данных, что позволяет защитить эти данные от перехвата. После успешного начала защищенного сеанса клиент может аутентифицироваться.

Если реализована возможность шифрования сеанса, сервер может отклонять попытки клиента аутентифицироваться без установления защищенного сеанса. Такой запрет может быть установлен как для всех, так и для отдельных пользователей. Допустимо использование разных портов TCP для работы по протоколу POP3 с шифрованием и без.

В процессе согласования параметров шифрования клиент должен удостовериться, соответствует ли доменное имя сервера используемому им сертификату, чтобы убедиться, что данные на пути к серверу не перехватываются злоумышленниками.

Результаты выполнения команды САРА до начала защищенного сеанса и после могут различаться.

TOP – первые строки сообщения

Дополнительная команда TOP, описанная в RFC 1939 , позволяет клиенту получить заголовок и первые строки тела указанного в аргументе сообщения. Эта команда дает пользователю возможность, не скачивая все сообщение, на основании адреса отправителя и темы, указанных в заголовке, а также из первых строк письма, принять решение, получать данное сообщение сейчас, сделать это позже или удалить, не читая.

Формат команды:

ТОР номер_сообщения число_строк

Если второй аргумент больше, чем число строк в теле сообщения, то клиент получает сообщение целиком.

UIDL – уникальный идентификатор сообщения

Сервер присваивает каждому сообщению идентификатор, уникальный в пределах почтового ящика. Клиент может использовать уникальные идентификаторы для того, чтобы найти сообщение в ящике, так как, в отличие от порядкового номера, идентификатор не меняется при удалении сообщений. Так, для того, чтобы определить, есть ли в почтовом ящике новые письма, клиент может запросить список идентификаторов сообщений в ящике и сравнить его со списком идентификаторов уже полученных сообщений.

Доступ к уникальным идентификаторам сообщений предоставляет дополнительная команда UIDL, описанная в RFC 1939 . Если она используется без аргументов, то в ответ на нее сервер присылает порядковые номера и уникальные идентификаторы всех сообщений в почтовом ящике, не помеченных для удаления. Если в качестве аргумента указан номер сообщения в ящике, то сервер возвращает порядковый номер и уникальный идентификатор только этого сообщения.

Пример:

C: UIDL

S: +OK

S: 1 whqtswO00WBw418f9t5JxYwZ

S: 2 QhdPYR:00WBw1Ph7x7

S: .

C: UIDL 2

S: +OK 2 QhdPYR:00WBw1Ph7x7

RESP-CODES – расширенные коды ответов

Наличие в ответе команды САРА строки "RESP-CODES" не свидетельствует о поддержке какой-либо команды. Эта дополнительная возможность позволяет серверу использовать расширенные коды ответов.

Расширенные коды ответов передаются после стандартного индикатора состояния: "+OK" или "–ERR" и заключаются в квадратные скобки. Они могут иметь иерархическую структуру, то есть могут состоять из нескольких кодов, каждый из которых уточняет предыдущие. В этом случае коды разделяются косой чертой: "/". Необязательный текст, поясняющий ответ сервера, может следовать после расширенного кода.

RFC 2449. Этот код передается после успешной аутентификации и свидетельствует о том, что доступ к почтовому ящику, тем не менее, невозможен, поскольку в настоящее время ящик уже используется, возможно, другим сеансом POP3.

Пример :

C: APOP mrose c4c9334bac560ecc979e58001b3e22fb

S: -ERR Do you have another POP session running?

LOGIN-DELAY – определение минимального интервала времени между сеансами

Многие пользователи хотят проверять свою почту как можно чаще, инициируя все новые сеансы POP3. Это приводит к неоправданному росту нагрузки на сервер, ведь даже если пользователь не производит никаких манипуляций с ящиком, только проверяя наличие новой почты и убеждаясь, что ее нет, необходимо выполнить как минимум авторизацию клиента.

Чтобы уменьшить нагрузку на сервер, можно установить время, в течение которого клиенту не разрешается инициировать повторный сеанс. Если оно установлено, то в ответе сервера на команду САРА должна содержаться строка вида:

LOGIN-DELAY время_задержки

где время_задержки – интервал в секундах, в течение которого не разрешается начинать повторный сеанс POP3. Время отсчитывается от момента положительного ответа сервера на одну из команд авторизации (PASS, APOP или AUTH) до следующей попытки авторизации того же пользователя.

Время задержки может различаться для разных пользователей. В этом случае, если команда САРА выполняется на этапе авторизации, когда вызывающий пользователь еще не известен, рекомендуется в ответе давать строку

LOGIN-DELAY время_задержки USER

где время_задержки – максимальное из всех установленных на сервере времен задержки. Пометка "USER" свидетельствует о том, что на самом деле время задержки зависит от пользователя и может быть уточнено после авторизации. Выполнив команду САРА на этапе транзакции, клиент может получить точное время задержки именно для данного пользователя.

PIPELINING - группирование команд

Аналог одноименного расширения ESMTP .

Эта дополнительная возможность не вводит новых команд, но позволяет клиенту посылать серверу команды, не дожидаясь ответов на предыдущие. Это ускоряет обмен данными. Например, клиент может посылать команды DELE в то время, когда сервер шлет ему запрошенные ранее сообщения.

EXPIRE – ограничение времени хранения сообщений на сервере

Сообщения могут храниться на сервере, пока пользователи сами их не удалят. К сожалению, далеко не всегда можно ожидать от пользователей бережного отношения к дисковому пространству сервера. Трудно потребовать от людей регулярно забирать почту и удалять с сервера старую корреспонденцию, поэтому многие администраторы прибегают к использованию технических средств.

Программное обеспечение хранилища сообщений может само удалять из ящиков старые письма. Администратор может определять довольно сложные правила удаления: они могут различаться для разных пользователей, время хранения может отсчитываться от разных моментов: от поступления сообщения, от первого сеанса POP3 после поступления сообщения, от первого прочтения командой RETR или TOP и т.д. Если подобные правила определены, сервер POP3 должен информировать об этом клиента в ответе на команду САРА.

Соответствующая строка содержит ключевое слово "EXPIRE" и параметр, обозначающий время хранения сообщения в днях. Если правилами предусмотрены разные значения времени хранения при разных обстоятельствах, то выдается минимальное из них. Параметр может принимать значения:

0 – прочитанные сообщения на сервере не хранятся;

целое число – минимальное время хранения сообщения в днях;

NEVER – сообщения автоматически не удаляются.

Если для разных пользователей предусмотрены разные правила удаления старых сообщений, то на запрос САРА в состоянии авторизации сервер возвращает минимальное значение параметра EXPIRE для всех пользователей, за которым следует модификатор " USER ". Это означает, что после авторизации клиенту следует повторить команду САРА, чтобы получить более точные данные об удалении с сервера старой корреспонденции именно этого пользователя.

Примеры:

EXPIRE 5 USER - сообщения на сервере хранятся не менее пяти дней, но эта цифра может различаться для разных пользователей. После авторизации клиенту следует повторить запрос, чтобы узнать, сколько дней хранится корреспонденция данного пользователя

EXPIRE 30 - сообщения на сервере хранятся не менее тридцати дней

EXPIRE NEVER - сообщения автоматически не удаляются

EXPIRE 0 - прочитанные сообщения удаляются с сервера автоматически

Следует учитывать, что удаление устаревших писем производит программное обеспечение хранилища сообщений, а не сервер POP3. Настройка этих программных продуктов зависит от реализации, и в общем случае параметры EXPIRE могут не соответствовать реальным установкам хранилища сообщений, если администраторы не взяли на себя труд настроить их соответствующим образом.

IMPLEMENTATION – информация о сервере

Строка ответа на команду САРА IMPLEMENTATION содержит версию программного обеспечения сервера POP3. Эта информация может быть передана также в строке приветствия сервера при установлении соединения. Но из соображений безопасности эти сведения не желательно делать доступными не аутентифицированным пользователям. Потому строка IMPLEMENTATION обычно передается клиенту только в состоянии транзакции.

Строка IMPLEMENTATION предусматривает только один параметр, потому информация о сервере, передаваемая в ней, не должна содержать пробелов.