Протокол POP3

Для небольших организаций невыгодно держать у себя систему для передачи сообщений (message transport system). Это связано с тем, что в небольших, не специализирующихся на компьютерных технологиях организациях, как правило, рабочие станции клиентов сети не имеют достаточно ресурсов (производительности или дискового пространства) для обеспечения работы полного SMTP-сервера. Кроме того, таким пользователям электронной почты может быть просто невыгодно держать персональный компьютер постоянно подключенным к Internet.

Для решения этой проблемы был разработан почтовый протокол для работы в офисе — POP (Post Office Protocol). Его наиболее распространенный вариант — РОРЗ (Протокол почтового отделения версия 3). Этот протокол позволяет рабочим станциям динамически получать доступ к своим почтовым ящикам, расположенным на сервере, предназначенном для обслуживания электронной почты в данной организации.

РОРЗ — это простейший протокол для работы пользователя с содержимым своего почтового ящика. Он позволяет только забрать почту из почтового ящика сервера на рабочую станцию клиента и удалить ее из почтового ящика на сервере. Всю дальнейшую обработку почтовое сообщение проходит на компьютере клиента.

РОРЗ -сервер не отвечает за отправку почты, он работает только как универсальный почтовый ящик для группы пользователей. Когда пользователю необходимо отправить сообщение, он должен установить соединение с каким-либо SMTP-сервером и отправить туда свое сообщение по SMTP. Этот SMTP-сервер может быть тем же хостом, где работает РОРЗ -сервер, а может располагаться совсем в другом месте.

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

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

Команды РОРЗ состоят из ключевых слов, состоящих из ASCII-символов, и одним или несколькими параметрами, отделяемыми друг от друга символом «пробела» — . Все команды заканчиваются символами «возврата каретки» и «перевода строки» — . Длина ключевых слов не превышает четырех символов, а каждого из аргументов может быть до 40 символов.

Ответы РОРЗ -сервера на команды состоят из строки статус- индикатора, ключевого слова, строки дополнительной информации и символов завершения строки — . Длина строки ответа может достигать 512 символов. Строка статус -индикатора принимает два значения: положительное («+ОК») и отрицательное («-ERR»). Любой сервер РОРЗ обязан отправлять строки статус- индикатора в верхнем регистре, тогда как другие команды и данные могут приниматься или отправляться как в нижнем, так и в верхнем регистрах.

Ответы РОРЗ -сервера на отдельные команды могут составлять несколько строк. В этом случае строки разделены символами . Последнюю строку информационной группы завершает строка, состоящая из символа «.» (код — 046) и , т. е. последовательность «CRLF.CRLF».

РОРЗ -сессия состоит из нескольких частей. Как только открывается TCP-соединение и РОРЗ -сервер отправляет приветствие, сессия должна быть зарегистрирована — состояние аутентификации (AUTHORIZATION state). Клиент должен зарегистрироваться в РОРЗ -сервере, т. е. ввести свой идентификатор и пароль.

После этого сервер предоставляет клиенту его почтовый ящик и открывает для данного клиента транзакцию — состояние начала транзакции обмена (TRANSACTION state). На этой стадии клиент может считать и удалить почту своего почтового ящика.

После того как клиент заканчивает работу (передает команду QUIT), сессия переходит в состояние UPDATE — завершение транзакции. В этом состоянии РОРЗ -сервер закрывает транзакцию данного клиента (на языке баз данных — операция COMMIT) и закрывает TCP-соединение.

В случае получения неизвестной, неиспользуемой или неправильной команды, РОРЗ -сервер должен ответить отрицательным состоянием индикатора.

РОРЗ -сервер может использовать в своей работе таймер контроля времени соединения. Этот таймер отсчитывает время «бездействия» («idle») клиента в сессии от последней переданной команды. Если время сессии истекло, сервер закрывает TCP-соединение, не переходя в состояние UPDATE (иными словами, откатывает транзакцию или на языке баз данных — выполняет ROLLBACK).

