Протокол imap используется для. Протокол SMTP и его порты. По каким протоколам происходит обмен электронной почтой? Понятия и термины

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

За подробностями - добро пожаловать под кат.

Нынешний запуск IMAP - наш второй подход к снаряду. В прошлый раз мы взяли сервер Dovecot и попробовали заточить его под себя. Результат нас не устроил: с нашими нагрузками и нашей инфраструктурой он сочетался плохо. В этот раз мы решили выбрать другой путь, и написали собственное решение.

IMAP мы запустили в мае, но анонсировали только в июне. Фактически, майская аудитория - это наши сотрудники и те пользователи, у которых клиенты автоматически определили наличие IMAP в нашей Почте и подключили к нему новые добавленные аккаунты. Трудности, специфичные для протокола IMAP1. Громоздкость самого протокола Первая версия протокола IMAP появилась в 1986 году. В данный момент актуален стандарт IMAP версии 4rev1, который был обновлен в 2003 году. За такой долгий срок стандарт существенно разросся: его текущая версия насчитывает порядка 200 страниц.

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

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

Чтобы побороть историческое наследие, нам пришлось реализовать несколько расширений. Одно из них - UID+: когда мы копируем или добавляем письмо, мы возвращаем ID нового письма, которое появилось на сервере в результате копирования или добавления. Это позволяет нам сэкономить на ресурсоемкой операции поиска, которую приходилось проводить клиенту, чтобы распознать, какое именно письмо было добавлено.

2. Отсутствие стандартного паттерна работы с сервером IMAP предоставляет множество способов решить одну и ту же задачу и, как следствие, практически у всех клиентов паттерн работы различен. Также важно, что паттерны работы существенно отличаются от того, как работает веб-почта или POP3.

Более половины приходится на долю клиентов под устройства Apple: причина в том, что у них хорошо работает автоопределение IMAP. Outloook же, напротив, по умолчанию работает по POP3, и настраивать IMAP нужно руками.
Здесь можно выделить 2 основные категории: десктопные клиенты, которые сразу запрашивают информацию обо всех письмах в ящике или папке, и мобильные клиенты, которые изначально запрашивают информацию только о самых новых письмах. Далее нам оставалось изучить запросы, которые они делают, чтобы обновить состояние, как именно они вытягивают информацию о письмах.

Почему для нас это было необходимым шагом? При скромных нагрузках (например, если сервер обслуживает корпоративную почту небольшой компании) вопрос оптимальности стоит не так остро. Однако при наших объемах оптимальность становится критичной: следовательно, нам нужно было изучить паттерны работы всего зоопарка почтовых клиентов, обращающихся к хранилищу.

3. Количество одновременных сессий По стандарту, минимальный таймаут сервера - 30 минут. Кроме того, один клиент может держать сразу несколько соединений к серверу (в протоколе не указано максимальное количество разрешенных соединений). Фактически, в нашем масштабе, это означает, что один сервер должен оптимально работать с десятками тысяч одновременных соединений. При работе в синхронном режиме такое количество соединений просто поглотило бы все ресурсы.

Для решения этой проблемы я написал библиотеку для асинхронной работы, построенную на базе edge-triggered epoll. Изначально я ставил перед собой задачу сделать библиотеку, при помощи которой можно было бы в будущем за пару дней написать свой асинхронный сервер для решения других задач, помимо IMAP; в результате практически весь код можно использовать для написания других сервисов.

4. Невозможность однозначно идентифицировать клиент Наш сервер поддерживает расширение ID, которое позволяет нам идентифицировать примерно половину клиентов. К сожалению, другая половина об этом расширении не знает (из популярных можно назвать, например, Outlook).
Понимание того, с каким клиентом мы работаем, позволяет обойти его характерные баги, а также предсказать, каким будет паттерн работы в рамках данной сессии и, соответственно, оптимизировать работу. Для нас это критично, поэтому, если клиент не называет ID, мы стараемся идентифицировать его другими путями (в случае Outlook - по тегам).5. Отсутствие команды перемещения сообщений В клиентах перемещение реализовано через копирование+удаление. Нам, разумеется, хочется, чтобы при этом копия письма помещалась в нужную папку, а оригинал удалялся и не захламлял корзину. С другой стороны, иногда сам пользователь копирует письмо в новую папку, а затем удаляет оригинал: в этом случае удаленное письмо должно помещаться в корзину.
Чтобы различать эти два кейса, после копирования мы в этой же сессии помечаем письмо специальным внутренним флажком. Когда сам пользователь копирует письмо и удаляет оригинал, клиент, как правило, обновляет список писем. При обновлении флажок автоматически сбрасывается, а удаленное письмо оказывается в корзине. Если же письмо (в рамках перемещения) удаляет клиент, обновления не происходит, и письмо, помеченное флажком, удаляется окончательно.Трудности, связанные с адаптацией текущего хранилища писем и индексов1. Идентификация сообщений Для работы по IMAP необходимо было поддержать два вида идентификаторов сообщений: порядковый номер, который может отличаться от сессии к сессии, а также уникальный номер, который сохраняется на все время жизни сообщения. Оба идентификатора должны удовлетворять довольно строгим критериям, которые не соответствовали схеме, используемой веб-почтой и POP3-сервером.

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

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

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

