Почтовый клиент

Пользовательский интерфейс почтового клиента Mozilla Thunderbird в операционной системе Linux

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

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

Получение сообщений из почтового ящика [ править ]

Как и большинство клиентских программ, почтовый клиент активен только тогда, когда пользователь запускает его. Обычно пользователь электронной почты (клиент) договаривается с удаленным сервером агента пересылки почты (MTA) для получения и хранения электронной почты клиента. MTA, используя подходящий агент доставки почты (MDA), добавляет сообщения электронной почты в хранилище клиента по мере их поступления. Удаленное почтовое хранилище называется почтовым ящиком пользователя . По умолчанию во многих системах Unix почтовый сервер хранит форматированные сообщения в mbox в домашнем каталоге пользователя.. Конечно, пользователи системы могут войти в систему и запустить почтовый клиент на том же компьютере, на котором размещены их почтовые ящики; в этом случае сервер фактически не является удаленным , кроме как в общем смысле.

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

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

В качестве альтернативы протокол доступа к сообщениям в Интернете (IMAP) позволяет пользователям хранить сообщения на сервере, помечая их соответствующим образом. IMAP предоставляет папки и подпапки, которыми могут пользоваться разные пользователи с возможно разными правами доступа. Обычно папки « Отправленные» , « Черновики» и « Корзина» создаются по умолчанию. IMAP имеет неактивное расширение для обновлений в реальном времени, обеспечивая более быстрое уведомление, чем опрос, когда возможны длительные соединения. См. Также раздел удаленных сообщений ниже.

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

Состав сообщения [ править ]

Почтовые клиенты обычно содержат пользовательские интерфейсы для отображения и редактирования текста. Некоторые приложения позволяют использовать внешний редактор программы.

Почтовые клиенты будут выполнять форматирование в соответствии с RFC 5322 для заголовков и тела и MIME для нетекстового содержимого и вложений. Заголовки включают поля назначения, To , Cc (сокращенно Carbon Copy ) и Bcc ( Blind калька ) и оригинатор поле из которых является автор данного сообщения (ы), Sender в случае , если есть больше авторов, и для ответа в случае, если ответы следует направлять в другой почтовый ящик. Чтобы лучше помочь пользователю с полями назначения, многие клиенты поддерживают одну или несколько адресных книг и / или могут подключаться кСервер каталогов LDAP . Для полей отправителя клиенты могут поддерживать разные идентификаторы.

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

Отправка сообщений на сервер [ править ]

Когда пользователь желает создать и отправить электронное письмо, почтовый клиент выполнит эту задачу. Почтовый клиент обычно настраивается автоматически для подключения к почтовому серверу пользователя, который обычно является либо MSA, либо MTA , двумя вариантами протокола SMTP . Почтовый клиент, использующий протокол SMTP, создает расширение аутентификации, которое почтовый сервер использует для аутентификации отправителя. Этот метод упрощает модульность и кочевые вычисления. Более старый метод заключался в том, что почтовый сервер распознавал IP-адрес клиента, например, потому что клиент находится на том же компьютере и использует внутренний адрес 127.0.0.1, или потому что IP-адрес клиента контролируется одним и тем же интернет-провайдером. который обеспечивает как доступ в Интернет, так и почтовые услуги.

Для настроек клиента требуется имя или IP-адрес предпочтительного сервера исходящей почты , номер порта (25 для MTA, 587 для MSA), а также имя пользователя и пароль для аутентификации, если таковые имеются. Существует нестандартный порт 465 для сеансов SMTP с шифрованием SSL , который многие клиенты и серверы поддерживают для обратной совместимости.

Шифрование [ править ]

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

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

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

Шифрование сеанса поиска электронной почты с помощью, например, SSL, может защитить обе части (аутентификация и передача сообщений) сеанса. ^[2]^[3]

В качестве альтернативы, если у пользователя есть SSH- доступ к своему почтовому серверу, он может использовать переадресацию портов SSH для создания зашифрованного туннеля, по которому можно будет получать свои электронные письма. ^[4]

Шифрование тела сообщения [ править ]

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

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

Электронная почта [ править ]

В дополнение к почтовым клиентам, работающим на настольном компьютере, есть клиенты, размещенные удаленно, либо как часть удаленной установки UNIX, доступной через telnet (т. Е. Через учетную запись оболочки ), либо размещенные в Интернете . Оба этих подхода имеют несколько преимуществ: они совместно используют возможность отправлять и получать электронную почту вне обычной базы пользователя с помощью веб-браузера или клиента telnet, что устраняет необходимость установки специального почтового клиента на устройстве пользователя.

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

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