Не забывайте, что РОРЗ -сервер может обслуживать группу клиентов, которые, возможно, присоединяются по коммутируемой линии, и, следовательно, необходимо иметь средство автоматического регулирования времени соединения. По спецификации РОРЗ -таймер контроля состояния «idle» должен быть установлен на промежуток времени не менее 10 минут.

При открытии TCP-соединения РОРЗ -клиентом, РОРЗ -сервер отправляет сообщение приветствия (далее во всех примерах РОРЗ -протокола используются следующие обозначения: С —клиент, S — сервер РОРЗ):

S: +OK РОРЗ server ready

Теперь РОРЗ -сессия находится в состоянии аутентификации (AUTHORIZATION), и клиент должен зарегистрировать себя на РОРЗ -сервере. Это может быть выполнено либо с помощью команд USER и PASS — ввод открытых пользовательского идентификатора и пароля (именно этот способ используется чаще), либо командой АРОР — аутентификация цифровой подписью, на базе секретного ключа. Любой РОРЗ -сервер должен поддерживать хотя бы один из механизмов аутентификации.

Команда USER имеет следующий формат:

Аргументом — «name» является строка, идентифицирующая почтовый ящик системы. Этот идентификатор должен быть уникальным в данной почтовой системе РОРЗ -сервера. Если ответом на эту команду является строка индикатора «+OK», клиент может отправлять команду PASS — ввод пароля или QUIT — завершить сессию. Если ответом является строка «-ERR», клиент может либо повторить команду USER, либо закрыть сессию. Примеры использования команды:

S: -ERR sorry, no mailbox for frated here

S: +OK mrose is a real hoopy frood

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

Команда PASS используется только после положительного ответа на команду USER:

Аргументом команды является строка пароля данного почтового ящика. После получения команды PASS, РОРЗ -сервер, на основании аргументов команд USER и PASS, определяет возможность доступа к заданному почтовому ящику. Если РОРЗ -сервер ответил «+OK», это означает, что аутентификация клиента прошла успешно и он может работать со своим почтовым ящиком, т. е. сессия переходит в состояние TRANSACTION. Если РОРЗ- сервер ответил «-ERR», то либо был введен неверный пароль, либо не найден указанный почтовый ящик:

S: +OK mrose is a real hoopy frood

S: -ERR maildrop already locked

S: +OK mrose is a real hoopy frood

S: +OK mrose’s maildrop has 2 messages (320 octets)

Команда аутентификации пользователя АРОР не входит в список обязательно реализуемых команд РОРЗ -сервера. Эта команда предоставляет значительно больший (по сравнению с командами USER или PASS) уровень защиты аутентификации пользователя при открытии сессии AUTHORIZATION и используется только тогда, когда к обеспечению конфиденциальности доступа к информации почтовых ящиков предъявляются повышенные требования. Эта команда может быть передана клиентом РОРЗ -сервера после получения приветственного сообщения или после ошибки обработки команд USER/PASS.

АРОР name digest

Аргументами команды являются: name — имя пользователя (то же, что и в команде USER), digest — шифрованная (по алгоритму MD5) строка пароля. Применяемый здесь алгоритм необратимого шифрования для построения секретного ключа использует открытый ключ и временную метку. Временные метки передаются хосту клиента вместе с сообщением приветствия. Например, для UNIX-машин временная метка может иметь вид: , где process-ID — это идентификатор процесса, clock — состояние таймера на момент установления соединения, hostname — имя компьютера РОРЗ -сервера. Этот механизм позволяет достичь очень высокой степени защищенности. Далее показан пример работы команды АРОР.

S: +OK РОРЗ server ready [email protected]

С: АРОР mrose c4c9334bac560ecc979e58001b3e22fb

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

Алгоритм на основании открытого ключа «tanstaaf и временной метки

[email protected]> построил шифрованную строку «c4c9334bac560ecc979e5800Ib3e22fb».

К командам состояния AUTHORIZATION может относиться команда закрытия РОРЗ- сессии — QUIT , если она была отправлена в режиме AUTHORIZATION (например, при вводе неправильного пароля или идентификатора пользователя):

Эта команда отправляется без аргументов и всегда имеет единственный ответ «+ОК», например:

S: +ОК dewey POP3 server signing off

После того как клиент успешно прошел процедуру аутентификации в РОРЗ- сервере, и РОРЗ- сервер «закрыл» определенный почтовый ящик только для использования данным клиентом (для тех, кто работал с базами данных, это называется EXCLUSIVE ACCESS LOCK), РОРЗ- сессия переходит в режим TRANSACTION, и клиент может начать работу со своей почтой.

Команда STAT (без аргументов) используется для просмотра состояния текущего почтового ящика.

В ответ РОРЗ- сервер возвращает строку, содержащую количество и общий размер в байтах сообщений, которые клиент может получить с РОРЗ- сервера. Сообщения, помеченные на удаление, не учитываются. Формат ответа: «+ОК nn mm», где nn — количество сообщений, mm — их общий объем:

В этом примере РОРЗ -сервер сообщает, что в данном почтовом ящике находятся два сообщения общим объемом 320 байт.

После того как РОРЗ -сервер открыл почтовый ящик, он присваивает каждому сообщению номер и устанавливает его размер в байтах. Первому сообщению присваивается число 1, второму — 2 и т. д. Далее во всех командах, относящихся к сообщениям, РОРЗ -сервер ссылается на сообщения по их номерам и указывает их размер только в десятичном виде.

Команда LIST может передаваться как с аргументом msg — номером сообщения, так и без аргумента:

Если команда содержит аргумент, и сообщение с указанным номером существует, ответом на нее будет «информационная строка», которая содержит номер сообщения и размер сообщения в байтах. Если аргумент не указан — ответом будет список информационных строк обо всех сообщениях в данном почтовом ящике. Сообщения, помеченные на удаление не фигурируют в этом списке:

S: +ОК 2 messages (320 octets)

S: -ERR no such message, only 2 messages in maildrop

Следующая команда — команда RETR — используется для передачи клиенту запрашиваемого сообщения:

Аргумент команды — номер сообщения. Если запрашиваемого сообщения нет, возвращается отрицательный индикатор «-ERR».

S: +ОК 120 octets

После получения, сообщение, как правило, помечается на удаление из почтового ящика, при этом используется команда DELE:

Аргумент команды— номер сообщения. Сообщения, помеченные на удаление, реально удаляются только после закрытия транзакции, на стадии UPDATE.

S: +ОК message 1 deleted

S: -ERR message 2 already deleted

Для проверки состояния соединения с РОРЗ- сервером используется команда NOOP . При активном соединении ответом на нее будет положительный индикатор «+ОК»:

Для отката транзакции внутри сессии используется команда RSET (без аргументов). Если пользователь случайно Пометил на удаление какие-либо сообщения, он может убрать эти пометки, отправив эту команду:

S: +OK maildrop has 2 messages (320 octets)

После того как пользователь проделал в режиме TRANSACTION все необходимые действия, он должен перейти в режим UPDATE. Для этого клиент РОРЗ отправляет команду QUIT. По этой команде все сообщения, помеченные на удаление, реально уничтожаются в почтовом ящике. Если сессия TRANSACTION завершается каким-либо другим способом (сбой сервера, сети или др.) никаких изменений в состоянии почтового ящика не происходит.

РОРЗ- сервер может поддерживать еще несколько команд, которые предоставляют пользователю большую свободу в манипулировании сообщениями, но которые не входят в список обязательных для реализации команд, т. е. ваш РОРЗ- сервер может их и не поддерживать. Одной из таких команд является команда ТОР:

По этой команде пользователь может получить «n» первых строк сообщения с номером «msg». РОРЗ- сервер по запросу клиента отправляет заголовок сообщения, затем пустую строку, затем требуемое количество строк сообщения (если количество строк в сообщении меньше указанного в параметре «n», пользователю передается все сообщение).

Различные расширения РОРЗ- протокола могут включать в себя другие команды или поддерживать расширения описанных команд. Эту или другую дополнительную информацию вы можете найти в соответствующих RFC, но большинство РОРЗ- систем работают только с набором описанных выше команд.

