Введение: Ошибка в матрице или архитектурная особенность почтовых сервисов?

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

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

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

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

Анатомия адреса электронной почты: Стандарты RFC и их интерпретация

Чтобы понять природу технологических сбоев при доставке корреспонденции, необходимо обратиться к первоисточникам — стандартам Internet Engineering Task Force (IETF). Базовые спецификации, описывающие структуру электронного письма, зафиксированы в документах серии RFC (Request for Comments), в частности RFC 5321 и RFC 5322. Согласно этим спецификациям, адрес электронной почты делится на две принципиальные части, разделенные символом собачки («@»): локальную часть (local-part) и доменное имя (domain).

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

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

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

Правило точек в Gmail: Как игнорирование символов порождает путаницу

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