2. Необходимость оптимально возвращать информацию о MIME-структуре письма Практически все клиенты запрашивают информацию о структуре письма. Часто в рамках первой сессии они запрашивают такую информацию сразу обо всех письмах в папке. Парсить письмо на каждый такой запрос было бы крайне неоптимально.
Вместо этого мы сделали кэш MIME-структур. Наличие кэша помогло нам побороть сразу несколько трудностей, связанных с особенностями IMAP - в частности, отсутствие стандартного паттерна работы с сервером: поскольку часть информации хранится в кэше, это помогает нивелировать нагрузку, связанную с разными паттернами работы клиентов.

Сейчас мы кэшируем до 50 сообщений. Почему не 2-3? Дело в том, что некоторые клиенты сначала запрашивают структуру письма, а потом тело, причем сразу для нескольких сообщений; максимальное число писем в такой «пачке» обычно составляет 50 штук.

3. Оптимальная отдача частей письма Часто клиенты просят лишь текстовые части письма, которые могут находиться в конце самого сообщения. Для отображения сниппетов клиенты могут просить текстовые части сразу у 50-200 писем. Читать весь файл сообщения целиком (и обрабатывать 10 МБ письма для того, чтобы отдать 10 КБ текста) при этом не хочется; использовать индекс для определения позиции части внутри файла при каждом запросе также было бы накладно. В этой ситуации также спасает кэш структуры письма.
Преимущества такого подхода особенно наглядны тогда, когда клиент подгружает сниппеты для нескольких десятков писем: если бы мы не использовали кэш структуры, то для этого приходилось бы просмотреть много мегабайт и пожертвовать скоростью.

Для экономии места в наших хранилищах base64-части хранятся в декодированном виде внутри письма: при работе с веб-почтой это позволяет отдавать аттачи без лишнего перекодирования. Нужно было сделать схему отдачи частей с учетом этого перекодирования. Мы написали потоковое перекодирование на IMAP-сервере. Здесь также помог кэш - благодаря ему мы без перечитывания структуры можем понять, в каком виде (бинарном или нет) хранится тот или иной фрагмент.

4. Особенности работы некоторых клиентов Некоторые клиенты не полностью соответствуют стандарту RFC: например, стандартные клиенты Android версий 2.2 - 2.3 не могут корректно отображать письма без возврата некоторых необязательных полей. Основная трудность заключалась в том, чтобы определить, какие именно поля каждый из таких клиентов считает для себя обязательными: приходилось решать это методом перебора.

Выше уже упоминалось о том, что у клиентов могут быть различные подходы к удалению писем: одни перемещают их в корзину, другие - удаляют сразу и безвозвратно. При этом некоторые клиенты не понимают стандартное расширение XLIST, которое мы поддерживаем, позволяющее определить, какая именно папка является корзиной. Вместо этого они используют в качестве корзины свою папку (так себя ведет, например, Sparrow).

Интересно ведет себя Outlook: по команде удаления письма не перемещаются в корзину, а помечаются как перечеркнутые, и затем удаляются позже. Выяснилось, что для пользователей это выглядит, как баг - многие просто не понимают, что делать дальше и как добиться того, чтобы клиент вел себя привычным образом и письма оказались в корзине.

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

