Электронная почта (e-mail)

Названия

Помимо названия "электронная почта" в русском письменном и устном языках используются и другие, являющиеся в большинстве калькой и/или огрублением английского названия:

• имейл, мейл (транскрипция с английского).^[1]
• е-мейл, емейл, емайл (различные буквенные кальки с английского)
• мыло (в просторечии, от английского "мейл")

Правильное написание пока не зафисированно в словарях. Справочное бюро Грамота.ру указывает, что Е. Ваулина в словаре «Мой компьютер» предлагает писать e-майл и е-мэйл, но замечает, что такое написание не соответствует литературной норме, в то же время, в другом ответе советуют писать e-mail латиницей.^[2]

Показатели использования

В течение 2010 года интернет-пользователи отправили друг другу 107 триллионов электронных писем, большая часть которых была спамом. Об этом говорится в отчете со статистикой интернета за 2010 год от компании Pingdom.

В среднем, за день пользователи пересылали через Сеть 294 млрд писем. Всего по всему миру специалисты Pingdom насчитали 1,88 млрд пользователей электронной почты. При этом, за год их число выросло на 480 млн человек. Количество email-аккаунтов составило 2,9 млрд. Из 107 триллионов писем, отправленных за год, 89,1% были спамом.

Почтовые сервисы

• Каталог решений и проектов Почтовый сервер на TAdviser

Почтовые сервисы в России

Сервисы email-маркетинга в России

Основная статья: Сервисы email-маркетинга в России

2023: Названы самые популярные почтовые домены в России

Более четверти подписчиков (25,32%) электронных почтовых рассылок используют электронную почту с иностранным доменом. Такие данные в середине сентября получили аналитики сервиса email-рассылок UniSender. Для получения выводов компания провела анализ данных 1,5 млрд писем, отправленных через сервисы компании за 2020–2023 гг.

Лидером среди иностранных доменов с огромным преимуществом является gmail.com – им пользуются 24,06% пользователей. Кроме этого, россияне используют почтовые адреса на доменах iCloud и hotmail.com, но они составляют менее 1% от рынка.

25,32% подписчиков электронных почтовых рассылок используют электронную почту с иностранным доменом

При этом 61,4% рассылок отправлялись на российские почтовые домены. Лидером среди них является mail.ru – им пользуются почти 39% потребителей рассылок. 12,6% рынка приходится на почтовый домен Яндекса yandex.ru. Другими доменами, которыми пользуются россияне, Unisender назвал bk.ru, list.ru, inbox.ru, rambler.ru и ya.ru. Остальные рассылки приходили на корпоративную почту.

Кроме этого, Unisender выяснили, что две трети email-адресов (68,45%) находятся в зоне .ru, а оставшаяся часть пользователей (31,55%) в других доменных зонах com, net, by, de и т. д.

31 июля президент России Владимир Путин подписал закон, запрещающий регистрацию на российских сайтах с использованием иностранных электронных почтовых сервисов. С 1 декабря россияне смогут регистрировать почтовые ящики только по номеру телефона российского оператора связи, через портал «Госуслуг» или Единую биометрическую систему (ЕБС), а также с помощью российских информсистем, например, VK.Метавселенная ВДНХ 2.5 т

Как отмечает директор РАЭК Сергей Гребенников, многие россияне изначально регистрировали почтовые ящики в российских доменах, а иностранные домены типа gmail.com использовали для иностранных рассылок.^[3]

2013

* Данные TNSWebIndex, Май 2013 г. Вся Россия, 12-64 лет.

Почтовые сервисы в мире

Основная статья: Почтовые веб-сервисы (мировой рынок)

Новости

2023

Количество электронных писем в РФ за 5 лет выросло вдвое

В середине июля 2024 года стало известно о том, что за последние пять лет количество электронных писем, которыми обмениваются россияне, увеличилось в два раза. Об этом свидетельствует исследование российского Email-сервиса Unisender, приуроченное ко Дню российской почты.

Как сообщают «Известия», Unisender проанализировал 40 млрд писем с 2019 года, что составляет около трети всех рассылок в России за этот период. По данным сервиса, в период пандемии активность рассылок практически не изменилась, а по сравнению с 2019 годом даже несколько снизилась, так как пользователи на карантине отдавали предпочтение мессенджерам и социальным сетям. Однако ситуация кардинально изменилась в последующие годы.

