емайл

Как написать емайл в контакте

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

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

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

Названия

Если в Европе, Америке и др. регионах написание используются только два варианта e-mail и, реже, email (в марте 2011 года англоязычным СМИ рекомендуется писать сокращение от электронная почта как email, а не e-mail), то в русском языке присутствует значительная вариативность. Наиболее часто в кириллических текстах также используется e-mail, то есть написание латиницей без транслитерации (визуальное восприятие других форм написания хуже). Но можно встретить и другие написания:

электронная почта, почта
интернет-почта
электропочта
имейл, мейл (транскрипция с английского).
е-мейл, емейл, емайл (различные варианты транслитерации)
мыло, Емеля (в просторечии, от английского мейл)
электронка (в просторечии, сокращение от электронная почта)

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

Де-факто в официальных русскоязычных документах:

в тексте (в смысле способ связи) употребляют выражение электронная почта;
в списке контактов используют префикс e-mail (E-mail: user@domain.com).

История

Появление электронной почты можно отнести к 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 в сети Фидонет, X.400 в сетях X.25. Доступ к ним из сети Интернет и обратно осуществляется через почтовый шлюз. Для маршрутизации почты в сетях X.25 в DNS предусмотрена специальная ресурсная запись c соответствующим названием X25 (код 19).

1996 г., 4 июля (день Независимости США) - Начало коммерческого функционирования почтового сервиса Hotmail. Дата старта сервиса символизировала освобождение от интернет-провайдеров.
1997 г., 8 марта - Компания Yahoo! приобретает портал RocetMail один из первых бесплатных почтовых сервисов. Появление сервиса Yahoo! Mail.
1998 г., 15 октября - Заработала бесплатная электронная почта от Mail.Ru.
2000 г., 26 июня - Запущена Яндекс.Почта бесплатный почтовый сервис от компании Яндекс.

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

Общепринятым в мире протоколом обмена электронной почтой является SMTP (англ. простой протокол передачи почты). В общепринятой реализации он использует 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-запись самого узла) отбрасываются, а доставка осуществляется на первый отвечающий узел (узлы пробуются в порядке убывания приоритета). Если MX-запись для домена не найдена, то некоторые серверы могут пытаться доставлять почту по A-записи. Если же записи о домене нет, то формируется отлуп (сообщение о невозможности доставки). Это сообщение формируется с пустым полем отправителя, в поле Кому указывается отправитель исходного письма. Пустое поле отправителя позволяет защитить почтовые сервера от бесконечного хождения сообщений об ошибке между серверами если сервер обнаруживает, что не может доставить письмо с пустым обратным адресом, то он уничтожает его.

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

После попадания почты на конечный сервер, он осуществляет временное или постоянное хранение принятой почты. Существует две различные модели работы с почтой: концепция почтового ящика и хранилища почты. В концепции почтового ящика почта на сервере хранится временно, в ограниченном объёме (аналогично почтовому ящику для бумажной почты), а пользователь периодически обращается к ящику и забирает письма (то есть почтовый клиент скачивает копию письма к себе и удаляет оригинал из почтового ящика). На основании этой концепции действует протокол POP3.

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

В определённых условиях сервер хранения писем может быть настроен на поведение, подобное клиенту: такой сервер обращается к почтовому серверу по протоколу POP3 и забирает почту себе. Подобные решения используются обычно в малых организациях, в которых нет инфраструктуры для развёртывания полноценных почтовых серверов; в этом случае используется локальный сервер для хранения почты и почтовый сервер провайдера, предоставляющий услугу получения почты по POP3 (например, с помощью fetchmail). Основным недостатком подобного решения является задержка в доставке (так как забирающее почту ПО обращается на сервера с некоторой задержкой) например, POP3 connector из Exchange 2003 Server в составе Windows SBS не позволяет через интерфейс конфигурирования выставить интервал менее 15 минут.

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

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

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

Заголовок 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, RFC 1864, RFC 1911).
RFC 4021 Registration of Mail and MIME Header Fields (регистрация почты и поля заголовков MIME).