То, что мы вынесли для себя: IMAP - достаточно «развесистая» штука, с множеством исторических особенностей, нажитых за 26 лет, которые умножаются на разнообразие почтовых клиентов. При наших нагрузках это выливается в то, что брать готовое решение и пытаться заточить его под себя нерационально: в лучшем случае объем работы будет таким же, как при самостоятельной разработке решения. Этим путем мы и пошли:)

Виктор Стародуб,
команда Почты Mail.ru

Outlook для Office 365 Outlook для Office 365 для Mac Outlook 2019 Outlook 2016 Office для бизнеса Office 365 для администраторов Outlook 2013 Outlook 2010 Outlook 2007 Outlook 2016 для Mac Outlook для Mac 2011 Outlook в Интернете для Office 365 бизнес веб-приложение Outlook Web App для Office 365 предоставляемое 21Vianet Outlook.com Outlook 2019 для Mac Почта Outlook для Windows 10 Меньше

IMAP и POP - это два метода доступа к электронной почте. Рекомендуется использовать IMAP, если вам требуется проверять почту с нескольких разных устройств (например, телефона, ноутбука и планшета).

IMAP

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

IMAP скачивает сообщение, только когда вы его щелкаете, и вложения не скачиваются автоматически. Так вы сможете проверять сообщения гораздо быстрее, чем с помощью POP.

POP

POP связывается с вашей службой электронной почты и скачивает из нее все новые сообщения. После скачивания на компьютер с Windows или Mac OS сообщения удаляются из почтовой службы. Это значит, что после скачивания почтового сообщения к нему можно обращаться только с того же компьютера . Если вы попытаетесь обратиться к сообщению с другого устройства, ранее скачанные сообщения будут недоступны.

Отправленная почта хранится локально на компьютере с Windows или Mac OS, а не на почтовом сервере.

Многие поставщики услуг Интернета предоставляют учетные записи электронной почты, которые используют POP.

Учетные записи веб-почты или почтовые приложения

Gmail, Outlook.com, Hotmail.com и iCloud - это веб-почта . Вход в учетную запись веб-почты выполняется в Интернете.

Если у вас есть компьютер с Windows или Mac OS, вы, вероятно, использовали программу, например Outlook, Apple Mail или Thunderbird, для управления электронной почтой. Outlook, Apple Mail и Thunderbird - это приложения для работы с электронной почтой: программы, устанавливаемые на компьютере для управления электронной почтой. Они взаимодействуют с помощью службы электронной почты, например Gmail или Outlook.com, для получения и отправки электронной почты.

В почтовое приложение вы можете добавить любую учетную запись электронной почты, чтобы управлять ею оттуда. Например, вы можете добавить в приложение Outlook или Apple Mail учетные записи веб-почты (Gmail, Outlook.com, Hotmail.com, AOL и Yahoo) и почтовые учетные записи, предоставленные вашей организацией.

Добавление учетных записей веб-почты в почтовые приложения, такие как Outlook, Apple Mail, Thunderbird

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

Если приложению электронной почты не удается добавить свою учетную запись электронной почты, обычно это связано с тем, что учетная запись электронной почты настроена для доступа по протоколу POP. В этом случае необходимо обратиться к поставщику услуг электронной почты и узнать имя сервера POP и SMTP, чтобы можно было ввести информацию в почтовое приложение. Как правило, эти сведения выглядят примерно так:

Сервер входящей почты (IMAP): IMAP. _лт_имя службы >. com

Сервер входящей почты (POP): pop..com

Сервер исходящей почты (SMTP): smtp..com

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

Иногда встаёт задача перейти на новую и более удобную почтовую систему, но мешают накопленные архивы писем. Бросить их на прежнем месте? Жалко. Пароли забываются. Бывает, утрачиваются номера мобильных и email-адреса, введённые для их восстановления. Однажды можно потерять архивы навсегда. Скачать на локальный жесткий диск? Переписать на болванку или флешку? Но они ненадёжны: ломаются, теряются, портятся.

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

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

POP3 ведёт свою историю с 1984 года, когда одна из сотрудниц Института Информатики в составе Университета Южной Калифорнии, Джойс Рейнольдс, опубликовала RFC 918 - предложение стандартного протокола для получения электронной почты (POP - Post Office Protocol). Через 4 года появилась третья редакция протокола POP, а текущая, современная версия стандарта на POP3 опубликована весной 1996 года, почти 17 лет назад.

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

Сейчас уже сложно представить, что электронные письма не хранили на серверах. Их перекачивали на локальный компьютер при первой возможности и читали, сортировали по адресатам, темам и важности локально.

