[Перевод] Каким станет email в будущем

Последнее письмо, которое вы получили, почти наверняка было свёрстано по стандарту RFC 5322 – спецификации, последний раз обновлявшейся в 2008 году. В нём могли быть вложения (их появление обеспечил MIME в 1996 году) или символы Unicode в теме – включая эмодзи, которые без костылей не поддерживались аж до 2012 года.

Кто-то набрал это письмо, нажал «Отправить» – и дальше в дело вступил SMTP (доработанный в 2008 году с выходом RFC 5321). Сообщение покочевало между несколькими почтовыми агентами и синхронизировалось с вашим телефоном по IMAP. Причём по стандарту IMAP4rev1 из RFC 3501, которому уже больше двадцати лет, – а не по более свежему IMAP4rev2, потому что Google, Office 365 и другие крупные игроки до него так и не добрались.

Операционной системе вашего телефона, скорее всего, нет и года. Через пару лет она будет считаться устаревшей. А email всё это время работает на стеке стандартов, часть которых не обновлялась больше двух десятков лет.

И дело не в том, что никто не пытается. Среди 9 953 документов Request for Comments, опубликованных для стандартизации интернет-технологий, больше 550 так или иначе упоминают почту. В среднем это один «почтовый» RFC каждые пять недель на протяжении последних 57 лет.

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

Свежая возможность, которую вы могли не заметить

Знаете ли вы, что 武@メール.グーグル сегодня такой же валидный адрес, как и user@example.com? Или что технически в адресе можно использовать эмодзи – то есть можно написать на 😅@techinch.com, и письмо дойдёт?

Это работает благодаря тройке стандартов, начиная с RFC 6530, который в 2012 году заложил основу для интернационализации почты (EAI). В IMAP4rev2 поддержка Unicode встроена изначально, а rev1 получил её через расширение из RFC 6855. Правда, старые серверы до сих пор могут её не поддерживать, а обновления Unicode-адресов для сертификатов x.509, SPF, DKIM и DMARC всё ещё дорабатываются.

Так что стандарт застрял в подвешенном состоянии. Gmail объявил о поддержке приёма писем с Unicode-адресов ещё в 2014 году, пообещав, что «в будущем» позволит создавать такие адреса. Больше десяти лет спустя мы всё ещё ждём: отправлять и получать письма с Unicode-адресов в Gmail можно, а вот сами Gmail-адреса по-прежнему ограничены буквами, цифрами и точками.

Возможности, которыми вы, возможно, так и не воспользуетесь

С самыми амбициозными нововведениями всё ровно наоборот. Взять хотя бы язык фильтрации Sieve и стандарт синхронизации почты на JSON под названием JMAP. Они существуют, ими ежедневно пользуются – но вряд ли они когда-нибудь войдут в рутину среднего пользователя Gmail или Outlook.

Sieve

if address :is "From" "best@friend.example.com" {
  fileinto "INBOX.My Best Pal";
  stop;
} //Фильтр Sieve из Fastmail, который кладёт письма от лучшего друга в инбокс

Sieve – один из самых долгоживущих почтовых проектов, и он идёт по официальному пути стандартизации. Это скриптовый язык для фильтрации писем прямо на сервере, ещё до их попадания во входящие. Появился он в 1999 году как часть Cyrus IMAP-сервера из Университета Карнеги-Меллона и с тех пор активно развивается: ему посвящено 42 RFC, последний вышел в конце 2024 года.

И это работает. Fastmail поддерживает Sieve с полноценной программируемой фильтрацией – переменными, условными ветвлениями, логикой. Хватит, чтобы написать свой спам-фильтр или настроить автоответы. А те же скрипты заработают на любом другом сервере с поддержкой Sieve – так что можно сменить сервис и забрать фильтры с собой.

Но поддержки Sieve в Google Workspace или Office 365 можно и не дождаться. Сервисы не обязаны реализовывать каждый RFC, а у обоих гигантов уже есть встроенная фильтрация – стимула поддерживать гиковский способ скриптовать почту почти нет. Мечта живёт, но сайт проекта мёртв и доступен только через Internet Archive.

JMAP

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

По словам редактора стандарта Нила Дженкинса, нынешние протоколы вроде IMAP «не были рассчитаны на современный мир», тогда как JMAP – это гибкая модель синхронизации, способная выйти за пределы почты и заодно стандартизировать контакты и календарь. В итоге получается открытый стандарт, способный потягаться с Exchange-синхронизацией от Outlook.