𝓲

Unsplash

В 2022 году, после блокировки популярных социальных сетей и отключения рекламных возможностей в Google и YouTube, многие компании перешли на использование электронной почты. Количество рассылок резко возросло: с чуть более 100 тыс. в 2021 году до 130 тыс. в 2022-м и 180 тыс. в 2023 году. Особенно популярными email-рассылки стали среди предпринимателей и блогеров.

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

В Email-сервисе Unisender прогнозируют, что в 2024 году и последующие несколько лет прирост рассылок не остановится, но станет более плавным – примерно на 5% ежегодно. Развитие технологий машинного обучения, таких как ML-модели, помогает почтовым сервисам минимизировать получение пользователями нежелательных писем.^[4]

Власти Якутии перестали принимать электронные письма с ящиков Gmail и Proton

Власти Якутии ввели запрет на получение писем через почтовые домены Gmail и Protonmail на почтовые адреса доменов органов государственной власти. Об этом 4 декабря 2023 года сообщается на странице в соцсети «ВКонтакте» управления ЗАГС при региональном правительстве. Подробнее здесь.

Компании в России смогут использовать электронную почту в качестве своего адреса

В октябре 2023 года в Госдуму внесен законопроект об использовании электронной почты в качестве юридического адреса. Инициативу разработали депутаты от фракции «Новые люди» — Владислав Даванков, Александр Демин, Антон Ткачев и член фракции «Единая Россия» Антон Немкин.

Предполагается, что после принятия соответствующих поправок в Гражданский кодекс (ГК) предприниматели смогут использовать электронную почту в качестве адреса и указывать ее при регистрации бизнеса. Так, в статье 54 ГК закрепят возможность компаниям указывать в ЕГРЮЛ адрес электронной почты в качестве своего адреса в пределах местонахождения. А в статье 52 ГК – для того, чтобы юридическое лицо могло использовать адрес электронной почты в качестве своего адреса, сведения об этом должны быть прописаны в его уставе, учредительном договоре или федеральном законе.

Предприниматели смогут использовать электронную почту в качестве адреса и указывать ее при регистрации бизнеса

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

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

Одновременно предлагается внести поправки в закон о регистрации юрлиц, подразумевающие, что такой адрес электронной почты формируется на портале госуслуг в порядке, установленном Правительством. Сведения об адресе и пароли доступа направляются юридическому лицу после его государственной регистрации.^[5]

2020: Власти РФ одобрили законопроект о блокировке электронной почты и мессенджеров

28 января 2020 года стало известно, что Правительство РФ подготовило положительный проект официального отзыва на законопроект сенатора Андрея Клишаса о блокировке опасных переписок по электронной почте. Законопроект будет поддерживаться властями при условии его доработки. Подробнее здесь.

2019

Минкомсвязи не поддержало инициативу по блокировке электронной почты и мессенджеров

8 ноября 2019 года стало известно, что Министерство цифрового развития, связи и массовых коммуникаций РФ не поддержало законопроект о блокировке электронной почты за распространение незаконной информации. Подробнее здесь.

В РФ может быть введена блокировка электронной почты пользователей

9 октября 2019 года стало известно, что в России может быть введена блокировка пользователей сервисов электронной почты и мессенджеров, занимающихся распространением запрещенной информации. Подробнее здесь.

История

1965

Появление электронной почты можно отнести к 1965 году, когда сотрудники Массачусетского технологического института (MIT) Ноэль Моррис и Том Ван Влек написали программу MAIL для операционной системы CTSS (Compatible Time-Sharing System), установленную на компьютере IBM 7090/7094.

Общее развитие электронной почты шло через развитие локального взаимодействия пользователей на многопользовательских системах. Пользователи могли, используя программу mail (или её эквивалент), пересылать друг другу сообщения в пределах одного мейнфрейма (компьютера). Следующий шаг был в возможности переслать сообщение пользователю на другой машине — для этого использовалось указание имени машины и имени пользователя на машине. Адрес мог записываться в виде foo!joe (пользователь joe на компьютере foo). Третий шаг для становления электронной почты произошёл в момент появления передачи писем через третий компьютер. В случае использования UUCP адрес пользователя включал в себя маршрут до пользователя через несколько промежуточных машин (например, gate1!gate2!foo!joe — письмо для joe через машину gate1, gate2 на машину foo). Недостатком такой адресации было то, что отправителю (или администратору машины, на которой работал отправитель) необходимо было знать точный путь до машины адресата.

