IMAP и POP3 через прокси: как настроить приём почты

Приём почты через посредника настраивается по SOCKS5: почтовый клиент открывает обычное TCP-соединение на порт 993 или 995, и посредник переносит этот поток целиком, без разбора содержимого. Разница между самими протоколами сводится к месту хранения: IMAP оставляет письма и папки на сервере и синхронизирует состояние между устройствами, POP3 скачивает письма на устройство и освобождает ящик.

Ниже мы разбираем оба сеанса по командам, с реальным обменом строками, показываем настройку в почтовом клиенте и в коде на Python, перечисляем порты и приводим способы убедиться, что соединение действительно идёт через посредника. Отправка писем живёт по своим правилам и вынесена в соседний материал.

Чем IMAP отличается от POP3 по устройству работы

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

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

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

Отсюда следует практика по разрыву связи. Порванный сеанс IMAP означает потерю нумерации, и клиент после переподключения повторяет SELECT. Порванный сеанс POP3 в середине выгрузки означает, что команда QUIT не дошла, удаление не подтвердилось и письма остались на сервере. Второй случай безопаснее по данным.

Какой протокол выбрать под какую работу

Выбор упирается в один вопрос: сколько устройств смотрит в один ящик. Когда устройств больше одного, берём IMAP. Когда ящик обслуживает одна программа и письма нужно сложить в локальную базу, POP3 закрывает задачу меньшим числом запросов.

Смешивать протоколы на одном ящике мы советуем осторожно. Схема, где рабочая программа ходит по IMAP, а ночной скрипт по POP3 с удалением, приводит к тому, что утром половина писем пропала из папок. Когда скрипту нужен только просмотр, оставьте ему POP3 без команды DELE: письма останутся на месте, а выгрузка пройдёт.

Сеанс IMAP по командам: LOGIN, LIST, SELECT, FETCH, STORE, LOGOUT

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

* OK [CAPABILITY IMAP4rev1 SASL-IR LOGIN-REFERRALS AUTH=PLAIN] Dovecot ready.
a001 LOGIN [email protected] secret
a001 OK [CAPABILITY IMAP4rev1 IDLE NAMESPACE UIDPLUS MOVE QUOTA] Logged in
a002 LIST "" "*"
* LIST (\HasNoChildren) "/" INBOX
* LIST (\HasNoChildren \Drafts) "/" Drafts
* LIST (\HasNoChildren \Sent) "/" Sent
* LIST (\HasNoChildren \Junk) "/" Junk
a002 OK List completed (0.002 + 0.000 secs).
a003 SELECT INBOX
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
* 1483 EXISTS
* 2 RECENT
* OK [UIDVALIDITY 1571234567] UIDs valid
* OK [UIDNEXT 20194] Predicted next UID
a003 OK [READ-WRITE] Select completed.
a004 SEARCH UNSEEN
* SEARCH 1482 1483
a004 OK Search completed.
a005 FETCH 1483 (FLAGS BODY.PEEK[HEADER.FIELDS (FROM SUBJECT)])
* 1483 FETCH (FLAGS () BODY[HEADER.FIELDS (FROM SUBJECT)] {74}
From: [email protected]
Subject: ostatki po skladu
)
a005 OK Fetch completed.
a006 STORE 1483 +FLAGS (\Seen)
* 1483 FETCH (FLAGS (\Seen))
a006 OK Store completed.
a007 LOGOUT
* BYE Logging out
a007 OK Logout completed.

Разберём команды по назначению.

Три детали из этого обмена пригодятся при отладке. Первая: BODY.PEEK[] забирает содержимое без установки флага \Seen, обычный BODY[] письмо помечает прочитанным. Вторая: номера сообщений в папке меняются после EXPUNGE, поэтому длинные скрипты работают через UID и команду UID FETCH. Третья: значение UIDVALIDITY при пересоздании папки на сервере меняется, и локальный кэш клиента после этого перестраивается целиком.

Сеанс POP3 по командам: USER, PASS, STAT, LIST, RETR, DELE, QUIT

POP3 устроен проще: ответы состоят из +OK и -ERR, меток нет, многострочный ответ завершается точкой на отдельной строке.