Ниже приведена стандартная сессия работы с РОРЗ -протоколом.

S: +OK РОРЗ server ready

S: +OK mrose is a real hoopy frood

S: +OK mrose’s maildrop has 2 messages (320 octets)

Источник

Почта. Основы настройки в Linux

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

Итак, прежде, чем бросаться настраивать почтовый сервер, необходимо понять, как в принципе работает почта.

Буквально на пальцах рассмотрим пример. Пусть у нас есть внешний статический ip — 195.195.122.129 и собственный почтовый сервер, зарегистрировано доменное имя example.ru. Когда кто-то посылает почту на почтовый адрес, например, thedude@example.ru, то, рано или поздно, запрос относительно того, на какой же ip отправлять почту человеку с адресом на домене example.ru (то есть dns-запрос), дойдет до dns-сервера, где хранятся mx-записи с реквизитами example.ru, то есть говоря еще проще — этот dns-сервер отвечает в соответствии с этой записью, что почту, идущую на example.ru, нужно перенаправлять на 195.195.122.129. А когда письмо приходит на наш сервер мы уже его обрабатываем сами. Обрабатывать пришедшее письмо мы будем с помощью Message Transport Agent (далее MTA). Под MTA мы будем понимать программу, которая может:

1. Пересылать письма от пользовательского почтового клиента (Mail User Agent, далее MUA), к удаленному почтовому серверу. MTA пересылает письма, используя протокол SMTP (Simple Mail Transfer Protocol). Примерами MUA служить Mozilla Thunderbird, MS Outlook и др.

2. Доставлять письма в локальные почтовые ящики (заметьте, что здесь имеются ввиду ящики на сервере, а не на локальных компьютерах пользователей).

3. Пересылать письма другим MTA.

В данной статье мы будем рассматривать MTA Postfix. Он прост в конфигурировании, что позволит сосредоточиться на содержании, а не на форме. Приведем ниже основные параметры главного конфигурационного файла — main.cf. К примеру, в openSUSE этот файл находится в каталоге /etc/postfix. Вы можете изменять значения параметров в соответствии со своими потребностями.

1. queue_directory = /var/spool/postfix

В процессе приема-получения почты письма могут находиться в разном состоянии. Одни только-только переданы на отправку, другие уже получены и пользователю остается только забрать их, а третье вообще зависло, потому что менеджер, которому отправляется письмо, был после хардкорной пьянки и не мог внятно продиктовать свой email, так что почта не может дойти до адресата. Для каждой из групп писем, имеющих одинаковый статус, предусмотрены отдельные каталоги, которые будут содержаться именно там, где указано в параметре queue_directory.

2. mail_owner = postfix

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

3. myhostname = mail.example.ru

Здесь мы задаем полностью определенное доменное имя нашего хоста. Это имя будет указываться в операциях, выполняемых про протоколу SMTP, в частности, в приветствии HELO. В принципе этот параметр может отсутствовать, если задан следующий параметр — mydomain. Можно значение myhostname вообще оставить пустым, при этом задав непустое значение для mydomain. Но лучше его все-таки задать, поскольку некоторые почтовые серверы, которым мы пересылаем почту, могут ругаться на то, что значение myhostname левое, неизвестно откуда взятое и вообще откажутся принимать от нас почту. В любом случае, если мы задаем значение параметра myhostname, значение mydomain будет сгенерировано автоматически на основании значения myhostname.

4. mydomain = example.ru

Здесь мы пишем имя нашего домена. И если мы пропустили предыдущий параметр, то он будет автоматически создан путем слияния результата вывода команды «uname -n», определяющей имя текущего хоста.

5. myorigin = example.ru

Этот параметр при отправлении почты добавляет свое значение к адресу отправителя, если оно указано не полностью. Например, если почта адресована юзеру thedude (это может быть даже почта, исходящая от локальных программ на данном сервере, например mdadm может послать сообщение с текстом «чувак, проверь-ка рейд-массивы»), то адрес, в соответствии со значением myorigin = example.ru, будет преобразован в thedude@example.ru.

6. mydestination = localhost, $mydomain, $myhostname, localhost.$mydomain