После появления распределённой глобальной системы имён DNS, для указания адреса стали использоваться доменные имена — user@example.com — пользователь user на машине example.com. Одновременно с этим происходило переосмысление понятия «на машине»: для почты стали использоваться выделенные сервера, на которые не имели доступ обычные пользователи (только администраторы), а пользователи работали на своих машинах, при этом почта приходила не на рабочие машины пользователей, а на почтовый сервер, откуда пользователи забирали свою почту по различным сетевым протоколам (среди распространённых на настоящий момент — POP3, IMAP, MAPI, веб-интерфейсы). Одновременно с появлением DNS была продумана система резервирования маршрутов доставки почты, а доменное имя в почтовом адресе перестало быть именем конкретного компьютера и стало просто почтовым доменом, за обслуживание которого могли отвечать многие сервера (возможно, физически размещённые на разных континентах и в разных организациях).

Кроме того, существовали (и существуют по настоящий момент) и другие системы электронной почты (некоторые из них существуют и сейчас), как-то Netmail в сети FidoNET, X.400 в сетях X.25. Доступ к ним из интернет и обратно осуществляется через почтовый шлюз. Для маршрутизации почты в сетях X.25 в DNS предусмотрена специальная ресурсная запись c соответствующим названием X25 (код 19).

Современная архитектура (SMTP)

Общепринятым в мире протоколом обмена электронной почтой является SMTP Simple Mail Transfer Protocol - Простой протокол передачи почты (привет, протокол передачи почты). В общепринятой реализации он использует DNS для определения правил пересылки почты (хотя в частных системах, вроде Microsoft Exchange, SMTP может действовать исходя из информации из других источников).

В различных доменах настроены свои, независимые друг от друга, почтовые системы. У каждого почтового домена может быть несколько пользователей. (Однако, фактически, может быть так, что одна организация или персона владеет многими доменами, которые обслуживаются (физически) одной почтовой системой). Почта передаётся между узлами с использованием программ пересылки почты (привет) (Такими, как, например, sendmail, exim4, postfix, Microsoft Exchange Server, Lotus Domino и т. д.). Поведение систем при связи друг с другом строго стандартизировано, для этого используется протокол SMTP (и соблюдение этого стандарта, наравне с всеобщей поддержкой DNS всеми участниками, является основой для возможности связи «всех со всеми» без предварительных договорённостей). Взаимодействие почтовой системы и пользователей, в общем случае, никак не регламентируется и может быть произвольным, хотя существуют как открытые, так и закрытые (завязанные на ПО конкретных производителей) протоколы взаимодействия между пользователями и почтовой системой. Программа, работающая в почтовой системе и обслуживающая пользователей, называется MDA (привет, агент доставки почты). В некоторых почтовых системах MDA и MTA могут быть объеденены в одну программу, в других системах могут быть разнесены в виде разных программ или вообще выполняться на различных серверах. Программа, с помощью которой пользователь осуществляет доступ, называется MUA, хотя, в случае, например, веб-интерфеса, может и отсутствовать.

Внутри заданной почтовой системы (обычно находящейся в рамках одной организации) может быть множество почтовых серверов, выполняющих как пересылку почты внутри организации, так и другие, связанные с электронной почтой задачи: фильтрацию спама, проверку вложений антивирусом, обеспечение автоответа, архивация входящей/исходящей почты, обеспечение доступа пользователям различными методами (от POP3 до ActiveSync). Взаимодействие между серверами в рамках одной почтовой системы может быть как подчинено общим правилам (использование DNS и правил маршуртизации почты с помощью протокола SMTP), так и следовать собственным правилам компании (используемого программного обеспечения).

Релеи

