Смотреть что такое "Электронная почта" в других словарях:

Названия

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

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

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

• в тексте (в смысле «способ связи») употребляют выражение «электронная почта» ;
• в списке контактов используют префикс «e-mail» (E-mail: [email protected]).

История

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

Текстовый интерфейс программы mail

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

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

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

Хронология

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

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

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

IMAP

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

Различия

Основываясь на работе протоколов можно разделить их по двум основным критериям:

• Производительность сервера - в данном случае, IMAP более требователен к ресурсам нежели POP3, так как вся работа по обработке почты (такая как поиск) ложится на плечи сервера, POP3 только передает почту клиенту;
• Пропускной способности канала - тут IMAP в выигрыше; POP3 передает тела всех писем целиком, тогда как IMAP - только заголовки писем, а остальное - по запросу.

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

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

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

• Заголовков SMTP-протокола, полученных сервером. Эти заголовки могут включаться, а могут и не включаться в письмо в дальнейшем, так что возможна ситуация, когда сервер обладает большей информацией о письме, чем содержится в самом сообщении. Так, например, поле RCPT TO указывает получателя письма, при этом в самом письме получатель может быть не указан. Эта информация передаётся за пределы сервера только в рамках протокола SMTP, и смена протокола при доставке почты (например, на узле-получателе в ходе внутренней маршрутизации) может приводить к потере этой информации. В большинстве случаев эта информация недоступна конечному получателю, который использует не-SMTP протоколы (POP3, IMAP) для доступа к почтовому ящику. Для возможности контролировать работоспособность системы эта информация обычно сохраняется в журналах почтовых серверов.
• Самого сообщения (в терминологии протокола SMTP - "DATA"), которое, в свою очередь, состоит из следующих частей, разделённых пустой строкой:
  • Заголовков (англ. headers ) письма, иногда называемых по аналогии с бумажной почтой конвертом (англ. envelope ). В заголовке указывается служебная информация и пометки почтовых серверов, через которые прошло письмо, пометки о приоритете, указание на адрес и имя отправителя и получателя письма, тема письма и другая информация. С термином «конверт» есть некоторая путаница, потому что в зависимости от ситуации «конвертом» называют либо заголовок письма, либо информацию, которой располагает SMTP-сервер после получения письма (так, например, в документации к почтовому серверу postfix, термин «конверт» используется в отношении SMTP-данных, включающих не только поля RCPT TO и MAIL FROM, но и IP-адрес отправителя, его строчка HELO и т. д.)
  • Тело письма. В теле письма находится, собственно, сообщение письма. Согласно стандарту, в теле письма могут находиться только символы 7-битного 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 , RFC 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) - (от англ. carbon copy ). Содержит имена и адреса вторичных получателей письма, к которым направляется копия.
• bcc: (RFC 822 , RFC 1123) - (от англ. blind carbon copy ). Содержит имена и адреса получателей письма, чьи адреса не следует показывать другим получателям. Это поле обычно обрабатывается почтовым сервером (и приводит к появлению нескольких разных сообщений, у которых bcc содержит только того получателя, кому фактически адресовано письмо). Каждый из получателей не будет видеть в этом поле других получателей из поля bcc.
• Reply-To: (