Как было сказано выше, одной из функций MTA является получение почты от одних MTA, и персылка ее другим MTA. Так вот, параметр mydestination служит для того, чтобы почта, приходящая на определенные адреса, указанные в значении параметра, не перенаправлялась куда-то, а оседала на нашем сервере в локальные почтовые ящики. То есть в нашем случае, мы будем принимать без перенаправления почту с адресами thedude@mail.example.ru, thedude@example.ru.

Да, еще один момент! Может еще быть непонятным — а как же заводить пользователей на почтовом сервере, давать им пароли, то есть осуществлять полноценный контроль пользовательских учетных записей. Например, нужно завести учетные записи coolboy@example.ru и coolgirl@example.ru. Для этого на почтовом сервере просто необходимо завести локальных пользователей, типа useradd coolboy; passwd coolboy; (далее ввести пароль для крутого парня) и, соответственно useradd coolgirl; passwd coolgirl; (девушку мы тоже без пароля не оставим). Мы можем посмотреть, что пользователи добавлены в файле /etc/shadow. Там будут логины и хеши паролей.

Да, еще один момент, команда useradd предусматривает сразу установку пароля (параметр -p), но, к сожалению, все равно приходится использовать passwd после этого, потому что аутентификация происходит с использованием хеша пароля, а useradd с параметром -p записывает пароль в /etc/shadow открытым текстом, например мы задали пароль 123456, и в файлик запишется 123456, что будет принято программой аутентификации за хеш пароля, в итоге юзер не получит почту с сообщением о том, что пароль неверный.

Таким образом, праильно указав, в соответствии со своими потребностями, вышеназванные параметры, мы получаем работоспособный MTA. Однако, это еще не все. Почта то пришла на наш сервер. А пользователям ее кто раздавать будет. А может быть они ее будут забирать сами? Сейчас мы ответим и на эти вопросы.

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

Однако, чтобы что-то услышать, для этого надо прежде всего слушать. Логично? То есть на сервере должен крутиться демон в ожидании запроса по POP3 протоколу. Для этого обратим свой взгляд в сторону xinetd. Xinetd (eXtended InterNET Daemon, еще его называют суперсервером) — это служба, которая управляет сетевыми соединениями. Говоря еще проще, она слушает запросы из сети по разным протоколам и у нее есть указания, каким программам на сервере передавать то, что она услышала. xinetd запускает эти программы, передавая при этом соответствующие параметры. А запросы по протоколу POP3 xinetd будет передавать POP3 серверу Qpopper (надо его сначала установить). Итак, заходим в /etc/xinetd.d, там открываем файлик qpopper и приводим его к следующему виду:

#
# qpopper — pop3 mail daemon
#
service pop3
<
disable = no
socket_type = stream
protocol = tcp
wait = no
user = root
server = /usr/sbin/popper
server_args = -s
flags = IPv4

Названия параметров говорят сами за себя. Еще раз осознаем то, что мы проделали. Соответствие указания типа интернет-сервиса и обрабатывающей его программы (в нашем случае service pop3 соответствует /usr/sbin/popper) находятся в директории /etc/xinetd.d в виде файлов, которые содержат в себе информацию о том, какая программа будет обрабатывать запросы определенного типа/ При установке Qpopper сам создал указание, что запросы по pop3 будет обрабатывать именно он. А нам необходимо его активировать, установив disable в no.

Теперь заключительный этап — настройка MUA. Необходимо задать в настройках MUA POP3-сервер, SMTP-сервер (их ip-адреса или доменные имена). В нашем случае это один и тот же компьютер, поэтому указываем в этих параметрах одно и то же. Необходимо учесть, что во внутренней локальной сети необходимо указывать ip того сетевого интерфейса, который настроен именно для работы с локальной сетью. Далее указываем имя учетной записи и пароль.

А теперь, когда вся почтовая система работает, вы можете заниматься ее оптимизацией, ведь здесь еще есть много вещей, которые можно улучшить и много нововведений, которые просто просят о том, чтобы их привнесли. Удачи!

Источник