DNS позволяет указать в качестве принимающего сервера (MX-запись) любой узел интернета, не обязательно являющийся частью доменной зоны домена получателя. Это может использоваться для настройки релеинга (пересылки) почты через третьи сервера. Сторонний сервер (например, более надёжный, чем сервера пользователя) принимает почту для домена пользователя и пересылает его на почтовые сервера пользователя как только появляется возможность. Исторически, контроля за тем, «кому пересылать» почту не было (или этому не придавали должного значения), и сервера без подобного контроля передавали почту на любые домены. Такие сервера называются открытыми релеями (в настоящее время новые открытые релеи появляются в основном из-за ошибок в конфигурировании сервера).

Для своих пользователей сервера почтовой системы являются релеями (пользователи отправляют почту не на сервера почтовой системы адресата, а на «свой» почтовый сервер, который передаёт письма далее). Во многих сетях провайдеров интернета возможность отправлять письма по протоколу SMTP за пределы сети закрыта (из-за использования этой возможности троянами, вирусами). В этом случае провайдер предоставляет свой SMTP-сервер, через который и направляется вся почта за пределы сети. Открытым релеем при этом считается такой релей, который не проверяет, является ли пользователь «своим» (проверка может осуществляться как на основании адреса пользователя, так и на основании идентификации паролем/сертификатом).

Маршрутизация почты

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

Если сеть имеет различные DNS-сервера (например, внешние — в интернете, и локальные — в собственных пределах), то возможна ситуация, когда «внутренние» DNS-сервера в качестве наиболее приоритетного получателя указывают на недоступный в интернете сервер, куда и перенаправляется почта с релея, указанного как узел-получатель для интернета. Подобное разделение позволяет осуществлять маршрутизацию почты по общим правилам между серверами, не имеющими выхода в интернет.

В случае Microsoft Exchange, для маршрутизации почты между несколькими серверами внутри органзации используется информация о получателях из Active Directory. Версии Microsoft Exchange 2000, 2003 используют понятие группа маршрутизации (и задаваемые вручную соединители между группами), начиная с Exchange 2007 маршрутизация осуществляется исходя из информации о топологии Active Directory (т.е. маршрутизация осуществляется согласно настройкам репликации между узлами Active Directory)^[6]

Почтовый сервер Proofpoint Sendmail поддерживает файл конфигурации mailertable, позволяющий задать правила пересылки почты минуя DNS^[7].

Структура письма

Электронное письмо состоит из следующих частей:

• Заголовков SMTP-протокола, полученных сервером. Эти заголовки могут включаться, а могут и не включаться в тело письма в дальнейшем, так что возможна ситуация, когда сервер обладает большей информацией о письме, чем содержится в самом письме (так, например, поле RCPT TO указывает получателя письма, при этом в самом письме получатель может быть не указан). Эта информация передаётся за пределы сервера только в рамках протокола SMTP, и смена протокола при доставке почты (например, на узле-получателе в ходе внутренней маршрутизации) может приводить к потере этой информации.
• Самого письма (в терминологии протокола SMTP - 'DATA'), которое в свою очередь состоит из следующих частей, разделённых пустой строкой:
• Заголовков письма. В письме указывается служебная информация и пометки почтовых серверов, через которые прошло письмо, пометки о приоритете, указание на адрес и имя отправителя и получателя письма, тема письма и другая информация.
• Тела письма. В теле письма находится, собственно, текст письма. Согласно стандарту, в теле письма могут находиться только символы ASCII. Поэтому при использовании национальных кодировок, различных форм представления информации (HTML, RTF, бинарные файлы) текст письма кодируется по стандарту MIME и не может быть прочитан человеком без использования декодера или почтового клиента.

Заголовок SMTP

Заголовок SMTP содержит в себе следующую информацию:

• имя отправляющего узла (не имя отправителя, а имя сервера или компьютера пользователя, который обратился к серверу) - параметр сообщения HELO/EHLO, обычно дополняющийся "объективной" информацией самим сервером (HELO может содержать произвольное имя, а IP отправителя подделать существенно сложнее), по IP-адресу осуществляется поиск PTR-записи в DNS, всё это вместе позволяет идентифицировать отправителя на сетевом уровне (и в реальности часто используется для проверки надёжности отправителя с помощью чёрных/белых списков, в том числе через интернет - см RBL).
• Поле "MAIL FROM:", содержащее емейл адрес отправителя. Адрес может быть произвольным (в т.ч. с несуществующих доменов, однако этот адрес может так же проверяться при первичной проверке на спам).
• Поле "RCPT TO:" - наиболее важное поле для доставки почты, содержит электронный адрес получателя. Большинство почтовых систем в случае возможности проверяет, существует ли пользователь и может отказаться принимать почту, если пользователь, указанный в RCPT TO не сущесвует.