Интересно, что в протоколе POP2 была предусмотрена возможность работы с несколькими папками на сервере, но она оказалась невостребована, да и сам протокол распространения не получил. Поэтому в POP3 команду FOLD, которая реализовала эту возможность, убрали. POP2 обогнал время.

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

Было много попыток улучшить POP3, но ни одна из них не достигла такого успеха, как протокол IMAP, почти параллельно разивавшийся с 1985 года. История IMAP тоже весьма интересна. Например, первая реализация была сделана на Lisp-е, и его наследие навсегда осталось в протоколе в виде S-выражений , которыми кодируются сложные ответы сервера, такие как BODYSTRUCTURE.

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

Последняя версия IMAP - 4rev1 - описана в документе RFC 3501, увидевшем свет в 2003 году. Несмотря на кажущийся возраст, протокол получился живым благодаря предусмотренному на ранних этапах механизму расширений. Этот механизм, конечно, тоже не без недостатков, но тем не менее, он позволил различным людям выпустить более пятидесяти публичных расширений , многие из которых были разработаны совсем недавно и нашли широкое применение.

Современная почтовая система без поддержки доступа по IMAP - нонсенс. На протяжении нескольких лет Яндекс.Почта поддерживает IMAP в качестве сервера для работы из таких популярных клиентских программ, как Outlook, Thunderbird, Apple Mail, а также многочисленных мобильных клиентов. Кстати, именно благодаря смартфонам IMAP получил вторую волну развития. Если на персональных компьютерах уже довольно давно подавляющее большинство пользователей сделали выбор в пользу веб-интерфейса к своей почте, то с мобильными устройствами ситуация совсем не такая. Быстрые и красивые IMAP-клиенты, например в iOS, заставляют пересматривать подход к IMAP как к выбору исключительно профессиональных и «продвинутых» пользователей.

Недавно в Яндекс.Почте появилась и функция IMAP-клиента - сборщика почты с внешних серверов по IMAP - в дополнение к POP3-сборщику.

Функция не требует практически никакой настройки и рассчитана на фоновую работу после первого включения. При сборе почты через IMAP из-за описанных выше особенностей работы протокола в вашем почтовом ящике вы увидите ту структуру папок, к которой привыкли, когда пользовались предыдущей почтовой системой. Все прочтённые письма останутся прочтёнными, а непрочитанные - непрочитанными.

Включить сбор с папками в Яндекс.Почте можно со всех почтовых систем, поддерживающих протокол IMAP. Протокол непростой, у каждой реализации IMAP-сервера есть свои закидоны, и нам было важно в первую очередь обработать самый массовый вариант перехода со старой почты на новую.

По-прежнему кроме самих писем импортируются контакты из адресных книг самых распространённых почтовых сервисов.

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

Каждая команда должна быть предварена некоторым идентификатором - тегом, который затем будет использован сервером при генерации ответа на эту команду. Это позволяет «беседе» клиента с сервером быть абсолютно асинхронной - сервер вправе отвечать на команды клиента в любом порядке, так как теги позволяют однозначно сопоставить ответ ранее поданной команде. Более того, сервер может выполнять такие команды одновременно, ускоряя скорость работы с почтой, и Яндекс.Почта умеет это использовать. Одновременно это требует особого подхода к программированию как клиента, так и сервера. Если вам в этом месте вспомнился механизм sequence numbers в TCP, то запишите себе +1 в geek cred:)

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

Переходите на Яндекс.Почту, настраивайте сборщик по IMAP - и вы всегда сможете найти любое старое письмо. Уж что-что, а искать Яндекс умеет.

Базируется на транспортном протоколе TCP и использует порт 143.

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

Для отправки писем используется обычно протокол SMTP , так как собственная команда отправки протокола IMAP, называемая APPEND, считается «неудачной» и «небезопасной».

Энциклопедичный YouTube

1 / 5

✪ Principais diferenças entre IMAP e POP3

✪ POP3 vs IMAP, which one should you choose? | 123-reg Support

✪ REPORTAJE IMAP

✪ How To Enable Gmail IMAP Settings

✪ What is IMAP and How To Use It | Email Tutorial

Цель разработки протокола IMAP

Протокол IMAP представляет собой, в основном, альтернативу POP3 с зачаточными способностями по отправке.