Удаленные сообщения [ править ]

POP3 имеет возможность оставлять сообщения на сервере. Напротив, и IMAP, и веб-почта хранят сообщения на сервере в качестве своего метода работы, хотя пользователи могут делать локальные копии по своему усмотрению. Хранение сообщений на сервере имеет преимущества и недостатки. ^[5]

Преимущества [ править ]

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

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

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

Протоколы [ править ]

Популярные протоколы для получения почты включают POP3 и IMAP4 . Отправка почты обычно осуществляется по протоколу SMTP .

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

Большинство почтовых клиентов используют поле заголовка User-Agent ^[6] для идентификации программного обеспечения, используемого для отправки сообщения. Согласно RFC 2076, это обычное, но нестандартное поле заголовка. ^[^{оспаривается}^-^{обсудить}^]

RFC 6409, «Отправка сообщений для почты» , подробно описывает роль агента отправки почты .

RFC 5068 « Операции отправки электронной почты: требования к доступу и отчетности» содержит обзор концепций MTA, MSA, MDA и MUA. В нем упоминается, что « Поставщики доступа НЕ ДОЛЖНЫ блокировать пользователям доступ к внешнему Интернету через порт SUBMISSION 587 » и что « MUA ДОЛЖНЫ использовать порт SUBMISSION для отправки сообщений ».

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

Почтовые серверы и клиенты по соглашению используют номера портов TCP, указанные в следующей таблице. Для MSA, IMAP и POP3 в таблице также указаны метки, которые клиент может использовать для запроса записей SRV и обнаружения как имени хоста, так и номера порта соответствующей службы. ^[7]

протокол	использовать	обычный текст или зашифрованные сеансы	только текстовые сеансы	шифровать только сеансы
POP3	входящие сообщения на почте	110 _pop3._tcp		995 _pop3s._tcp
IMAP4	входящие сообщения на почте	143 _imap._tcp		993 _imaps._tcp
SMTP	исходящая корреспонденция	25
MSA	исходящая корреспонденция	587 _submission._tcp		465 ^[8] _submissions._tcp
HTTP	электронная почта		80	443

Обратите внимание, что в то время как веб-почта подчиняется более раннему порядку HTTP, предусматривающему отдельные порты для сеансов шифрования и обычного текста, почтовые протоколы используют технику STARTTLS , тем самым позволяя запускать шифрование уже установленного TCP-соединения. В то время как RFC 2595 препятствовал использованию ранее установленных портов 995 и 993, RFC 8314 продвигает использование неявного TLS, когда он доступен.

Собственные клиентские протоколы [ править ]

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

См. Также [ править ]

Найдите почтовый клиент в Викисловаре, бесплатном словаре.

Сравнение почтовых клиентов
Агент отправки почты (MSA)
Mailto
Агент передачи сообщений (MTA)
Простой протокол передачи почты
Агент доставки сообщений (MDA)

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