Заголовок письма

Заголовок письма описывается стандартами RFC:

• RFC 2076 - Common Internet Message Headers (общепринятые стандарты заголовков сообщений), включает в себя информацию из других RFC: RFC 822, RFC 1036, RFC 1123, RFC 1327, RFC 1496, RFC 1521, RFC 1766, RFC 1806, RCC 1864, RFC 1911).
• RFC 4021 - Registration of Mail and MIME Header Fields (регистрация почты и поля заголовков MIME).

Заголовок отделяется от тела письма пустой строкой. Заголовок используется для журналирования прохождения письма и служебных пометок (иногда строки журналирования и пометки называются кладжами). В Microsoft Outlook этот заголовок называется "Заголовки Интернет" (подразумевается, что каждая строчка - отдельный заголовок). В заголовке обычно указываются: почтовые серверы, через которые прошло письмо (каждый почтовый сервер добавляет информацию о том, от кого он получил это письмо), информацию о том, похоже ли это письмо на спам, информацию о проверке антивирусами, уровень срочности письма (может меняться почтовыми серверами). Так же в заголовке обычно пишется программа, с помощью которой было создано письмо. Чаще всего почтовые клиенты скрывают заголовки от пользователя при обычном использовании почтовой системой, но предоставляют возможность увидеть заголовки, если возникает потребность в более детальном анализе письма. В случае, если письмо из SMTP формата конвертируется в другой формат (например, в Microsoft Exchange 2007 письма конвертируются из SMTP-формата в MAPI), то заголовки сохраняются отдельно, для возможности диагностики.

Заголовки добавляются снизу вверх (т.е. каждый раз, когда к сообщению нужно добавить заголовок, он дописывается первой строкой, перед всеми предыдущими).

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

Наиболее часто используемые заголовки

• Return-Path (RFC 821, RFC 1123) — обратный адрес. Может отличаться от MAIL FROM. (т.е. обратный адрес может быть указн отличным от адреса отправителя).
• Received (RFC 822, RFC 1123) — строчка журналирования прохождения письма. Каждый почтовый сервер (MTA) помечает процесс обработки этим сообщением. Если сообщение проходит через несколько почтовых серверов (обычная ситуация), то новые сообщения дописываются над предыдущими (и журнал перемещения читается в обратном порядке, от ближайшего узла к самому дальнему).
• MIME-Version (RFC 1521) — версия MIME, с которым это сообщение создано. Поскольку сообщение создаётся раньше всех остальных событий с письмом, то этот заголовок обычно самый первый (т.е. последний в списке).
• From: (RFC 822, RFC 1123, RFC 1036) — Имя и адрес отправителя (именно в этом заголовке появляется текстовое поле с именем отправителя). Может не совпадать с return-path и даже не совпадать с заголовком SMTP MAIL FROM:.
• Sender: (RFC 822, RFC 1123) - Отправитель письма. Добавлено для возможности указать, что письмо от чьего-то имени (from) отправлено другой персоной (например, секретаршей от имени начальника). Некоторые почтовые клиенты показывают сообщение при наличии sender и from как "сообщение от 'sender' от имени 'from'". Sender является информационным заголовком (и так же может отличаться от заголовка SMTP MAIL FROM).
• To: (RFC 822, RFC 1123) — Имя и адрес получателя. Может содержаться несколько раз (если письмо адресовано нескольким получателям). Может не совпадать с полем SMTP RCPT TO.
• cc: (RFC 822, RFC 1123) — (от привет). Содержит имена и адреса вторичных получаетелей письма, к которым направляется копия.
• bcc: (RFC 822, RFC 1123) - (от привет). Содержит имена и адреса получателей письма, чьи адреса не следует показывать другим получателям. Это поле обычно обрабатывается почтовым сервером (и приводит к появлению нескольких разных сообщений, у которых bcc содержит только того получателя, кому фактически адресовано письмо). Каждый из получаетелей не будет видеть в этом поле других получателей из поля bcc.
• Reply-To: (RFC 822, RFC 1036) - имя и адрес, куда следует адресовать ответы на это письмо. Если, например, письмо рассылается ботом, то в качестве Replay-To будет указан адрес персоны, готовой принять ответ на письмо.
• Message-ID: (RFC 822, RFC 1036) - уникальный идентификатор сообщения. Состоит из адреса узла-отправителя и номера (уникального в пределах узла). Алгоритм генерации уникального номера зависит от сервера/клиента. Выглядит примерно так: AAB77AA2175ADD4BACECE2A49988705C0C93BB7B4A@exapmle.com. Вместе с другими идентификаторами используется для поиска прохождения конкретного сообщения по журналам почтовой системы (почтовые системы фиксируют прохождение письма по его Message-ID) и для указания на письмо из друхих писем (используется для группировки и построения цепочек писем). Обычно создаётся первым почтовым сервером (MTA) в момент принятия почты от пользователя.
• In-Reply-To: (RFC 822) - указывает на Message-ID, для которого это письмо является ответом (с помощью этого почтовые клиенты могут легко выстраивать цепочку переписки - каждый новый ответ содержит Message-ID для предыдущего сообщения).
• Subject: (RFC 822, RFC 1036) - тема письма.
• Date: (RFC 822, RFC 1123, RFC 1036) - дата написания письма.
• Content-Type: (RFC 1049, RFC 1123, RFC 1521, RFC 1766) - тип содержимого письма. С помощью этого поля указывается тип (HTML, RTF, Plain text) содержимого письма и кодировка, в которой создано письмо (см ниже про кодировки).

