Клиент электронной почты , программа для чтения электронной почты или, более формально, почтовый пользовательский агент ( MUA) — это компьютерная программа, используемая для доступа к электронной почте пользователя и управления ею .
Веб -приложение , которое обеспечивает функции управления сообщениями, их составления и приема, может выступать в качестве веб-клиента электронной почты , а также часть компьютерного оборудования или программного обеспечения, чья основная или наиболее заметная роль заключается в работе в качестве клиента электронной почты, также может использовать этот термин.
Как и большинство клиентских программ, почтовый клиент активен только тогда, когда его запускает пользователь. Обычно пользователь электронной почты (клиент) договаривается с удаленным сервером Mail Transfer Agent (MTA) о получении и хранении писем клиента. MTA, используя подходящий почтовый агент (MDA), добавляет электронные сообщения в хранилище клиента по мере их поступления. Удаленное почтовое хранилище называется почтовым ящиком пользователя . Настройка по умолчанию во многих системах Unix заключается в том, что почтовый сервер хранит отформатированные сообщения в mbox в домашнем каталоге пользователя . Конечно, пользователи системы могут войти в систему и запустить почтовый клиент на том же компьютере, на котором размещены их почтовые ящики; в этом случае сервер на самом деле не является удаленным , за исключением общего смысла.
Письма хранятся в почтовом ящике пользователя на удаленном сервере до тех пор, пока почтовый клиент пользователя не запросит их загрузку на компьютер пользователя или не сможет иным образом получить доступ к почтовому ящику пользователя на возможно удаленном сервере. Почтовый клиент может быть настроен на подключение к нескольким почтовым ящикам одновременно и на запрос загрузки писем либо автоматически, например, через заданные интервалы, либо запрос может быть инициирован вручную пользователем.
Доступ к почтовому ящику пользователя можно получить двумя выделенными способами. Протокол почтового отделения (POP) позволяет пользователю загружать сообщения по одному и удаляет их с сервера только после того, как они будут успешно сохранены в локальном хранилище. Можно оставлять сообщения на сервере, чтобы другой клиент мог получить к ним доступ. Однако не предусмотрено пометки определенного сообщения как прочитанного , отвеченного или пересланного , поэтому POP неудобен для пользователей, которые получают доступ к одной и той же почте с разных машин.
В качестве альтернативы протокол доступа к сообщениям в Интернете (IMAP) позволяет пользователям хранить сообщения на сервере, помечая их соответствующим образом. IMAP предоставляет папки и подпапки, которые могут совместно использоваться разными пользователями с возможными разными правами доступа. Обычно папки «Отправленные» , «Черновики» и «Корзина» создаются по умолчанию. IMAP имеет расширение «Неактивно» для обновлений в реальном времени, обеспечивая более быстрое уведомление, чем опрос, где возможны длительные соединения. См. также раздел «Удаленные сообщения» ниже.
Протокол метаприложений JSON (JMAP) реализован с использованием API JSON поверх HTTP и был разработан как альтернатива IMAP/SMTP.
Кроме того, доступ к хранилищу почтового ящика может осуществляться напрямую программами, работающими на сервере, или через общие диски . Прямой доступ может быть более эффективным, но менее переносимым, поскольку зависит от формата почтового ящика; он используется некоторыми почтовыми клиентами, включая некоторые приложения веб-почты.
Клиенты электронной почты обычно содержат пользовательские интерфейсы для отображения и редактирования текста. Некоторые приложения позволяют использовать внешний редактор программы.
Клиенты электронной почты будут выполнять форматирование в соответствии с RFC 5322 для заголовков и тела , а также MIME для нетекстового содержимого и вложений. Заголовки включают поля назначения, To , Cc (сокращение от Carbon copy ) и Bcc ( Blind carbon copy ), а также поля отправителя From Which — автор(ы) сообщения, Sender в случае, если авторов больше, и Reply-To в случае, если ответы должны быть адресованы на другой почтовый ящик. Чтобы лучше помочь пользователю с полями назначения, многие клиенты поддерживают одну или несколько адресных книг и/или могут подключаться к серверу каталогов 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] для идентификации программного обеспечения, используемого для отправки сообщения. Это поле заголовка определено для Netnews, но не для электронной почты, и, как таковое, является нестандартным [7] в заголовках электронной почты.
RFC 6409 «Отправка сообщений по почте » подробно описывает роль агента отправки почты .
RFC 5068, Операции отправки электронной почты: требования к доступу и подотчетности , содержит обзор концепций MTA, MSA, MDA и MUA. В нем упоминается, что « Провайдеры доступа НЕ ДОЛЖНЫ блокировать пользователям доступ к внешнему Интернету с использованием порта SUBMISSION 587 » и что « MUA ДОЛЖНЫ использовать порт SUBMISSION для отправки сообщений » .
RFC 5965, Расширяемый формат отчетов об обратной связи по электронной почте , предоставляет «расширяемый формат и тип MIME, которые могут использоваться почтовыми операторами для предоставления другим сторонам отзывов о полученных электронных письмах».
Почтовые серверы и клиенты по соглашению используют номера портов TCP в следующей таблице. Для MSA, IMAP и POP3 таблица также сообщает метки, которые клиент может использовать для запроса записей SRV и обнаружения как имени хоста, так и номера порта соответствующей службы. [8]
В то время как веб-почта подчиняется более раннему HTTP-предложению о наличии отдельных портов для сеансов шифрования и обычного текста, почтовые протоколы используют технику STARTTLS , тем самым позволяя шифрованию начинаться на уже установленном TCP-соединении. В то время как RFC 2595 ранее не одобрял использование ранее установленных портов 995 и 993, RFC 8314 поощряет использование неявного TLS , когда он доступен.
Почтовые системы Microsoft используют фирменный интерфейс программирования приложений обмена сообщениями (MAPI) в клиентских приложениях, таких как Microsoft Outlook , для доступа к серверам электронной почты Microsoft Exchange .
документ не содержит рекомендаций по конкретным реализациям безопасности. Он просто предупреждает, что передачу учетных данных пользователя в открытом виде по незащищенным сетям СЛЕДУЕТ избегать во всех сценариях, поскольку это может позволить злоумышленникам прослушивать этот трафик и украсть данные учетной записи. В этих случаях настоятельно рекомендуется использовать соответствующую технологию безопасности.
APOP, заменяет стандартную USER/PASSаутентификацию механизмом аутентификации вызов-ответ. Это решает проблему раскрытия повторно используемых паролей, но не делает ничего, чтобы помешать злоумышленникам читать почтовые сообщения пользователей по мере их получения».Помимо предоставления удаленного доступа к оболочке и выполнения команд, OpenSSH может пересылать произвольные порты TCP на другой конец вашего соединения. Это может быть очень удобно для защиты электронной почты, веб-трафика или любого другого трафика, который вам нужно сохранить конфиденциальным (по крайней мере, на всем пути до другого конца туннеля).
ssh выполняет локальную пересылку, привязываясь к локальному порту, выполняя шифрование, отправляя зашифрованные данные на удаленный конец ssh -подключения, затем расшифровывая их и отправляя на удаленный хост и указанный вами порт. Запустите туннель ssh с помощью ключа -L (сокращение от Local): Естественно, замените user на свое имя пользователя, а mailhost на имя или IP-адрес вашего почтового сервера. Обратите внимание, что для этого примера вам нужно будет иметь права root на ноутбуке, поскольку вы будете привязываться к привилегированному порту (110, порт POP). Вам также следует отключить любой локально запущенный демон POP (посмотрите в /etc/inetd.conf ), иначе он будет мешать. Теперь, чтобы зашифровать весь ваш POP-трафик, настройте почтовый клиент на подключение к порту localhost 110. Он будет успешно взаимодействовать с mailhost, как если бы был подключен напрямую, за исключением того, что весь разговор будет зашифрован.root@laptop:~# ssh -f -N -L110:mailhost:110 -l user mailhost
Часть этой информации ранее отправлялась в нестандартных полях заголовков, таких как X-Newsreader, X-Mailer, X-Posting-Agent, X-Http-User-Agent и других.
, определенные только в RFC 1036 для использования в Usenet News, иногда появляются в почтовых сообщениях, либо потому, что сообщения были шлюзованы из Usenet News в электронную почту, либо потому, что сообщения были написаны в комбинированных клиентах, поддерживающих как электронную почту, так и Usenet News в одном клиенте. Эти заголовки не стандартизированы для использования в электронной почте Интернета и должны обрабатываться с осторожностью агентами электронной почты.