^ К. Хатцлер; Д. Крокер; П. Резник; Э. Оллман; Т. Финч (ноябрь 2007 г.). «Технологии аутентификации / авторизации при отправке сообщений» . Операции по отправке электронной почты: требования к доступу и отчетности . IETF . сек. 5. DOI : 10,17487 / RFC5068 . BCP 134. RFC 5068 . Проверено 24 августа 2011 года .Этот документ не дает рекомендаций по конкретным реализациям безопасности. Он просто предоставляет предупреждение о том, что передачи учетных данных пользователя в открытом виде по небезопасным сетям СЛЕДУЕТ избегать во всех сценариях, поскольку это может позволить злоумышленникам прослушивать этот трафик и красть данные учетной записи. В этих случаях настоятельно рекомендуется использовать соответствующую технологию безопасности.
Перейти ↑ Sill 2003 , p. 353: "Как и SMTP, POP3 не зашифрован. Однако, в отличие от SMTP, он требует аутентификации: пользователи должны идентифицировать себя и доказать, что они те, кем они себя называют. К сожалению, аутентификация обычно состоит из представления имени пользователя и пароля, которые известны только пользователю и серверу POP3. Поскольку диалог POP3 не зашифрован, перехватчик может получить имя пользователя и пароль и повторно использовать их для доступа к почтовому ящику пользователя. Таким образом, простой протокол POP3 раскрывает содержимое почтовых сообщений, полученных пользователем, и раскрывает их имя пользователя и пароль, которые затем могут быть повторно использованы кем-то другим.
Обе эти проблемы решаются путем объединения диалога POP3 с безопасностью транспортного уровня, такой как SSL. Поскольку сеансы POP3 с оболочкой SSL зашифрованы от начала до конца, сообщения, имена пользователей или пароли не отображаются в открытом виде.
Дополнительная команда POP3,, APOPзаменяет стандартную USER/PASSаутентификацию механизмом аутентификации запрос-ответ. Это решает проблему раскрытия повторно используемых паролей, но ничего не делает, чтобы помешать злоумышленникам читать почтовые сообщения пользователей по мере их получения ».
^ Обновленная процедура проверки подлинности сервера безопасности транспортного уровня (TLS) для протоколов, связанных с электронной почтой . DOI : 10,17487 / RFC7817 . RFC 7817 .
^ Фликенгер, Роб (2003). Linux Server Hacks: 100 промышленных советов и инструментов . O'Reilly Media . п. 146 . ISBN 978-0596004613. Помимо предоставления удаленного доступа к оболочке и выполнения команд, OpenSSH может перенаправлять произвольные TCP-порты на другой конец вашего соединения. Это может быть очень удобно для защиты электронной почты, Интернета или любого другого трафика, который вам необходимо сохранить конфиденциальным (по крайней мере, до другого конца туннеля).
ssh выполняет локальную переадресацию, привязываясь к локальному порту, выполняя шифрование, отправляя зашифрованные данные на удаленный конец ssh- соединения, затем расшифровывая их и отправляя на удаленный хост и порт, которые вы укажете. Запустите ssh- туннель с переключателем -L (сокращение от Local): естественно, замените пользователя своим именем пользователя и mailhost
root@laptop:~# ssh -f -N -L110:mailhost:110 -l user mailhost
с именем или IP-адресом вашего почтового сервера. Обратите внимание, что для этого примера вам нужно будет иметь root-доступ на портативном компьютере, поскольку вы будете привязаны к привилегированному порту (110, порт POP). Вы также должны отключить любой запущенный локально демон POP (см. /Etc/inetd.conf ), иначе он будет мешать.
Теперь, чтобы зашифровать весь ваш POP-трафик, настройте свой почтовый клиент для подключения к порту 110 localhost. Он будет с удовольствием общаться с mailhost, как если бы он был подключен напрямую, за исключением того, что весь диалог будет зашифрован.
^ "Подходит ли мне IMAP?" . ИТ-услуги . Стэнфордский университет . 4 марта 2010 . Проверено 14 апреля 2013 года .
^ "Пользователь-агент" . Формат статьи Netnews . IETF . Ноябрь 2009. с. 3.2.13. DOI : 10,17487 / RFC5536 . RFC 5536 . Некоторая часть этой информации ранее отправлялась в нестандартных полях заголовка, таких как X-Newsreader, X-Mailer, X-Posting-Agent, X-Http-User-Agent и другие.
^ Сайрус Daboo (март 2011). Использование записей SRV для поиска служб отправки электронной почты / доступа . IETF . DOI : 10,17487 / RFC6186 . RFC 6186 . Проверено 17 апреля 2013 года .
^ Кейт Мур; Крис Ньюман (январь 2018). Открытый текст считается устаревшим: использование безопасности транспортного уровня (TLS) для отправки электронной почты и доступа к ней . IETF . DOI : 10,17487 / RFC8314 . RFC 8314 . Проверено 12 февраля 2018 .

Библиография [ править ]

Подоконник, Дэйв (2003). Справочник qmail . Апресс . ISBN 9781430211341.
Куропатка, Крейг (апрель – июнь 2008 г.). «Техническое развитие электронной почты в Интернете» (PDF) . IEEE Annals of the History of Computing . 30 (2): 3–29. DOI : 10,1109 / mahc.2008.32 . ISSN 1934-1547 . S2CID 206442868 . Архивировано из оригинального (PDF) 12 мая 2011 года.

[1] К. Хатцлер; Д. Крокер; П. Резник; Э. Оллман; Т. Финч (ноябрь 2007 г.). «Технологии аутентификации / авторизации при отправке сообщений» . Операции по отправке электронной почты: требования к доступу и отчетности . IETF . сек. 5. DOI : 10,17487 / RFC5068 . BCP 134. RFC 5068 . Проверено 24 августа 2011 года .Этот документ не дает рекомендаций по конкретным реализациям безопасности. Он просто предоставляет предупреждение о том, что передачи учетных данных пользователя в открытом виде по небезопасным сетям СЛЕДУЕТ избегать во всех сценариях, поскольку это может позволить злоумышленникам прослушивать этот трафик и красть данные учетной записи. В этих случаях настоятельно рекомендуется использовать соответствующую технологию безопасности.