Помимо стандартных, почтовые сервера (и роботы по обработки почты) могут добавлять свои собственные заголовки, начинающиеся с "X-" (например, "X-MyServer-Note-OK" или "X-Spamassasin-Level").

Тело письма

Тело письма отделяется от заголовка пустой строкой, а заканчивается (согласно стандартам SMTP Simple Mail Transfer Protocol - Простой протокол передачи почты) строчкой, состоящей из единственной точки (и символа перевода строки). Часть почтовых клиентов (например, Thunderbird) показывают эту точку, часть нет. В не-smtp стандартах формат письма зависит от стандарта системы (например, MAPI), но перед "выходом" письма за пределы MAPI-совместимой системы (например, перед пересылкой через Интернет) обычно приводится к SMTP-совместимому виду (иначе маршрутизация письма была бы невозможной, так как стандартом передачи почты в Интернете является SMTP).

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

Цепочки писем

Благодаря наличию в письме уникального идентификатора, а так же тому, что подавляющее большинство почтовых клиентов при ответе на письмо копируют его идентификатор в поле "In-Reply-To" ("в ответ на"), появляется возможность достоверной группировки писем по цепочке (привет). В разных почтовых клиентах это реализовано по разному, например, Microsoft Outlook позволяет найти все связанные с заданным письма; веб-интерфейс gmail группирует сообщения на основании данных о цепочке в единый объект. Некоторые почтовые клиенты (например, mutt) позволяют структурировать цепочки (образующиеся обычно в почтовых рассылках, когда в беседе участвует много подписчиков) в форме дерева (вопрос породил несколько ответов, на каждый из которых дали комментарий - это сформировало несколько ветвей дерева). Так же такие клиенты обычно умеют принудительно резать цепочки при смене темы сообщения (считая, что смена темы сообщения означает новое обсуждение, хотя, быть может, и вызванное предыдущей беседой).

Почтовые рассылки

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

