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

Почтовый клиент , программа чтения электронной почты или, более формально, пользовательский агент сообщений (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 ]}

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

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

Собственные клиентские протоколы

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

См. также

Ссылки

^ К. Хатцлер; Д. Крокер; П. Резник; Э. Оллман; Т. Финч (ноябрь 2007 г.). «Технологии аутентификации/авторизации отправки сообщений» . Операции по отправке электронной почты: требования к доступу и подотчетности . IETF . сек. 5. дои : 10.17487/RFC5068 . BCP 134. RFC 5068 . Проверено 24 августа 2011 г. Этот документ не предоставляет рекомендаций по конкретным реализациям безопасности. Он просто предупреждает о том, что во всех сценариях СЛЕДУЕТ избегать передачи учетных данных пользователя в открытом виде по незащищенным сетям, поскольку это может позволить злоумышленникам прослушивать этот трафик и украсть данные учетной записи. В таких случаях настоятельно рекомендуется ОБЯЗАТЕЛЬНО использовать соответствующую технологию безопасности.
^ Силл 2003 , с. 353: «Как и SMTP, POP3 не зашифрован. Однако в отличие от SMTP он требует аутентификации: пользователи должны идентифицировать себя и доказать, что они те, за кого себя выдают. К сожалению, аутентификация обычно состоит из предоставления имени пользователя и пароля, известных только пользователю и POP3-серверу. Поскольку диалог POP3 не зашифрован, перехватчик может получить имя пользователя и пароль и повторно использовать их для доступа к почтовому ящику пользователя. Таким образом, простой POP3 раскрывает содержимое почтовых сообщений, которые получает пользователь. раскрывает свое имя пользователя и пароль, которые затем могут быть повторно использованы кем-то другим.
Объединение диалога POP3 с безопасностью транспортного уровня, такой как SSL, решает обе эти проблемы. Поскольку сеансы POP3, защищенные SSL, шифруются от начала до конца, никакие сообщения, имена пользователей или пароли не передаются в открытом виде.
Необязательная команда POP3, APOP, заменяет стандартный USER/PASS аутентификация с использованием механизма аутентификации запрос-ответ. Это решает проблему раскрытия многоразовых паролей, но не мешает злоумышленникам читать почтовые сообщения пользователей по мере их получения».
^ Обновленная процедура проверки идентичности сервера Transport Layer Security (TLS) для протоколов, связанных с электронной почтой . дои : 10.17487/RFC7817 . РФК 7817 .
^ Фликенджер, Роб (2003). Хаки для Linux-серверов: 100 промышленных советов и инструментов . О'Рейли Медиа . п. 146 . ISBN 978-0596004613 . Помимо обеспечения удаленного доступа к оболочке и выполнения команд, OpenSSH может перенаправлять произвольные TCP-порты на другой конец вашего соединения. Это может быть очень удобно для защиты электронной почты, Интернета или любого другого трафика, который вам необходимо сохранить конфиденциальным (по крайней мере, до другого конца туннеля).
ssh выполняет локальную пересылку, привязываясь к локальному порту, выполняя шифрование, отправляя зашифрованные данные на удаленный конец ssh -соединения, затем расшифровывая их и отправляя на указанный вами удаленный хост и порт. Запустите ssh -туннель с ключом -L (сокращение от Local):
root@laptop:~# ssh -f -N -L110:mailhost:110 -l user mailhost
Естественно, замените user своим именем пользователя, а mailhost — именем или IP-адресом вашего почтового сервера. Обратите внимание, что для этого примера вам потребуется root-права на ноутбуке, поскольку вы будете привязаны к привилегированному порту (110, порт POP). Вам также следует отключить любой локально работающий демон POP (посмотрите в /etc/inetd.conf ), иначе он будет мешать.
Теперь, чтобы зашифровать весь ваш POP-трафик, настройте свой почтовый клиент для подключения к порту 110 локального хоста. Он будет успешно общаться с почтовым хостом, как если бы он был подключен напрямую, за исключением того, что весь разговор будет зашифрован.
^ «Подходит ли мне IMAP?» . ИТ-услуги . Стэнфордский университет . 4 марта 2010 г. Проверено 14 апреля 2013 г.
^ «Пользователь-Агент» . Формат статьи Netnews . IETF . Ноябрь 2009 г. сек. 3.2.13. дои : 10.17487/RFC5536 . РФК 5536 . Часть этой информации ранее отправлялась в нестандартизированных полях заголовков, таких как X-Newsreader, X-Mailer, X-Posting-Agent, X-Http-User-Agent и других.
^ Дж. Пальме (февраль 1997 г.). «Использование шлюзовых заголовков» . Общие заголовки Интернет-сообщений . сек. 2. дои : 10.17487/RFC2076 . РФК 2076 . Проверено 11 мая 2015 г. Заголовки, определенные только в RFC 1036 для использования в Usenet News, иногда появляются в почтовых сообщениях либо потому, что сообщения были перенаправлены из Usenet News в электронную почту, либо потому, что сообщения были написаны в комбинированных клиентах, поддерживающих как электронную почту, так и Usenet News в тот же клиент. Эти заголовки не стандартизированы для использования в электронной почте Интернета, и агентам электронной почты следует обращаться с ними с осторожностью.
^ Сайрус Дабу (март 2011 г.). Использование записей SRV для поиска служб отправки электронной почты/доступа . IETF . дои : 10.17487/RFC6186 . РФК 6186 . Проверено 17 апреля 2013 г.
^ Кейт Мур; Крис Ньюман (январь 2018 г.). Открытый текст считается устаревшим: использование протокола TLS для отправки электронной почты и доступа к ней . IETF . дои : 10.17487/RFC8314 . RFC 8314 . Проверено 12 февраля 2018 г.

Библиография

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

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

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

[3] Обновленная процедура проверки идентичности сервера Transport Layer Security (TLS) для протоколов, связанных с электронной почтой . дои : 10.17487/RFC7817 . РФК 7817 .

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

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

[6] «Пользователь-Агент» . Формат статьи Netnews . IETF . Ноябрь 2009 г. сек. 3.2.13. дои : 10.17487/RFC5536 . РФК 5536 . Часть этой информации ранее отправлялась в нестандартизированных полях заголовков, таких как X-Newsreader, X-Mailer, X-Posting-Agent, X-Http-User-Agent и других.

[7] Дж. Пальме (февраль 1997 г.). «Использование шлюзовых заголовков» . Общие заголовки Интернет-сообщений . сек. 2. дои : 10.17487/RFC2076 . РФК 2076 . Проверено 11 мая 2015 г. Заголовки, определенные только в RFC 1036 для использования в Usenet News, иногда появляются в почтовых сообщениях либо потому, что сообщения были перенаправлены из Usenet News в электронную почту, либо потому, что сообщения были написаны в комбинированных клиентах, поддерживающих как электронную почту, так и Usenet News в тот же клиент. Эти заголовки не стандартизированы для использования в электронной почте Интернета, и агентам электронной почты следует обращаться с ними с осторожностью.

[8] Сайрус Дабу (март 2011 г.). Использование записей SRV для поиска служб отправки электронной почты/доступа . IETF . дои : 10.17487/RFC6186 . РФК 6186 . Проверено 17 апреля 2013 г.

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

[ 1 ]

[ 2 ]

[ 3 ]

[ 4 ]

[ 5 ]

[ 6 ]

[ 7 ]

[ 8 ]

[ 9 ]