+OK POP3 ready <[email protected]>
USER [email protected]
+OK
PASS secret
+OK Logged in.
STAT
+OK 3 14820
LIST
+OK 3 messages:
1 4210
2 5312
3 5298
.
UIDL
+OK
1 GmM2AV4x1Q3xVQ
2 QhdPYR:00WBw1
3 hUYtQ2kLm9Vc0a
.
TOP 2 5
+OK
From: [email protected]
Subject: price list
Content-Type: text/plain; charset=utf-8

Dobryy den, vysylaem preys.
.
RETR 2
+OK 5312 octets
...
.
DELE 2
+OK Marked to be deleted.
QUIT
+OK Logging out, messages deleted.

Самое важное свойство POP3 сидит в паре DELE и QUIT. Команда DELE только ставит пометку, физически ящик очищается на выходе из сеанса. Оборванная связь до QUIT оставляет письма нетронутыми, и повторный запуск скрипта заберёт их снова. Настройка почтовых программ «оставлять копии на сервере» опирается на UIDL: программа помнит идентификаторы уже забранных писем и пропускает их при следующем сеансе.

Почему приём почты через посредника идёт по SOCKS5

IMAP и POP3 это текстовые протоколы поверх обычного TCP, к HTTP они отношения не имеют. Посреднику для их переноса нужно уметь ровно одно: открыть соединение до пары «хост и порт» и переливать байты в обе стороны, не заглядывая внутрь. Так работает SOCKS5.

Рукопожатие занимает два коротких обмена. Клиент отправляет версию 0x05 и список поддерживаемых способов авторизации. Посредник выбирает способ: 0x00 при доступе по привязанному адресу либо 0x02 при доступе по логину и паролю. Затем клиент шлёт запрос CONNECT с типом адреса 0x03 для доменного имени, посредник открывает соединение и отвечает кодом 0x00. Дальше по каналу идут байты IMAP или POP3 в исходном виде.

Разрешение имён заслуживает отдельной строки. Когда клиент передаёт доменное имя внутри запроса CONNECT, имя превращается в адрес на стороне посредника, и запрос к DNS с рабочей машины наружу не уходит. В библиотеках этот режим включается схемой socks5h вместо socks5, в почтовых программах отдельной галкой в настройках сети. Мы советуем включать его сразу: прокси SOCKS5 для почтовых клиентов поддерживают оба варианта, и режим с удалённым разрешением имён даёт цельную картину по маршруту.

По HTTP приём почты тоже переносится, если программа умеет строить туннель методом CONNECT. Тогда клиент просит открыть канал до mail.example.net:993, получает 200 Connection established и работает внутри него. Такой путь встречается у серверных библиотек и у части утилит командной строки, поэтому прокси HTTP с методом CONNECT в почтовых задачах тоже применимы. Почтовые программы с графическим интерфейсом в настройках сети предлагают именно поля SOCKS, и потому в клиентах мы идём по SOCKS5. В пакете доступны SOCKS4 и SOCKS5 на выбор, для почты берём SOCKS5: он добавляет авторизацию по паре логина и пароля и передаёт имя хоста посреднику. Про разницу транспортов есть отдельный разбор про TCP и UDP через SOCKS5.

Порты, шифрование и что писать в настройках

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

Сегодня 993 и 995 стоят по умолчанию почти везде, и мы рекомендуем начинать с них: шифрование поднимается вместе с соединением, и настройка сводится к трём полям. Номера отправки, 587 и 465, работают по той же логике, они разобраны в материале про почтовые порты 25, 465 и 587.

Важная деталь про порты в связке с посредником. В окне настроек почтовой программы одновременно живут два порта: порт почтового сервера и порт посредника. Первый идёт в разделе учётной записи рядом с именем сервера, второй в разделе сети рядом с адресом посредника. Мы советуем выписать обе пары рядом до начала настройки, потому что перепутанные поля дают самый запутанный класс отказов.

Настройка в почтовом клиенте

В Thunderbird путь короткий: раздел настроек, страница «Основные», кнопка настроек соединения внизу. Там выбирается ручная настройка прокси, в поля узла SOCKS вписывается адрес и порт из списка, включается пятая версия протокола и ставится галка передачи имён DNS через посредник. Логин и пароль программа запросит при первом соединении.

Прокси-узел SOCKS:  185.24.87.14
Порт:               1080
Версия:             SOCKS v5
DNS через прокси:   включено