• Почтовые рассылки — письмо от одного адреса с одинаковым (или меняющимся по шаблону) содержимым, рассылаемое подписчикам рассылки. Технически может быть организовано как отправка множества писем (используется при шаблонных письмах) или как отправка письма с множеством получаетелей (в полях TO, CC, BCC). Для управления крупными почтовыми рассылками (более 10-50 абонентов) используются специализированные программы (например, mailman). Правильно организованная почтовая рассылка должна контролировать возврат писем (сообщения о невозможности доставить письмо) с исключением недоступных адресатов из списка рассылки, позволять подписчикам отписываться от рассылок. Нежелательные почтовые рассылки называются спамом и существенно осложняют функционирование почтовых систем.
• Группы переписки — специализированный тип почтовой рассылки, в которой письмо на адрес группы (обычный почтовый адрес, обработкой почты которого занимается специализированная программа) рассылается всем участникам группы. Является аналогом новостных конференций, эхоконференций. Правильно настроенная почтовая рассылка должна контролировать циклы (два робота рассылок, подписанные друг на друга способны создать бесконечный цикл пересылки писем), ограничивать список участников рассылки, имеющих право на помещение сообщения, выполнять прочие требования к почтовой рассылке.

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

Примеры программ управления рассылками:

• mailman
• Sympa
• Majordomo

Спам

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

По данным компании Pingdom, из 107 триллионов писем, отправленных за 2010 год, 89,1% были спамом. Для борьбы со спамом были разработаны различные механизмы (чёрные списки отправителей, серые списки (требующие повторного обращения почтового сервера для отправки), контекстные фильтры). Одним из последствий внедрения средств борьбы со спамом стала вероятность "ошибочного положительного" решения относительно спама (часть писем, не являющихся спамом, стала помечаться как спам). В случае агрессивной антиспам-политики (уничтожение писем, кажущихся спамом, в автоматическом режиме без уведомления отправителя/получателя) это приводит к труднообнаружимым проблемам с прохождением почты (т.к. сообщения удаляются или проходят в зависимости от эвристических алгоритмов).

• Статья Спам
• Каталог продуктов и проектов ИБ - Антиспам
• Статья Антиспам технологии

Электронная почта по модели SaaS

SaaS-решения в области электронной почты – это тот базовый сервис, который работает в компаниях любого масштаба. Одно из интересных предложений – это комплект из Microsoft Hosted Exchange и Symantec Hosted Email Security.

Преимущества для клиента, который будет работать по модели SaaS, вполне заметны – это быстрое внедрение, низкая стоимость решения за счет отсутствия затрат на приобретение серверного оборудования и программного обеспечения, а также отсутствие необходимости расширять собственную ИТ-инфраструктуру для обслуживания решений. Базовая стоимость «входного билета» для компаний с числом пользователей до 24 составит 300 руб. в месяц, дальше – чем больше, тем дешевле (если больше ста аккаунтов – уже 245 руб.). За это компания получит 3 Гб места на каждый почтовый ящик, настройку сервиса, интеграцию как с AS&AV-сервисами, так и другим ПО компании Microsoft, обучение пользователей и доступ в call-центр для решения всех технических вопросов. Аналогичная ситуация и с Symantec Hosted Email Security, которое защитит корпоративную электронную почту от спама, вирусов и другого нежелательного содержимого – его стоимость составит 80 руб. за каждого пользователя в месяц.

Эра e-mail подходит к концу?

До поры до времени Facebook на вашем рабочем месте может быть запрещен, но все больше компаний предоставляют своим сотрудникам функции чатов, постов и комментариев в корпоративных социальных сетях (Enterprise Social Software, ESS). Такие платформы совместной работы как Cisco Quad, Yammer, Jive, Traction Software, Socialtext, SocialCast, Salesforce.com Chatter, WizeHive (и десятки других) дают сотрудникам возможность обсуждать идеи, вместе работать над документами, рассылать новости и задавать вопросы с помощью постов, чатов, микроблогов и форумов. Некоторые из перечисленных приложений – например, Cisco Quad – включают в себя функции "голос поверх IP" (VoIP) для поддержки голосовых и видеоконференций в реальном времени, а также мобильные приложения, поддерживающие совместную работу в мобильном и удаленном режимах.

• Социальные сети (рынок России)
• Социальные сети (мировой рынок)

Впрочем, давайте зададим себе вопрос: действительно ли корпоративные социальные сети помогают компаниям повышать производительность труда и улучшать финансовые показатели? По данным аналитической компании Gartner, в 2011 году затраты на корпоративные социальные приложения в мировом масштабе могут составить 770 млн долларов США, что на 16 процентов больше, чем годом раньше (этот показатель не включает средства ESS, используемые для взаимодействия с заказчиками и внешними партнерами). Это капля в море по сравнению с затратами на традиционные программные средства для совместной работы, такие как электронная почта (e-mail), системы обмена документами, средства календарной работы и веб-конференций. Данный рынок несколько аморфен, но, согласно некоторым отраслевым отчетам, только лишь в США его объем составляет около 5 млрд долларов в год.

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

