Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

Почтовый ящик [1] (также электронный почтовый ящик , [1] почтовый ящик , ящик электронной почты , электронной почтовый ящик ) является местом , к которому электронные почтовые сообщения доставляются. Это эквивалент почтового ящика в почтовой системе.

Определения [ править ]

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

RFC 5321, [2] определяет адрес электронной почты как строку символов, которая идентифицирует пользователя, которому будет отправлена ​​почта, или место, в которое она будет депонирована. Термин « почтовый ящик» относится к этому хранилищу. В этом смысле термины почтовый ящик и адрес могут использоваться как синонимы.

RFC 5322 определяет почтовый ящик следующим образом: [3] Почтовый ящик принимает почту. Это «концептуальная сущность», которая не обязательно относится к файловому хранилищу. Это также служит примером того, что некоторые сайты могут распечатать почту на принтере и доставлять результат на стол адресата, как при традиционной передаче по факсу .

Доступ [ редактировать ]

Основная статья: Почтовый клиент

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

Доступ для чтения [ редактировать ]

Популярные клиент-серверные протоколы для получения сообщений:

  • Почтовый протокол (POP): метод, наиболее подходящий для чтения сообщений с одного клиентского компьютера. Обычно сообщения удаляются из почтового ящика сервера после получения. В любом случае, главная копия сообщения находится в локальном почтовом ящике.
  • Протокол доступа к сообщениям в Интернете (IMAP): предназначен для получения сообщений от нескольких клиентов путем удаленного управления почтовым ящиком сервера. Основные копии остаются на сервере, но копию можно сохранить локально.
  • Веб-почта через HTTP : сообщения отправляются в браузер пользователя в определяемом сервером формате. Мастер-копии остаются на сервере, возможно, в исходном формате, который можно загрузить.

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

Формат Интернет-сообщений, который в настоящее время определяется RFC 5322, восходит к 1982 году (RFC 822). Это то, что ожидают получить клиенты POP и IMAP.

Доступ для записи [ править ]

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

Квота размера [ править ]

У почтовых ящиков есть ограничение на размер, которое определяется либо неявно доступной памятью, либо после определения квоты для этого почтового ящика или его папок. Помимо административных мелочей, ограничения квот помогают предотвратить атаки с использованием электронных писем . [4]

Расширение IMAP для квот было стандартизовано в 1997 году [5].

Формат хранения [ править ]

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

  • mbox - это оригинальный метод хранения всех сообщений в одном файле,
  • Maildir - это новая спецификация, которая обеспечивает хранение всех сообщений в дереве каталогов с одним файлом для каждого сообщения.

Имена почтовых ящиков [ править ]

Основная статья: Адрес электронной почты

Имя почтового ящика - это первая часть адреса электронной почты, также известная как локальная часть ; то есть часть перед символом @ . Его формат формально указан в RFC 5322 и RFC 5321. Часто это имя пользователя получателя на почтовом сервере или в домене назначения.

Локальная часть может иметь длину до 64 символов и, теоретически, чувствительна к регистру. Он может состоять либо из последовательности допустимых символов (описанных ниже), либо из строки в кавычках, которая также может содержать пробелы и специальные символы. Используя расширение SMTPUTF8 для SMTP, также можно использовать символы, отличные от ASCII. [6] При создании новых имен почтовых ящиков необходим здравый смысл, чтобы избежать распространенных ошибок. По словам RFC 5321, очень осторожно вводить ограничения:

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

-  Джон Кленсин, RFC 5321.

Допустимые символы [ править ]

Следующие символы могут появляться в локальной части без кавычек:

  • Прописные и строчные буквы английского алфавита (a – z, A – Z) и последовательности UTF-8 при использовании SMTPUTF8
  • Цифры 0в9
  • Символы ! # $ % & ' * + - / = ? ^ _ ` { | } ~
  • Символ .(точка) при условии, что это не первый и не последний символ, а также при условии, что он не появляется два или более раз подряд (например, John..Doe @ example.com).

Зарезервированные имена [ править ]

Имена «почтмейстер», «злоупотребление» и другие соответствуют хорошо известным ролям и функциям и должны быть действительными. [7]

Известно, что некоторые имена вызывают проблемы, возможно, потому, что они конфликтуют с именами, используемыми внутри (некоторыми частями) почтового программного обеспечения, включая почтовые фильтры , или потому, что базовая система хранения подавляется ими. Существует ряд списков, например, на GitHub . [8] [9]

Ссылки [ править ]

  1. ^ a b ISO / IEC 2382: 2015
  2. ^ RFC 5321, Simple Mail Transfer Protocol , J. Klensin, The Internet Society (октябрь 2008 г.), раздел 2.3.11 ( Почтовый ящик и адрес )
  3. ^ RFC 5322, Формат сообщений Интернета , П. Резник (ред.), The Internet Society (октябрь 2008 г.), раздел 3.4 ( Указание адреса )
  4. ^ Ник Кристенсон; Тим Боссерман; Дэвид Бекемейер (9 декабря 1997 г.). «Высоко масштабируемая служба электронной почты с использованием открытых систем» . USENIX . Проверено 12 декабря 2015 года .Помимо аутентификации и местоположения почтового ящика, агент доставки почты также знает о квотах почтовых ящиков, которые мы налагаем на наших подписчиков. Если текущий размер почтового ящика превышает квоту для этого пользователя, значение по умолчанию - 10 МБ, то сообщение возвращается обратно в MTA с причиной «Пользователь npc, почтовый ящик заполнен». Помимо предотвращения злоупотребления ресурсами со стороны подписчиков, это также помогает смягчить возможные разрушительные последствия взлома почты злоумышленниками в Интернете. Мы считаем, что квота в 10 МБ довольно щедрая, особенно с учетом модема 28,8, использующего очень высокую скорость передачи данных и отсутствие узких мест в сети, можно ожидать, что на загрузку содержимого почтового ящика размером 10 МБ может уйти более часа.
  5. ↑ Джон Г. Майерс (январь 1997 г.). Расширение IMAP4 QUOTA . IETF . DOI : 10,17487 / RFC2087 . RFC 2087 .
  6. ^ Цзянькан Яо; Вэй МАО (февраль 2012 г.). «Расширение SMTPUTF8» . Расширение SMTP для интернационализированной электронной почты . IETF . сек. 3.2. DOI : 10,17487 / RFC6531 . RFC 6531 . Проверено 12 декабря 2015 года . CS1 maint: обескураженный параметр ( ссылка )
  7. ↑ Дэйв Крокер (май 1997 г.). Имена почтовых ящиков для общих служб, ролей и функций . IETF . сек. 3,4,5. DOI : 10,17487 / RFC2142 . RFC 2142 . Проверено 12 декабря 2015 года . CS1 maint: обескураженный параметр ( ссылка )
  8. ^ Кейси О'Хара (2011). «Список зарезервированных имен пользователей, чтобы избежать столкновения тщеславных URL-адресов с путями к ресурсам» . GitHub . Проверено 12 декабря 2015 года .
  9. ^ Майкл Махемофф (2011). «Список зарезервированных имен пользователей» .