В eM Client и в других клиентах на своём сетевом слое поля называются похоже и лежат в разделе сети. Клиенты, которые берут системные настройки, заворачиваются через Proxifier или через локальный проброс: поднимается локальный порт, он смотрит на адрес из списка, а в почтовой программе указывается 127.0.0.1 с этим номером.

Учётная запись при этом настраивается обычным порядком: сервер входящей почты, порт 993 для IMAP или 995 для POP3, тип шифрования SSL/TLS, имя пользователя целиком с доменом. После сохранения программа делает пробное соединение, и его результат сразу показывает, работает ли связка.

Доступ к самому посреднику открывается двумя путями. Первый: в кабинете указывается адрес машины, с которой пойдут соединения, и логин с паролем в клиенте не нужен. Второй: берётся формат IP:PORT:LOGIN:PASS, и пара подставляется в поля программы. В пакет входит две одновременные привязки со свободной сменой, при двух привязанных адресах общий лимит потоков делится пополам. Для команды, где почтовые клиенты стоят на нескольких машинах, ближе вариант с логином: приватные адреса для рабочей группы настраиваются один раз и переносятся между машинами копированием строки.

Приём почты в коде: imaplib и poplib через PySocks

В Python приём почты закрывается стандартными модулями imaplib и poplib. Прокси добавляется библиотекой PySocks: она подменяет фабрику сокетов, после чего оба модуля работают без изменений в остальном коде.

import socks, socket, imaplib, email

socks.set_default_proxy(
    socks.SOCKS5, "185.24.87.14", 1080,
    username="user5521", password="pf39kd", rdns=True)
socket.socket = socks.socksocket

m = imaplib.IMAP4_SSL("mail.example.net", 993)
m.login("[email protected]", "secret")
m.select("INBOX")

typ, data = m.search(None, "UNSEEN")
for num in data[0].split():
    typ, raw = m.fetch(num, "(BODY.PEEK[])")
    msg = email.message_from_bytes(raw[0][1])
    print(num.decode(), msg.get("Subject"))
    m.store(num, "+FLAGS", "\\Seen")

m.logout()

Флаг rdns=True включает передачу доменного имени посреднику, и запрос к DNS с машины наружу не уходит. Без него имя разрешается локально, и картина по маршруту получается неполной.

import socks, socket, poplib

socks.set_default_proxy(
    socks.SOCKS5, "185.24.87.14", 1080,
    username="user5521", password="pf39kd", rdns=True)
socket.socket = socks.socksocket

p = poplib.POP3_SSL("mail.example.net", 995, timeout=30)
p.user("[email protected]")
p.pass_("secret")

count, size = p.stat()
print(count, size)

for i in range(1, count + 1):
    resp, lines, octets = p.retr(i)
    body = b"\r\n".join(lines)
    open(f"msg-{i}.eml", "wb").write(body)
    # p.dele(i)   # пометка к удалению применится на quit()

p.quit()

Строка p.dele(i) оставлена закомментированной осознанно. Пока скрипт отлаживается, ящик лучше держать нетронутым: пометки применяются на quit(), и одна невнимательная выгрузка уносит письма из ящика без возврата. Включать удаление стоит после того, как файлы стали появляться на диске в ожидаемом виде.

Подмена socket.socket действует на весь процесс. Когда в одном скрипте живут запросы напрямую и запросы через посредника, аккуратнее работать с socks.socksocket точечно: создать сокет, вызвать у него set_proxy, соединиться и передать готовый объект в imaplib.IMAP4 через параметр. Состав пакета с потоками, форматами выдачи и протоколами описан там, где оформляется пакет с доступом по SOCKS5.

Как убедиться, что соединение идёт через посредника

Проверка строится на трёх независимых наблюдениях: куда уходит соединение с машины, какой адрес видит почтовый сервер и куда уходит запрос к DNS. Совпадение всех трёх даёт полную картину.

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

# полный сеанс IMAP через SOCKS5 глазами curl
curl -v --url "imaps://mail.example.net:993/INBOX?UNSEEN" \
     --user "[email protected]:secret" \
     --proxy socks5h://user5521:[email protected]:1080

# то же самое для POP3
curl -v --url "pop3s://mail.example.net:995/1" \
     --user "[email protected]:secret" \
     --proxy socks5h://user5521:[email protected]:1080

# выходной адрес того же канала
curl -s -x socks5h://user5521:[email protected]:1080 https://ifconfig.me