Студенты и преподаватели факультета MBA Дюкского университета (Duke University, США) используют решение Cisco Quad для совместной работы над проектами в разных часовых поясах. Студенты из США, Великобритании, Дубая, Индии, Китая, России используют Cisco Quad для формирования виртуальных рабочих групп, поиска людей с общими интересами, обмена файлами и видеоматериалами со студентами, работающими над схожими проектами, и мгновенной организации видеоконференций и чатов. Преподаватели используют эту платформу для передачи лекций в реальном времени через вебкасты и для предоставления студентам учебных материалов в видеоклипах и интерактивных форматах с широкой функциональностью.

Хотя многие преимущества ESS трудно формализовать (сотрудники чувствуют себя комфортнее? рабочие отношения стали прочнее? совместная работа получила большее распространение?), эти технологии имеют массу ощутимых достоинств. В одной из групп разработчиков после внедрения корпоративных социальных сетей количество сообщений электронной почты сократилось на 38 процентов, а средний размер таких сообщений уменьшился на 43 процента. Более того, с помощью ESS менеджеры по продуктам стали еженедельно экономить 7,8 часа, а инженеры - 5,4 часа. Высвободившееся время дало им возможность решать более важные задачи.

Тем не менее на пути распространения ESS немало препятствий. Одна из проблем – сопротивление сотрудников. Уже сегодня каждому сотруднику приходится использовать в среднем как минимум шесть "приложений для повышения производительности". Еще одно такое приложение в виде ESS – это уж слишком.

Перед ИТ-отделами встает другая проблема – необходимость интеграции корпоративных социальных сетей в существующую инфраструктуру. К концу 2011 года более половины предприятий в США и Европе внедрят корпоративные социальные технологии, но только единицы таких технологий «будут хотя бы удаленно соединены с бизнес-системами, приложениями и процедурами», утверждает автор опубликованного в апреле 2011 года независимого отчета исследовательской фирмы Forrester Research "Интеграция: новая задача корпоративных социальных продуктов" (Integration: The Next Frontier For Enterprise Social). "За исключением нескольких компаний-первопроходцев, – говорится в отчете, – нормой остаются изолированные, автономные социальные технологии".

Коммерческое использование

Пошаговое прохождение электронной почты от отправителя получателю (без использования proxy сервера):

1. Создание письма;
2. Соединение почтового клиента с SMTP Simple Mail Transfer Protocol - Простой протокол передачи почты-сервером отправителя;
3. Передача SMTP-серверу информации о том, кому предназначается почта и кто является отправителем;
4. Проверка SMTP-сервером корректности данных об адресате и отправителе и принятие письма (с заголовками и телом письма);
5. Постановка письма в очередь доставки;
6. DNS-запрос о почтовых серверах (MX-записи) для домена адресата;
7. Попытка соединения SMTP-сервера отправителя с почтовыми серверами адресата, имеющими наибольший приоритет. Если попытка неудачна, делаются ещё попытки соединения с резервными почтовыми серверами домена адресата;
8. Передача письма в случае удачного соединения с почтовым сервером домена адресата, либо постановка в очередь для попытки переслать письмо позже, в случае неудачи;
9. Прием SMTP-сервером домена адресата письма
10. Проверка письма на предмет его похожести на спам
11. Передача его модулю, который занимается хранением писем и выдачей их адресатам по протоколу POP3, IMAP или другим;
12. Соединение адресата с POP3 или IMAP сервером, аутентификация и получение письма адресатом.

Серверы электронной почты с числом учётных записей больше 10 млн

Протоколы передачи электронной почты

Популярные программы для работы с E-mail

См. также

Ссылки

• RFC 822 — Standard for ARPA Internet Text Messages
• RFC 2142 — Mailbox Names for Common Services, Roles and Functions
• RFC 2368 — The mailto URL scheme
• RFC 2822 — Internet Message Format

Примечания