Разработчикам с JMAP удобнее. Вместо простого текста, который надо парсить строчка за строчкой, письма в JMAP оформлены в JSON, где каждый заголовок и часть тела чётко разделены. Из коробки – фильтры в стиле Gmail, push-уведомления, нормальный серверный поиск и работа с вложениями. Вот только всё это уже встроено в большинство современных систем – через расширения и костыли. То, что разработчикам Google и Microsoft когда-то дорого далось, сегодня попросту незаметно для пользователей.

«JMAP – штука сложная. Но спроектирована она просто отлично», – писал разработчик Джейсон Манро.

Правда, даже это не гарантирует признания. JMAP работает уже сегодня – прежде всего в Fastmail (чья команда вела разработку), а также в atmail, в серверных решениях Apache James и в сервисе маскированных адресов от 1Password. Но на широкое распространение рассчитывать не приходится: у Microsoft – своя MAPI-синхронизация в Exchange, у Gmail – собственные приложения плюс IMAP.

На вопрос, взлетит ли JMAP, Манро ответил: «JMAP – открытый, умный, современный и мощный протокол. Так что, наверное, нет».

Знакомьтесь: новый email. Выглядит точь-в-точь как старый

И это нормально. Именно стабильность подарила почте такой долгий срок жизни и сделала её одним из немногих кроссплатформенных форматов текста, который просто работает.

И всё же разработчики нет-нет да и бросаются на очередную ветряную мельницу. А что, если сделать email лучше – задумываются они, прежде чем оформить идеи в RFC. Вот так, год за годом, email потихоньку меняется – оставаясь при этом ровно тем же, чем был всегда.

Email работает во многом благодаря принципу «не сломано – не чини» и децентрализованной природе – наследию вольных исследовательских лабораторий и университетов. Его чинят, когда действительно надо: прежде всего ради безопасности и глобальной пользы. Всё остальное – приятное, но не необходимое – обсуждают и реализуют где-то на периферии, но до массового внедрения дело часто не доходит. Лучше держаться того, что работает, чем рисковать сломать почту или – что ещё хуже – её централизовать.

Поэтому массовое распространение получают именно небольшие правки:

• SMTP давно пора прибрать: RFC 5321bis на 44-й редакции «сводит воедино, обновляет и уточняет» передачу писем – но принципиально ничего не меняет.

• IMAP ждёт обновления: ранний черновик от Fastmail хочет собрать воедино горстку расширений – серверный поиск, сжатие, перенос писем одной командой, команду NOTIFY для push-уведомлений. Всё это приятные мелочи, ради которых сегодня приходится городить обходные пути.

• Безопасность. ARC (Authenticated Received Chain) начинался в 2019 году как экспериментальный RFC и был быстро внедрён в Gmail и Outlook – а теперь его хотят влить в следующую версию DKIM. RFC 9788 несёт шифрование в заголовки, 8997 и 8689 ужесточают требования к TLS, а DMARCbis обновляет DMARC (который и сам-то пока лишь предложенный стандарт).

Тут подкрутили, там подлатали – и email потихоньку модернизируется, точно корабль Тесея, что цепляется за свой первоначальный киль. Обновления безопасности будут проталкивать по мере надобности – скорее всего, задолго до полной стандартизации. Крупные изменения будут внедрять там, где нужно, – особенно небольшие игроки, которым приходится тащить меньше легаси. А сами почтовые приложения продолжат экспериментировать с новыми интерфейсами и фичами на базе ИИ – а под капотом всё это будут крутить те же старые добрые SMTP и IMAP.

Так email и будет плыть себе дальше – в своей прекрасной простоте, оставаясь актуальным и кроссплатформенным вот уже больше полувека с момента, когда его придумали.

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

Cloud4U предоставляет корпоративную почту на базе Microsoft Exchange в облаке: Outlook, календарь и задачи, работа по MAPI, IMAP, POP3 и через веб (OWA), встроенный антиспам и антивирус, автобэкап и синхронизация с Active Directory. Миграцию ящиков, календарей и контактов инженеры берут на себя, а первый месяц – бесплатно.

Для новых клиентов с Хабра — скидка 20% по промокоду HABR20, подробности на странице акции.