Пул держится в районе 12 000 активных адресов, ротация внутри него автоматическая, список обновляется в режиме реального времени. Отсюда практический вывод для почты: соседние сеансы штатно уходят с разных выходов, и удивляться смене адреса между проверками не нужно. Когда почтовому серверу нужна ровная картина по адресам, соединения стоит держать длинными: один сеанс IMAP с командой IDLE живёт часами и остаётся на одном канале. Полный состав доступа с протоколами IPv4, HTTP, HTTPS, SOCKS4 и SOCKS5 описан на странице, где оформляется доступ к пулу IPv4 и SOCKS5.

Отдельно смотрим на ошибки авторизации. Отказ посредника и отказ почтового сервера выглядят в интерфейсе программы похоже, поэтому разделяем их порядком проверки: сначала nc -vz до посредника, затем curl с полным сеансом. Первый шаг отвечает за канал, второй за учётные данные ящика.

Стабильность канала для почты значит больше, чем пиковая скорость. Выгрузка ящика идёт короткими порциями, а сеанс IMAP с командой IDLE живёт часами и болезненно переносит обрывы: клиент после разрыва повторяет SELECT, заново сверяет UIDVALIDITY и перечитывает список писем. Мы держим серверные адреса на собственном оборудовании и потому время отклика внутри пула ровное от сеанса к сеансу. Трафик безлимитный, поэтому объём выгруженных вложений на работу канала не влияет и считать его не нужно.

Ещё один способ увидеть маршрут снаружи это журнал самого почтового сервера. Dovecot пишет строку входа с адресом клиента в формате imap-login: Login: user=<...>, rip=185.24.87.14, lip=..., и значение rip показывает тот адрес, который сервер увидел на входе. Когда у вас есть доступ к журналам своего почтового сервера, эта строка закрывает вопрос быстрее любых команд на клиентской машине.

Частые вопросы

Какой тип прокси брать под почтовый клиент?

В пакете IPv4 и SOCKS5 доступны SOCKS-4 и SOCKS-5 на выбор, и для почты мы рекомендуем SOCKS-5. Он передаёт произвольный номер порта, поддерживает авторизацию по паре логина и пароля и разрешает доменное имя на своей стороне. Почтовые программы в разделе сетевых настроек предлагают именно поля SOCKS, поэтому настройка сводится к четырём значениям: адрес, порт, версия и галка передачи имён.

В каком формате выдаётся список прокси и как его получить?

Форматов два: IP:PORT и IP:PORT:LOGIN:PASS. Первый подходит при доступе по привязанному адресу, второй при доступе по логину и паролю, который удобно вписывать в поля почтовой программы. Забрать список можно двумя путями: получить ссылку в кабинете либо скачать файл. Список обновляется в режиме реального времени, поэтому перед настройкой новой машины его стоит перечитать.

Подойдут ли прокси под мой почтовый сервис?

Каждый почтовый сервер ведёт себя по-своему, и предсказать это со стороны не выйдет, поэтому до покупки открыт бесплатный тест до 2 часов под ваш запрос. Шаги такие: подобрать тип прокси под свой софт, завести кабинет, отправить из меню запрос теста, вписать свой адрес в настройках, активировать доступ и сообщить оператору логин вместе с типом прокси. Дальше два часа идут на вашей программе и вашем ящике.

Сколько одновременных сеансов приёма выдержит пакет?

Лимит потоков на стандартных пакетах доходит до 1000, на корпоративном до 3000. Складывать потоки нескольких пакетов нельзя, каждый работает со своим лимитом, а при двух привязках цифра делится надвое. Для приёма почты запаса хватает с большим ходом: один почтовый клиент держит от одного до пяти соединений на ящик, и даже сотня ящиков под наблюдением укладывается в сотни соединений.

Вокруг приёма почты собрано несколько смежных разборов. Обратная сторона ящика, то есть путь письма от программы отправителя до сервера получателя, описана в материале про протокол SMTP и путь письма. Что переписать в настройках, когда наружу уходят письма, показано в заметке про настройку отправки по SMTP через прокси. Выбор типа доступа под конкретную программу разложен в сравнении HTTP, HTTPS, SOCKS4 и SOCKS5. Настроенный клиент полезно один раз прогнать по общему порядку диагностики, он собран в материале про проверку работы прокси.