· Return-Path: (RFC 821, RFC 1123) — адрес возврата в случае неудачи, когда невозможно доставить письмо по адресу назначения. Может отличаться от MAIL FROM и заголовков From:,Sender: или Reply-To:, но обычно совпадает с 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.

· Сc: (RFC 822, RFC 1123) — (от англ. carbon copy) содержит имена и адреса вторичных получателей письма, к которым направляется копия. Участвует в формировании поля SMTP RCPT TO, как и поле "To".

· Bcc: (RFC 822, RFC 1123) — (от англ. blind carbon copy) содержит имена и адреса получателей письма, чьи адреса не следует показывать другим получателям. Участвует в формировании поля SMTP RCPT TO, как поля "To" и "Cc", но отсутствует в отправляемом сообщении.

· Reply-To: (RFC 822, RFC 1036) — имя и адрес, куда следует адресовать ответы на это письмо. Если, например, письмо рассылается роботом, то в качестве Reply-To будет указан адрес почтового ящика, готового принять ответ на письмо.

· Message-ID: (RFC 822, RFC 1036) — уникальный идентификатор сообщения. Состоит из адреса узла-отправителя и номера (уникального в пределах узла). Алгоритм генерации уникального номера зависит от сервера/клиента. Выглядит примерно так: AAB77AA2175ADD4BACECE2A49988705C0C93BB7B4A@example.com. Вместе с другими идентификаторами используется для поиска прохождения конкретного сообщения по журналам почтовой системы (почтовые системы фиксируют прохождение письма по его Message-ID) и для указания на письмо из других писем (используется для группировки и построения цепочек писем). Обычно создаётся почтовым клиентом (MUA) в момент составления письма.

· 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) и кодировка, в которой создано письмо (см. ниже про кодировки).

· Return-Receipt-To: (RFC 2076) — E-Mail, куда почтовый сервер получателя должен отправить уведомление о доставке. В RFC 2076 упоминается в разделе "Not Internet standard", в силу этого может не поддерживаться серверами.

· Disposition-Notification-To: (RFC 3798) — E-Mail, куда почтовый клиент получателя должен отправить уведомление о доставке, если это разрешит пользователь (посредством настроек и т.п.).

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

Тело письм

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

В теле сообщения допускаются только печатные символы. Потому для целей передачи бинарной информации (картинок, исполняемых файлов и т.п.) применяются кодировки, приводящие данные с 7-битному виду — Base64 или UUE. Кроме того, в самом начале существования E-Mail ограничение было более жёстким — некоторые почтовые системы поддерживали только 7-битные сообщения. С целью работы с такими системами обычный текст, при наличии национальных символов, так же, может кодироваться в 7-битный вид. Для этого используются Base64 или Quoted-Printable. Однако, почтовые системы, которые могут работать только с 7-битными сообщениями сейчас, вряд ли существуют.

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

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

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

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

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

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

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

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

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

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

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

Спам

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

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

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

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

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

Федеральный закон № 152-ФЗ «О персональных данных».