Заголовок отделяется от тела письма пустой строкой. Заголовок используется для журналирования прохождения письма и служебных пометок (иногда строки журналирования и пометки называются кладжами). В Microsoft Outloo этот заголовок называется Заголовки Интернет (подразумевается, что каждая строчка отдельный заголовок). В заголовке обычно указываются: почтовые серверы, через которые прошло письмо (каждый почтовый сервер добавляет информацию о том, от кого он получил это письмо), информацию о том, похоже ли это письмо на спам, информацию о проверке антивирусами, уровень срочности письма (может меняться почтовыми серверами). Также в заголовке обычно пишется программа, с помощью которой было создано письмо. Чаще всего почтовые клиенты скрывают заголовки от пользователя при обычном использовании почтовой системой, но предоставляют возможность увидеть заголовки, если возникает потребность в более детальном анализе письма. В случае, если письмо из 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) имя и адрес, куда следует адресовать ответы на это письмо. Если, например, письмо рассылается ботом, то в качестве Reply-To будет указан адрес персоны, готовой принять ответ на письмо.
Message-ID: (RFC 822, RFC 1036) уникальный идентификатор сообщения. Состоит из адреса узла-отправителя и номера (уникального в пределах узла). Алгоритм генерации уникального номера зависит от сервера/клиента. Выглядит примерно так: AAB77AA2175ADD4BACECE2A49988705C0C93BB7B4A@example.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-Mailer, X-MyServer-Note-OK или X-Spamassasin-Level).

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

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

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

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

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

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

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

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

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

mailman
Sympa
Majordomo

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

В настоящий момент существуют следующие модели коммерческого применения почтовых систем:

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

Спам разновидность почтовой рассылки с целью рекламы (часто нежелательной) того или иного товара или услуги, аналог бумажной рекламы, бесплатно распространямой по почтовым ящикам жилых домов. По мере роста популярности электронной почты, она (наравне с новостными группами usenet), начала использоваться для рассылки незапрошенных рекламных сообщений, аналогично тому, как раскидываются рекламные брошюры в обычные почтовые ящики. Однако, в отличие от существенной стоимости бумажной рассылки, отправка значительного количества (миллионов и миллиардов) сообщений практически ничего не стоит отправителю. Это привело к непропорциональному росту количества и размера рекламных рассылок (по некоторым данным, спам в настоящее время составляет 70-90 % от всех почтовых сообщений, то есть превысил объём полезной почтовой нагрузки в 2-10 раз). Для рассылки спама в настоящий момент активно используются все возможные технические ухищрения: открытые релеи, ремейлеры, прокси-серверы, бесплатные серверы электронной почты (допускающие автоматизацию отправки почты), ботнеты, поддельные сообщения о невозможности доставки.

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

Шифрование почты

Для шифрования почты в настоящий момент широко применяются два стандарта: S/MIME (использующий инфраструктуру открытых ключей) и Open PGP (использующий сертификаты со схемой доверия, группирующегося вокруг пользователя).

Ранее также существовали стандарты MOSS и PEM, но, из-за несовместимости друг с другом и неудобства использования, они не прижились.

Стандарты S/MIME и Open PGP позволяют обеспечить три вида защиты: защиту от изменения, неотзывную подпись и конфиденциальность (шифрование). Дополнительно, S/MIME третьей версии позволяет использовать защищённое квитирование (при котором квитанция о получении письма может быть сгенерирована успешно только в том случае, когда письмо дошло до получателя в неизменном виде).

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

Законодательное регулирование

MxA-классификация

В терминологии электронной почты выделяются следующие компоненты:

MTA (англ. агент пересылки почты) отвечает за отправку почты; чаще всего это почтовый сервер, но, в принципе, возможна реализация с отправкой почты через smart host.
MDA (англ. агент доставки почты) отвечает за доставку почты конечному пользователю.
MUA (англ. почтовый агент пользователя; в русской нотации закрепился термин почтовый клиент) программа, обеспечивающая пользовательский интерфейс, отображающая полученные письма и предоставляющая возможность отвечать, создавать, перенаправлять письма.
MRA англ. почтовый сервер, забирающий почту с другого сервера по протоколам, предназначенным для MDA.

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

Почтовые сервера обычно выполняют роль MTA и MDA. Некоторые почтовые сервера (программы) выполняют роль как MTA, так и MDA, некоторые подразумевают разделение на два независимых сервера: сервер-MTA и сервер-MDA (при этом, если для доступа к ящику используются различные протоколы например, POP3 и IMAP, то MDA в свою очередь может быть реализован либо как единое приложение, либо как набор приложений, каждое из которых отвечает за отдельный протокол).