[sill-security-2] Перейти ↑ Sill 2003 , p. 353: "Как и SMTP, POP3 не зашифрован. Однако, в отличие от SMTP, он требует аутентификации: пользователи должны идентифицировать себя и доказать, что они те, кем они себя называют. К сожалению, аутентификация обычно состоит из представления имени пользователя и пароля, которые известны только пользователю и серверу POP3. Поскольку диалог POP3 не зашифрован, перехватчик может получить имя пользователя и пароль и повторно использовать их для доступа к почтовому ящику пользователя. Таким образом, простой протокол POP3 раскрывает содержимое почтовых сообщений, полученных пользователем, и раскрывает их имя пользователя и пароль, которые затем могут быть повторно использованы кем-то другим.
Обе эти проблемы решаются путем объединения диалога POP3 с безопасностью транспортного уровня, такой как SSL. Поскольку сеансы POP3 с оболочкой SSL зашифрованы от начала до конца, сообщения, имена пользователей или пароли не отображаются в открытом виде.
Дополнительная команда POP3,, APOPзаменяет стандартную USER/PASSаутентификацию механизмом аутентификации запрос-ответ. Это решает проблему раскрытия повторно используемых паролей, но ничего не делает, чтобы помешать злоумышленникам читать почтовые сообщения пользователей по мере их получения ».

[3] Обновленная процедура проверки подлинности сервера безопасности транспортного уровня (TLS) для протоколов, связанных с электронной почтой . DOI : 10,17487 / RFC7817 . RFC 7817 .

[4] Фликенгер, Роб (2003). Linux Server Hacks: 100 промышленных советов и инструментов . O'Reilly Media . п. 146 . ISBN 978-0596004613. Помимо предоставления удаленного доступа к оболочке и выполнения команд, OpenSSH может перенаправлять произвольные TCP-порты на другой конец вашего соединения. Это может быть очень удобно для защиты электронной почты, Интернета или любого другого трафика, который вам необходимо сохранить конфиденциальным (по крайней мере, до другого конца туннеля).
ssh выполняет локальную переадресацию, привязываясь к локальному порту, выполняя шифрование, отправляя зашифрованные данные на удаленный конец ssh- соединения, затем расшифровывая их и отправляя на удаленный хост и порт, которые вы укажете. Запустите ssh- туннель с переключателем -L (сокращение от Local): естественно, замените пользователя своим именем пользователя и mailhost
root@laptop:~# ssh -f -N -L110:mailhost:110 -l user mailhost
с именем или IP-адресом вашего почтового сервера. Обратите внимание, что для этого примера вам нужно будет иметь root-доступ на портативном компьютере, поскольку вы будете привязаны к привилегированному порту (110, порт POP). Вы также должны отключить любой запущенный локально демон POP (см. /Etc/inetd.conf ), иначе он будет мешать.
Теперь, чтобы зашифровать весь ваш POP-трафик, настройте свой почтовый клиент для подключения к порту 110 localhost. Он будет с удовольствием общаться с mailhost, как если бы он был подключен напрямую, за исключением того, что весь диалог будет зашифрован.

[5] "Подходит ли мне IMAP?" . ИТ-услуги . Стэнфордский университет . 4 марта 2010 . Проверено 14 апреля 2013 года .

[6] "Пользователь-агент" . Формат статьи Netnews . IETF . Ноябрь 2009. с. 3.2.13. DOI : 10,17487 / RFC5536 . RFC 5536 . Некоторая часть этой информации ранее отправлялась в нестандартных полях заголовка, таких как X-Newsreader, X-Mailer, X-Posting-Agent, X-Http-User-Agent и другие.

[7] Сайрус Daboo (март 2011). Использование записей SRV для поиска служб отправки электронной почты / доступа . IETF . DOI : 10,17487 / RFC6186 . RFC 6186 . Проверено 17 апреля 2013 года .

[8] Кейт Мур; Крис Ньюман (январь 2018). Открытый текст считается устаревшим: использование безопасности транспортного уровня (TLS) для отправки электронной почты и доступа к ней . IETF . DOI : 10,17487 / RFC8314 . RFC 8314 . Проверено 12 февраля 2018 .