Почтовый клиент , программа чтения электронной почты или, более формально, пользовательский агент сообщений (MUA) или почтовый пользовательский агент — это компьютерная программа , используемая для доступа к электронной почте пользователя и управления ею .
Веб -приложение , которое обеспечивает функции управления, составления и приема сообщений, может действовать как веб-клиент электронной почты , а часть компьютерного оборудования или программного обеспечения, основная или наиболее заметная роль которого заключается в работе в качестве клиента электронной почты, также может использовать этот термин.
Как и большинство клиентских программ, почтовый клиент активен только тогда, когда его запускает пользователь. Обычно пользователь электронной почты (клиент) договаривается с удаленным сервером агента передачи почты (MTA) о приеме и хранении электронных писем клиента. MTA, используя подходящий агент доставки почты (MDA), добавляет сообщения электронной почты в хранилище клиента по мере их поступления. Удаленное хранилище почты называется почтовым ящиком пользователя . По умолчанию во многих системах Unix почтовый сервер сохраняет форматированные сообщения в mbox в домашнем каталоге пользователя . Конечно, пользователи системы могут войти в систему и запустить почтовый клиент на том же компьютере, на котором расположены их почтовые ящики; в этом случае сервер на самом деле не является удаленным , кроме как в общем смысле.
Электронные письма хранятся в почтовом ящике пользователя на удаленном сервере до тех пор, пока почтовый клиент пользователя не запросит их загрузку на компьютер пользователя или не сможет иным образом получить доступ к почтовому ящику пользователя на возможно удаленном сервере. Почтовый клиент можно настроить для одновременного подключения к нескольким почтовым ящикам и запроса загрузки электронных писем либо автоматически, например, через заранее установленные интервалы, либо запрос может быть инициирован пользователем вручную.
Доступ к почтовому ящику пользователя можно получить двумя специальными способами. Протокол почтового отделения (POP) позволяет пользователю загружать сообщения по одному и удаляет их с сервера только после того, как они были успешно сохранены в локальном хранилище. Можно оставлять сообщения на сервере, чтобы другой клиент мог получить к ним доступ. Однако не существует возможности пометить конкретное сообщение как просмотренное , отвеченное или перенаправленное , поэтому POP не удобен для пользователей, которые получают доступ к одной и той же почте с разных компьютеров.
Альтернативно, протокол доступа к сообщениям в Интернете (IMAP) позволяет пользователям хранить сообщения на сервере, помечая их соответствующим образом. IMAP предоставляет папки и подпапки, которые могут использоваться разными пользователями с разными правами доступа. Обычно папки «Отправленные », «Черновики » и «Корзина» создаются по умолчанию. IMAP имеет расширение простоя для обновлений в реальном времени, обеспечивая более быстрое уведомление, чем опрос, где возможны длительные соединения. См. также раздел удаленных сообщений ниже.
Протокол метаприложений JSON (JMAP) реализован с использованием API-интерфейсов JSON через HTTP и был разработан как альтернатива IMAP/SMTP.
Кроме того, к хранилищу почтовых ящиков могут обращаться напрямую программы, работающие на сервере, или через общие диски . Прямой доступ может быть более эффективным, но менее портативным, поскольку зависит от формата почтового ящика; он используется некоторыми почтовыми клиентами, включая некоторые приложения веб-почты.
Почтовые клиенты обычно содержат пользовательские интерфейсы для отображения и редактирования текста. Некоторые приложения допускают использование внешнего редактора программы.
Почтовые клиенты будут выполнять форматирование в соответствии с RFC 5322 для заголовков и тела и MIME для нетекстового содержимого и вложений. Заголовки включают поля назначения: «Кому» , «Копия» ( сокращение от «Копия ») и « Скрытая копия », а также поля отправителя, « От которого указан автор(ы) сообщения», « Отправитель », если авторов больше, и « Ответить-кому». в случае, если ответы должны быть адресованы в другой почтовый ящик. Чтобы лучше помочь пользователю с полями назначения, многие клиенты поддерживают одну или несколько адресных книг и/или могут подключаться к серверу каталогов LDAP . Для полей отправителя клиенты могут поддерживать разные идентификаторы.
Настройки клиента требуют настоящего имени пользователя и адреса электронной почты для идентификации каждого пользователя и, возможно, списка серверов LDAP.
Когда пользователь хочет создать и отправить электронное письмо, почтовый клиент выполнит эту задачу. Почтовый клиент обычно настраивается автоматически для подключения к почтовому серверу пользователя, которым обычно является MSA или MTA — два варианта протокола SMTP . Почтовый клиент, использующий протокол SMTP, создает расширение аутентификации, которое почтовый сервер использует для аутентификации отправителя. Этот метод упрощает модульность и кочующие вычисления. Старый метод заключался в том, что почтовый сервер распознавал IP-адрес клиента, например, потому что клиент находится на том же компьютере и использует внутренний адрес 127.0.0.1, или потому что IP-адрес клиента контролируется тем же поставщиком интернет-услуг, который предоставляет как Интернет-адрес, так и 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-трафик, настройте свой почтовый клиент для подключения к порту 110 локального хоста. Он будет успешно общаться с почтовым хостом, как если бы он был подключен напрямую, за исключением того, что весь разговор будет зашифрован.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 в тот же клиент. Эти заголовки не стандартизированы для использования в электронной почте Интернета, и агентам электронной почты следует обращаться с ними с осторожностью.