blackhack.ru ОК. Настройки, новости, игры.
И другие агенты пересылки сообщений используют SMTP для отправки и получения почтовых сообщений, работающие на пользовательском уровне клиентские почтовые приложения обычно используют SMTP только для отправки сообщений на почтовый сервер для ретрансляции. Для получения сообщений клиентские приложения обычно используют либо POP (англ. Post Office Protocol - протокол почтового отделения), либо IMAP (англ. Internet Message Access Protocol ), либо патентованные системы (такие как Microsoft Exchange и Lotus Notes /Domino) для доступа к учетной записи своего почтового ящика на сервере.
История
В 1960-х годах использовались различные виды электронной связи. Люди связывались друг с другом с помощью систем, разработанных для определённых мейнфреймов . Когда всё больше компьютеров становились связанными, особенно в сети Правительства США, ARPANET , были разработаны стандарты для того, чтобы пользователи на различных системах могли писать электронные сообщения друг другу. Эти стандарты, разработанные в 1970-х годах, стали основой для SMTP.
Корни SMTP можно проследить в двух описанных в 1971 г. реализациях - Mail Box Protocol и SNDMSG, который был «изобретен» Рэем Томлинсоном из BBN Technologies для TOPS-20/TENEX-компьютеров, посылающих сообщения по ARPANET (в то время к ней были подсоединены менее 50 хостов).
Дальнейшие реализации включают в себя FTP Mail и Mail Protocol, разработанные в 1973 г. Разработка продолжалась на протяжении 1970-х, пока ARPANET не преобразовалась в современный Интернет около 1980 г. В том же году Джон Постел предложил Mail Transport Protocol (протокол передачи почты), благодаря которому FTP перестал быть основой для передачи почты. SMTP опубликован в RFC 821 (также написанном Постелом) в августе 1982 г.
Стандарт SMTP был разработан примерно в то же время, что и Usenet , сеть передачи данных, имеющая некоторые сходства с SMTP. SMTP стал широко использоваться в ранние 1980-е. В то время, он был дополнением для работающей под Unix почтовой программы Unix Copy Program (UUCP), которая больше подходила для обработки передачи электронных сообщений между периодически связанными устройствами. С другой стороны, SMTP прекрасно работает, когда как отправляющее, так и принимающее устройства связаны в сети постоянно. Оба устройства используют механизм хранения и пересылки и являются примером push-технологии (технологии «проталкивания»). Хотя новостные группы Usenet все еще распространяются между серверами с помощью UUCP, почта UUCP фактически исчезла вместе с маршрутом «bang path» (последовательность хост-машин в сети, по которой сообщение должно дойти до адресата), которые использовались как заголовки маршрутизации. В статье о перезаписи отправителя содержится техническая справочная информация о истории раннего SMTP и маршрутизации от источника до RFC 1123 .
Поскольку этот протокол сначала был с текстовым (ASCII) интерфейсом, то он плохо работал с бинарными файлами и символами многих неанглийских языков. Такие стандарты, как Multipurpose Internet Mail Extensions (MIME), были разработаны для кодирования двоичных файлов для передачи через SMTP. Разработанные после Sendmail агенты пересылки, как правило, также осуществляли опцию чистых 8 бит, так что альтернативная стратегия «просто посылай восемь» может быть использована для передачи произвольных текстовых данных (в любой восьмибитной ASCII-подобной кодировке символов) через SMTP. Однако все еще оставалась проблема кракозябр , вызванная разным отображением наборов символов у производителей, хотя сами почтовые адреса все еще позволяли использовать исключительно ASCII. Сегодня агенты пересылки, работающие с чистыми 8 битами, как правило, поддерживают расширение 8BITMIME, позволяющее передавать бинарные файлы почти так же легко, как обычный текст. Недавно было создано расширение SMTPUTF8 для поддержки текста в кодировке UTF-8 , благодаря чему стало возможным включать международное содержимое и адреса с использованием таких алфавитов, как кириллица или китайский.
Многие выдающиеся люди внесли свой вклад в спецификацию основного SMTP, среди них Джон Постел , Эрик Оллман , Дэйв Крокер, Нед Фрид, Рэндалл Джелленс, Джон Кленсин и Кейт Мур.
Модель обработки почты
Электронная почта представлена почтовым клиентом (MUA, mail user agent - пользовательский почтовый агент) для почтового сервера (MSA, mail submission agent - агент передачи электронной почты) с помощью SMTP по TCP -порту 587. Оттуда MSA доставляет почту своим агентам пересылки сообщений (MTA, mail transfer agent). Часто эти два агента являются просто различными образцами одного и того же программного обеспечения, запущенного с разными параметрами на одном устройстве. Локальная обработка может быть проведена как на отдельной машине, так и разделена между различными устройствами; в первом случае вовлеченные процессы имеют общий доступ к файлам, во втором случае SMTP используется для пересылки сообщения внутренне, причем каждый хост настроен на использование следующего устройства в качестве промежуточного хоста . Каждый процесс - сам по себе MTA, т. е. - SMTP-сервер.
Граничный MTA должен найти целевой хост. Он использует систему доменных имен (DNS) для поиска записей почтового обменника (mail exchanger - MX) домена получателя (часть адреса , находящаяся справа от символа @). Возвращаемая запись почтового MX содержит имя целевого хоста. Затем MTA подключается к серверу обмена в качестве SMTP-клиента.
Как только цель MX принимает входящее сообщение, она передает его агенту доставки почты (mail delivery agent - MDA) для локальной доставки сообщения. MDA предусматривает возможность сохранять сообщения в соответствующем формате почтового ящика. Прием почты, опять же, может быть проведен как несколькими, так и одним компьютером - изображение показывает два ближайших ящика для каждого случая. MDA может доставлять сообщения прямо на хранение или передавать их по сети с помощью SMTP или любых других средств, в том числе протокола локальной пересылки почты (Local Mail Transfer Protocol - LMTP) - производного от SMTP, предназначенного для этой цели.
После доставки на локальный почтовый сервер сообщение хранится для пакетного поиска по аутентифицированным почтовым клиентам (MUA). Сообщение извлекается приложениями конечного пользователя (почтовые клиенты) с использованием Internet Message Access Protocol (IMAP, который облегчает доступ к сообщениям и управляет хранящейся почтой), или же с помощью Post Office Protocol (POP), который обычно использует традиционный mbox-формат файлов, или фирменные системы вроде Miscrosoft Exchange/Outlook или Lotus Notes/Domino. Клиенты сетевой почты могут использовать любой метод, но протокол поиска часто не соответствует официальным стандартам.
SMTP определяет передачу сообщения, а не его содержание. Таким образом, он задает оболочку сообщения и её параметры (такие, как отправитель оболочки), но не заголовок либо тело самого сообщения. STD 10 и RFC 5321 определяют SMTP (оболочку), в то время как STD 11 и RFC 5322 - сообщение (заголовок и тело), официально называемый форматом почтового сообщения (Internet Message Format).
Обзор протокола
SMTP - требующий соединения текстовый протокол, по которому отправитель сообщения связывается с получателем посредством выдачи командных строк и получения необходимых данных через надёжный канал, в роли которого обычно выступает TCP-соединение (Transmission Control Protocol - протокол управления передачей). SMTP-сессия состоит из команд, посылаемых SMTP-клиентом , и соответствующих ответов SMTP-сервера . Когда сессия открыта, сервер и клиент обмениваются её параметрами. Сессия может включать нуль и более SMTP-операций (транзакций).
SMTP-операция состоит из трёх последовательностей команда/ответ (см. пример ниже). Описание последовательностей:
- MAIL FROM - устанавливает обратный адрес (т. е. Return-Path, 53121.From, mfrom). Это адрес для возвращённых писем .
- RCPT TO - устанавливает получателя данного сообщения. Эта команда может быть дана несколько раз, по одному на каждого получателя. Эти адреса также являются частью оболочки.
- DATA - для отправки текста сообщения. Это само содержимое письма, в противоположность его оболочке. Он состоит из заголовка сообщения и тела сообщения, разделенных пустой строкой. DATA, по сути, является группой команд, а сервер отвечает дважды: первый раз на саму команду DATA, для уведомления о готовности принять текст; и второй раз после конца последовательности данных, чтобы принять или отклонить всё письмо.
Помимо промежуточных ответов для DATA-команды, каждый ответ сервера может быть положительным (код ответа 2хх) или отрицательным. Последний, в свою очередь, может быть постоянным (код 5хх) либо временным (код 4хх). Отказ SMTP-сервера в передаче сообщения - постоянная ошибка; в этом случае клиент должен отправить возвращённое письмо. После сброса - положительного ответа, сообщение скорее всего будет отвержено. Также сервер может сообщить о том, что ожидаются дополнительные данные от клиента (код 3xx).
Изначальным хостом (SMTP-клиентом) может быть как почтовый клиент конечного пользователя (функционально определяемый как почтовый агент - MUA), так и агент пересылки сообщений (MTA) на сервере, т.е. сервер действует как клиент в соответствующей сессии для ретрансляции сообщения. Полностью функциональные сервера поддерживают очереди сообщений для повторной передачи сообщения в случае ошибок.
MUA знает SMTP-сервер для исходящей почты из своих настроек. SMTP-сервер, действующий как клиент, т. е. пересылающий сообщения, определяет, к какому серверу подключиться, просмотром ресурса записей MX (Mail eXchange) DNS для домена каждого получателя. В случае, если запись MX не найдена, совместимые MTA (не все) возвращаются к простой А-записи . Пересылающие сервера также могут быть настроены на использование Smart host.
SMTP-сервер, действующий как клиент, устанавливает TCP-соединение с сервером по разработанному для SMTP порту 25. MUA должен использовать порт 587 для подключения к агенту предоставления сообщений (MSA). Основное различие между MTA и MSA заключается в том, что SMTP-аутентификация обязательно только для последнего.
SMTP и извлечение сообщений
SMTP - всего лишь протокол доставки. Он не может по требованию взять сообщения с удаленного сервера. Для извлечения почты и управления почтовым ящиком разработаны другие протоколы, такие как POP и IMAP. Тем не менее, SMTP предоставляет возможность начать на удаленном сервере обработку очереди сообщений, при которой запрашивающая система может получать все направленные ей сообщения (см. Remote Message Queue Starting ниже). POP и IMAP предпочтительны, когда компьютер пользователя включен не постоянно, или же временно подключен к Интернету.
Remote Message Queue Starting
Remote Message Queue Starting (запуск удаленной очереди сообщений) - особенность SMTP, позволяющая удаленнному хосту начать обработку очереди сообщений на сервере так, что он может получать предназначенные ему сообщения с помощью команды TURN. Однако эта особенность считалась небезопасной и была расширена в RFC 1985 командой ETRN, которая работает надёжнее благодаря основанному на информации DNS методу аутентификации .
On-Demand Mail Relay
ODMR (On-Demand Mail Relay - ретрансляция почты по требованию) - стандартизированное в RFC 2645 SMTP-расширение, позволяющее проводить ретрансляцию сообщения аутентифицированному пользователю.
Интернационализация
Многие пользователи, чей набор символов отличается от латиницы, сталкиваются с требованием адреса электронной почты на латинице. Для решения этой проблемы был создан RFC 6531 , предоставляющий возможности для интернационализации для SMTP - расширение SMTPUTF8. RFC 6531 предоставляет поддержку многобайтных и не-ASCII символов в почтовом адресе, например: δοκιμή@παράδειγμα.δοκιμή или 测试@测试.测试. Текущая поддержка ограничена, но есть большой интерес в широком распространении RFC 6531 и связанных с ним RFC в странах с обширной базой пользователей, для которых латиница не является родным алфавитом.
SMTP-сервер исходящей почты
Почтовый клиент должен знать IP-адрес SMTP-сервера, который задается как часть конфигурации (обыкновенно в виде DNS-имени). Сервер будет доставлять исходящие сообщения от лица пользователя.
Ограничения доступа к серверу исходящей почты
Администраторам сервера необходимо контролировать то, какие клиенты могут использовать сервер. Это позволяет им бороться с такими злоупотреблениями, как спам. Обычно используются два решения:
- В прошлом многие системы вводили ограничения по местоположению клиента, допуская к использованию лишь тех, чей IP-адрес был среди подконтрольных администраторам.
- Современные сервера обычно предлагают альтернативную систему, требующую аутентификацию клиентов для получения доступа.
Ограничение доступа по местоположению
В этом случае SMTP-сервер интернет-провайдера не разрешит допуск пользователям «за пределами» сети провайдера. Точнее, сервер может допустить лишь тех пользователей, чей IP-адрес предоставлен данным провайдером, что эквивалентно требованию соединения с Интернетом с помощью этого провайдера. Мобильный пользователь часто может оказаться в сети, отличной от сети своего провайдера, и потому сообщения не будут отправляться.
У данной системы есть несколько разновидностей. Например, SMTP-сервер организации может предоставлять доступ только пользователям той же сети, блокируя остальных пользователей. Также сервер может проводить ряд проверок клиентского IP-адреса. Эти методы обычно использовались организациями и учреждениями, например университетами, для внутреннего пользования сервером. Однако, большая их часть теперь использует описанные ниже методы аутентификации.
Благодаря ограничению доступа определенным адресам, администраторы сервера могут легко определить адрес любого злоумышленника. Если пользователь может использовать различные провайдеры для соединения с Интернетом, этот вид ограничения становится нецелесообразным, а изменение настроенного адреса SMTP-сервера исходящей почты непрактично. Крайне желательно иметь возможность использовать такую информацию о настройках клиента, которая не нуждается в изменении.
Аутентификация клиента
Вместо описанного ранее ограничения по местоположению, современные SMTP-сервера обычно требуют аутентификацию пользователей перед получением доступа. Эта система, будучи более гибкой, поддерживает мобильных пользователей и предоставляет им фиксированный выбор настроенного сервера исходящей почты.
Открытый релей
Сервер, доступный для широкой сети и не предоставляющий эти виды ограничения доступа, называют открытым релеем . Сейчас такие сервера считаются дурным тоном.
Порты
Администраторы сервера выбирают, какой порт будут использовать клиенты для ретрансляции исходящей почты - 25 или 587. Спецификации и многие сервера поддерживают и тот, и другой порты. Хотя некоторые сервера поддерживают порт 465 для безопасного SMTP,но предпочтительнее использовать стандартные порты и ESMTP-команды, если необходима защищенная сессия между клиентом и сервером.
Некоторые сервера настроены на отклонение всех ретрансляций по порту 25, но пользователям, прошедшим аутентификацию по порту 587, позволено перенаправлять сообщения на любой действительный адрес.
Некоторые провайдеры перехватывают порт 25, перенаправляя трафик на свой собственный SMTP-сервер вне зависимости от адреса назначения. Таким образом, их пользователи не могут получить доступ к серверу за пределами провайдерской сети по порту 25.
Некоторые сервера поддерживают аутентифицированный доступ по дополнительному, отличному от 25, порту, позволяя пользователям соединяться с ними, даже если порт 25 заблокирован.
Пример простейшей SMTP-сессии
C: - клиент, S: - сервер
S: (ожидает соединения) C: (Подключается к порту 25 сервера) S:220 mail.company.tld ESMTP CommuniGate Pro 5.1.4i is glad to see you! C:HELO S:250 domain name should be qualified C:MAIL FROM:В результате такой сессии письмо будет доставлено адресату [email protected], но не будет доставлено адресату [email protected], потому что такого адреса не существует.
Дополнительные расширения
Многие клиенты запрашивают расширения SMTP, поддерживаемые сервером, с помощью команды EHLO из спецификации расширенного SMTP (RFC 1870). HELO используется только в том случае, если сервер не ответил на EHLO . Современные клиенты могут использовать ключ SIZE расширения ESMTP для запроса максимального размера сообщения, которое будет принято. Более старые клиенты и сервера могут попытаться передать чрезмерно большие сообщения, которые будут отклонены после потребления сетевых ресурсов, включая время соединения. Пользователи могут вручную заранее определить максимальный размер, принимаемый ESMTP-серверами. Клиент заменяет команду HELO на EHLO .
S: 220 smtp2.example.com ESMTP Postfix C: EHLO bob.example.org S: 250-smtp2.example.com Hello bob.example.org S: 250-SIZE 14680064 S: 250-PIPELINING S: 250 HELPsmtp2.example.com объявляет,что он примет сообщение размером не больше чем 14,680,064 октетов (8-битных байтов). В зависимости от фактического использования сервера, он может на данный момент не принять сообщение такой величины. В простейшем случае, ESMTP-сервер объявит максимальный SIZE только при взаимодействии с пользователем через EHLO .
Безопасность SMTP и спам
Изначальная спецификация SMTP не включала средств для аутентификации отправителей. Впоследствии, в RFC 2554 было введено расширение. Расширение SMTP (ESMTP) предоставляет почтовым клиентам механизм задания механизма обеспечения безопасности для сервера, аутентификации и профиля безопасности SASL (Simple Authentication and Security Layer) для последующих передач сообщений.
Продукты Microsoft реализуют собственный протокол - SPA (Secure Password Authentication) с помощью расширения SMTP-AUTH.
Однако, непрактичность широкого распространения реализации и управления SMTP-AUTH означает, что проблема спама не может быть решена с его помощью.
Обширное изменение SMTP, так же как и полная его замена, считаются непрактичными из-за огромной инсталированной базы SMTP. Internet Mail 2000 был одним из претендентов для такой замены.
Спам функционирует благодаря различным факторам, в том числе не соответствующие стандартам реализации MTA, уязвимости в защите операционных систем (усугубляемые постоянным широкополосным подключением), что позволяет спамерам удаленно контролировать компьютер конечного пользователя и посылать с него спам.
Существует несколько предложений для побочных протоколов, помогающих работе SMTP. Исследовательская группа Anti-Spam (The Anti-Spam Research Group - ASRG) - подразделение Исследовательской группы Интернет-технологий работает над почтовой аутентификацией и другими предложениями для предоставления простой аутентификации, которая будет гибкой, легковесной и масштабируемой. Недавняя деятельность Инженерного совета Интернета (IETF) включает в себя MARID (2004), приведший к двум утвержденным IETF-экспериментам в 2005, и DomainKeys Identified Mail в 2006.
Расширения ESMTP
RFC 1869 предписывает начинать сессию не командой HELO , а командой EHLO . В случае, если сервер не поддерживает расширений, то он ответит на EHLO ошибкой, в этом случае клиент должен послать команду HELO и не использовать расширения протокола.
Если же сервер поддерживает ESMTP, то кроме приветствия он сообщит список поддерживаемых расширений протокола SMTP, например:
Ehlo office.company1.tld 250-mail.company2.tld is pleased to meet you 250-DSN 250-SIZE 250-STARTTLS 250-AUTH LOGIN PLAIN CRAM-MD5 DIGEST-MD5 GSSAPI MSN NTLM 250-ETRN 250-TURN 250-ATRN 250-NO-SOLICITING 250-HELP 250-PIPELINING 250 EHLO
Стандарты RFC
- RFC 1870 SMTP Service Extension for Message Size Declaration (заменяет RFC 1653)
- RFC 2034 SMTP Service Extension for Returning Enhanced Error Codes
- RFC 2505 Anti-Spam Recommendations for SMTP MTAs (BCP 30)
- RFC 4954 SMTP Service Extension for Authentication (заменяет RFC 2554)
- RFC 2822 Internet Message Format (заменяет RFC 822 aka STD 11)
- RFC 2920 SMTP Service Extension for Command Pipelining (STD 60)
- RFC 3030 SMTP Service Extensions for Transmission of Large and Binary MIME Messages
- RFC 3207 SMTP Service Extension for Secure SMTP over Transport Layer Security (заменяет RFC 2487)
- RFC 3461 SMTP Service Extension for Delivery Status Notifications (заменяет RFC 1891)
- RFC 3462 The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages (заменяет RFC 1892)
- RFC 3463 Enhanced Status Codes for SMTP (заменяет RFC 1893)
- RFC 3464 An Extensible Message Format for Delivery Status Notifications (заменяет RFC 1894)
- RFC 3552 Guidelines for Writing RFC Text on Security Considerations
- RFC 3834 Recommendations for Automatic Responses to Electronic Mail
- RFC 4409 Message Submission for Mail (заменяет RFC 2476)
- RFC 5321 Simple Mail Transfer Protocol (заменяет RFC 821 aka STD 10, RFC 974 , RFC 1869 , RFC 2821)
- RFC 5336 SMTP Extension for Internationalized Email Addresses
- Перевод RFC 2505 - Рекомендации по предотвращению спама для SMTP MTA
- Перевод RFC 2554 - Расширение сервиса SMTP для аутентификации
- Перевод RFC 5321 - Простой протокол передачи электронной почты (SMTP)
Литература
- Hughes L Internet e-mail Protocols, Standards and Implementation. - Artech House Publishers, 1998. - ISBN 0-89006-939-5
- Hunt C sendmail Cookbook. - O"Reilly Media, 2003. - ISBN 0-596-00471-0
- Johnson K Internet Email Protocols: A Developer"s Guide. - Addison-Wesley Professional, 2000. - ISBN 0-201-43288-9
- Loshin P Essential Email Standards: RFCs and Protocols Made Practical. - John Wiley & Sons, 1999. - ISBN 0-471-34597-0
- Rhoton J Programmer"s Guide to Internet Mail: SMTP, POP, IMAP, and LDAP. - Elsevier, 1999. -
Ярким пунктом многих протоколов прикладного уровня,является то, что они простые. Протоколы, основанные на TCP используют в основном команды и ответы в текстовом формате, что делает их более удобными для пользователей, чтобы понять и программистам для реализации.
Для дальнейшей иллюстрации мы рассмотрим два протокола, которые можно использовать каждый день, чтобы отправлять и получать электронную почту: SMTP и POP3.
Простой протокол передачи почты: SMTP
Simple Mail Transfer Protocol (SMTP)
является одним из самых уважаемых интернет-протоколов. Разработанный в начале 1980-х, его функции чисто и просто передают по электронной почте, а также между сетями и другими транспортными системами. Таким образом, его использование не обязательно должно быть ограничено в системах, использующих протокол TCP / IP
. Любая система связи способна обрабатывать линии до 1000 7-битных ASCII символов которые могут быть использованы для выполнения сообщений по протоколу SMTP. В TCP / IP сети, однако, TCP обеспечивает транспортный механизм.
В SMTP-отправитель
является клиентом, а клиент может взаимодействовать с различными серверами. Сообщения могут отправляться непосредственно от отправляющего хоста на хост-получателя, требующего отдельного соединения TCP и должны быть сделаны каждая копия каждого сообщения. Тем не менее, несколько получателей почты могут запустить свой собственный сервер SMTP.
Это наиболее характерно для назначения SMTP
сообщений,сервер, который обслуживает группу пользователей, таких как интернет-домены. Сервер получает всю почту, предназначенную для пользователей, а затем позволяет им собирать, используя POP3 (Post Office Protocol версии 3)
или другие почтовые протоколы. Кроме того, большинство SMTP-клиентов
посылают сообщения в один «умный хост» сервер, чья работа заключается в том, чтобы передать эти сообщения для своих возможных получателей.
Транзакции SMTP
начинаются тогда, когда отправитель клиент открывает TCP соединение с приемником, используя известный номер порта 25. Сервер признает связь, отправив обратно сообщение вида «220 SMTP Server Ready
«. SMTP
использует похожий формат ответов на FTP, который мы рассмотрели ранее. Полученный трехзначный код, программное обеспечение клиента должно ответить, если все будет ОК. Эта стаья, чтобы помочь людям, которые могли бы устранить неполадки с помощью анализа журнала транзакций. В окне «Application Protocol Ответы кодов» содержится более подробная информация о кодах сообщений ответа.
Сервер SMTP
может отказать в связи, отправив обратно сообщение с ответным кодом «421 Служба недоступна». Например, SMTP
сервер провайдера услуг Интернета, при условии, для своих абонентов для передачи исходящей почты может отказать в связи с хостом, чей IP-адрес указывает, что он не является абонентом ISP. Основной SMTP протокол
не имеет формы контроля доступа - так, как его можно использовать для передачи сообщений и это делает его непрактичным - так что единственный путь,в котором провайдеры могут предотвратить неподписчиков, таких как спамеров, от использования своих почтовых серверов для отправки сообщений.
Получив подтверждение правильных знаков отправителя на сервер, сервер отправляет строку «HELO имя». HELO знак на команду и имя, является именем хоста. Как мы увидим, имя хоста используется в редакции: заголовок, сервер добавляет сообщение, когда он отправляет его по своему пути. Эта информация позволяет получателю проследить путь по сообщению.
Посылающий сервер
Когда отправитель получает признание «250 OK» он может начать отправку сообщений. Протокол чрезвычайно прост. Всё что отправители должны сделать, это сказать, какие из сообщений должны поставлять содержимое сообщения.
Сообщение задаётся с помощью команды «MAIL FROM:
Оно действительно на обратном пути и является недействительным, как в «MAIL FROM: <>». Это обычно используется при отправки отчета об ошибке. Нулевой путь возврата означает, что отчет об ошибке, не требуется. Его основной целью является не попасть в ситуацию, в которой сообщения невозможно доставить трансферу туда и обратно, потому что оба адреса отправителя и получателя недоступны.
Получатели сообщений определяется с помощью команды «RCPT TO: ». Каждый адрес, заключен в угловые скобки. Сообщение может иметь много получателей, и RCPT TO: команда отправляется для каждого из них. Эти RCPT TO: команды, не все в заголовке сообщения, которые прибывают к месту назначения. В случае скрытых копий сообщений или списка адресов серверов получателя не будут отображаться в заголовке вообще.
Каждый получатель признается с ответом «250 OK». Получатель также может быть отклонён при использовании ответа с кодом 550 ответа. Это зависит от того, как сервер был настроен. Удаленный доступ к серверам провайдера SMTP может принять каждую команду RCPT TO:, даже если указанный адрес, является недействительным, так как сервер не знает, что адрес неверный, пока он не сделаеь поиск DNS на нём. Тем не менее, почтовый сервер, предназначенный для приема сообщений для локальных пользователей или конкретного домена будет отвергать почту для адресов, которые не находятся в этой области.
Могут быть получены и другие ответы в ответ на RCPT TO: сообщения, что сервер SMTP был полезным. Если адрес неправильный, но сервер не знает правильный адрес он может ответить «251 Пользователь не местный; направит » или «551 Пользователь не местный, попробуйте ». Обратите внимание на различные коды ответов означающих что, сервер направляет сообщение или нет. Эти ответы не являются общими, и почтовый клиент может просто отправить ответ 551 , как ошибку, а не пытаться анализировать альтернативные адреса из текста ответа.
Для полноты картины следует отметить, что команды RCPT TO: могут задавать маршруты, а не просто адреса. Маршрут будет выражаться в виде «RCPT TO:
Текст сообщений.
После того как все получатели были указаны, всё, что остается сделать отправителю отправить сообщение. Сначала он отправляет команду «DATA», а затем ожидает ответа типа: «354 Start вход почты, с конца
В конце сообщения, как указано в ответе указанном выше, период (точка) на линии своих собственных. Таким образом, одной из самых простых, но самых важных вещей,это то что почтовый клиент должен сделать - убедиться, что строка, содержащая один период не появляется в самом тексте. В конце сообщения признается с ответом «250 OK». Стоит отметить, что SMTP ни в малейшей степени не заинтересован в содержании сообщения. Это может быть все что угодно, хотя, строго говоря, сообщения не должны содержать любые символы с ASCII значениями в диапазоне от 128 до 255, а строки текста не должны превышать 1000 знаков. Так же не требуется, чтобы заголовки адреса отправителя и получателя, которые использовали команды SMTP, что делает их лёгкими для сообщений, по всей видимости, пришли от кого-то другого, чем истинный отправитель.
Скорее всего, большинство читающих это руководство уже знакомы с самой часто используемой технологией связи – электронной почтой. Но задумывались ли вы когда-нибудь о том, как на самом деле она работает? В этой статье мы узнаем, как работает эта служба, и что такое POP3, SMTP и IMAP.
POP3 (протокол почтового отделения версия 3) часто используется для связи с удаленным сервером электронной почты и загрузки сообщений на локальный почтовый клиент с последующим удалением его на сервере, к примеру , Thunderbird , Windows Mail, и т.д. Однако обычно почтовые клиенты предлагают выбор – оставлять или нет копии сообщений на сервере. Если вы используете несколько устройств для отправки сообщений, то рекомендуется оставлять эту функцию включенной, в противном случае, на другом устройстве у вас не будет доступа к отправленным сообщениям, которые не были сохранены на удаленном сервере. Также стоит отметить, что POP3 – протокол работающий только в одном направлении, это означает, что данные берутся с удаленного сервера и отправляются на локальный клиент.
Порты POP3, по умолчанию являются такими:
Порт 110 – порт без шифрования
Порт 995 – порт SSL/TLS, также известный как POP3S
Шаг 2 - Различия между POP3 и IMAP, и какие порты у IMAP?
IMAP (протокол прикладного уровня для доступа к электронной почте), также как и POP3 используется для получения сообщений электронной почты на локальный клиент, однако, он имеет существенное отличие – загружаются только лишь заголовки электронных сообщений, сам текст письма остается на сервере. Данный протокол связи работает в две стороны, если происходят изменения на локальном клиенте, они передаются и на сервер. В последнее время IMAP стал более популярным, так как такие гиганты-провайдеры услуг электронной почты, как Gmail, стали рекомендовать использовать его вместо POP3.
Порты IMAP, по умолчанию являются такими:
- Порт 143 – порт без шифрования
- Порт 993 – порт SSL/TLS, также известный как IMAPS
Шаг 3 - SMTP, протокол для исходящей связи по электронной почте
Простой протокол передачи почты (SMTP ), используется для связи с удаленным сервером и последующей отправке сообщений с локального клиента на удаленный сервер, и в конечном итоге на сервер получателя сообщений. На вашем сервере электронной почты, этот процесс контролируется специальной службой (MTA ). Стоит упомянуть, что SMTP используется исключительно для отправки сообщений.
Порты SMTP:
- Порт 25 – порт без шифрования
- Порт 465 – порт SSL/TLS, также известный как SMTPS
Заключение
Надеемся, что теперь у вас появилось ясное понимание того, как работают почтовые протоколы и какие порты они используют. В этом руководстве мы узнали, что такое POP3, SMTP и IMAP и для чего они используются. К примеру, POP3 и IMAP используются для одинаковый целей, но подходят к выполнению этих задач по-разному. IMAP оставляет содержимое письма на сервере, а POP3 скачивает его на ваш компьютер. Также, мы узнали какие стандартные порты у SMTP, POP3 и IMAP.
Протокол SMTP
O В этой главе:
O Основные команды протокола
O Серверы-ретрансляторы
O Непосредственная пересылка
Для доставки почты в большинстве случаев используется протокол SMTP (Simple Mail Transfer Protocol ).
При его создании протокола SMTP разработчиками была допущена грубая ошибка, испортившая немало крови, как системным администраторам, так и простым пользователям. Суть ее заключается в том, что протокол SMTP не требует аутентификации пользователя перед отправкой сообщения, и это позволяет использовать чужие сервера для массовой рассылки.
Современные SMTP-сервера используют различные защитные механизмы, препятствующие отправке корреспонденции неизвестными пользователями. Подробно об этом рассказывается в главе «Почтовый сервер изнутри».
В терминологии SMTP-протокола нет таких понятий как «клиент» и «сервер». Вместо этого говорят об отправителе (sender ) и получателе (receiver ). То, что большинство называют «SMTP-сервером», является одновременно и отправителем, и получателем. Когда клиент устанавливает с ним соединение для передачи письма, сервер выступает в роли получателя, а когда доставляет сообщение абоненту, становится отправителем.
Каждый почтовый ящик представляет собой SMTP-получатель, связавшись с которым напрямую, можно передать сообщение без посредников. Однако такой способ не обрел большой популярности. Связь с далекими узлами может быть медленной и ненадежной, поэтому миссию доставки сообщения удобно возложить на специальный сервер, часто называемый сервером исходящей почты. Если связь с сервером исходящей почты быстрая и надежная, то такой подход вполне оправдан. Напротив, рассылать письма через далекие, тормозные и нестабильно работающее сервера не имеет никакого смыла. В таком случае лучше положить сообщение непосредственно в ящик получателя. Однако немногие почтовые клиенты поддерживают такую возможность.
Приведенный ниже пример демонстрирует, как посредством протокола SMTP отправить абоненту сообщение. Первым шагом необходимо запустить telnet-клиента и, установив соединение с выбранным SMTP-сервером (например, mail.aport.ru) по двадцать пятому порту, дождаться выдачи приглашения.
Рисунок 009 Подключение к серверу mail.aport.ru
Первые три символа возвращенной сервером строки представляют собой код завершения операции. Полный перечень кодов всевозможных ошибок содержится в RFC-821, и здесь не приводится.
Для передачи корреспонденции одного лишь TCP-соединения не достаточно, и необходимо установить еще одно, так называемое SMTP-соединение. Это достигается возвращением ответного приветствия серверу с указанием имени узла клиента (если у него есть имя) или IP-адреса (если у клиента нет имени).
Далеко не всегда требуется указывать свой точный адрес. Часто достаточно ввести произвольную текстовую строку, например “ABDCEF”
· HELO ppp-15.krintel.ru
Ответное приветствие осуществляется командой “HELO
”. Сервер, установив SMTP-соединение, возвращает код успешного завершения операции (250) и в большинстве случаев определяет IP-адрес клиента или его доменное имя.
Следующим шагом требуется указать отправителя сообщения. Для этого необходимо воспользоваться командой «MAIL FROM» с указанием собственного почтового адреса при желании заключенного в угловые скобки.
Например:
· HELO ppp-15.krintel.ru
· 250 camel.mail.ru Hello ppp-15.krintel.ru
· MAIL FROM:«[email protected]»
Затем указывается получатель сообщения, передаваемый с помощью команды “RCPT TO”, пример использования которой продемонстрирован ниже:
· HELO ppp-15.krintel.ru
· 250 camel.mail.ru Hello ppp-15.krintel.ru
· MAIL FROM:«[email protected]»
· 250 «[email protected]» is syntactically correct
· RCPT TO:«[email protected]»
При возникновении потребности в отправке одного и того же сообщения нескольким респондентам, достаточно вызвать “RCPT TO” еще один (или более) раз (максимальное количество получателей обычно не ограничено). Если кому-то из них сервер не возьмется доставить сообщение, он вернет ошибку, никак, однако не сказывающуюся на остальных получателях.
Команда “DATA”, вызываемая без аргументов, переводит сервер в ожидание получения текста письма.
· 354 Enter message, ending with "." on a line by itself
Последовательность завершения ввода представляет собой обыкновенную точку, «окаймленную» с двух сторон переносами строк. Если такая последовательность встретится в тексте сообщения, формирование письма будет немедленно завершено. Почтовые клиенты, обычно распознают такую ситуацию и прибегают к перекодировке, но при работе с telnet-клиентом эта забота ложиться на пользователя.
Пример использования команды “DATA” приведен ниже:
· HELO ppp-15.krintel.ru
· 250 camel.mail.ru Hello ppp-15.krintel.ru
· MAIL FROM:«[email protected]»
· 250 «[email protected]» is syntactically correct
· RCPT TO:«[email protected]»
· 250 «[email protected]» verified
· Hello, Sailor!
· 250 OK id=12ZDEd-000Eks-00
Команда “QUIT” завершает сеанс и закрывает соединение.
· 221 camel.mail.ru closing connection
Содержимое полученного сообщения (механизм получения сообщений на локальный компьютер пользователя рассмотрен в главах «Протокол POP» и «Протокол IMAP4») может выглядеть, например, следующим образом:
· From [email protected] Sun Mar 26 17:38:03 2000
· Received: from ppp-15.krintel.ru ()
· by camel.mail.ru with smtp (Exim 3.02 #107)
· id 12ZDEd-000Eks-00
· Message-Id: «[email protected]»
· From: [email protected]
· Hello,Sailor!
Ниже будет показано, каким образом злоумышленники находят и используют чужие сервера исходящей почты. Один из способов поиска общедоступных SMTP-серверов заключается в анализе заголовков приходящей корреспонденции. Среди узлов, оставивших свои адреса в поле “Received”, порой встречаются сервера, которые не требуют аутентификации пользователя для отправки писем.
Например, ниже показан заголовок письма, вытащенного автором этой книги из его собственного почтового ящика:
· From [email protected] Wed Mar 22 16:57:03 2000
· Received: from gate.chiti.uch.net ()
· by msk2.mail.ru with esmtp (Exim 3.02 #116)
· id 12Xld1-0008jx-00
· Received: from 13.chiti.uch.net ()
· by gate.chiti.uch.net (8.8.8/8.8.8) with SMTP id PAA29678
· From: "irt" «[email protected] »
Анализ заголовка позволяет установить, что письмо было отправлено с адреса 13.chiti.uch.net через сервер исходящей почты gate.chiti.uch.net. Если попробовать установить с ним соединение, то результат может выглядеть так:
Для проверки возможности пересылки сообщения необходимо послать серверу приглашение, а затем идентифицировать отправителя и получателя письма. Например, это может выглядеть так:
· HELO kpnc.krintel.ru
· 250 gate.chiti.uch.net Hello kpnc.krintel.ru , pleased to meet you
· MAIL FROM:«[email protected]»
· 250 «[email protected]»… Sender ok
· RCPT TO:«[email protected]»
· 250 «[email protected]»… Recipient ok
Код успешного завершения операции (250) и срока «Recipient ok» свидетельствуют о том, что сервер согласился на пересылку. Остается ввести текст послания и можно отправлять письмо. Спустя какое-то время (обычно не превышающее одной минуты) сообщение должно прийти по назначению. А его заголовок может выглядеть, например, так:
· From [email protected] Sun Mar 26 17:28:33 2000
· Received: from gate.chiti.uch.net ()
· by camel.mail.ru with esmtp (Exim 3.02 #107)
· id 12ZD5a-000Dhm-00
· Received: from kpnc.krintel.ru (kpnc.krintel.ru )
· by gate.chiti.uch.net (8.8.8/8.8.8) with SMTP id QAA02468
· (envelope-from [email protected])
· From: [email protected]
· Message-Id: «[email protected]»
Жирным шрифтом выделен адрес отправителя, показывая, что он не смог остаться анонимным. Если это оказывается неприемлемо, среди входящих писем своего почтового ящика можно попробовать отыскать такие, в чьих заголовках нет никаких сведений об отправителе, за исключением той информации, которую он пожелал сообщить сам.
Один из анонимных серверов расположен (точнее, был когда-то расположен на момент написания этой главы) по адресу dore.on.ru. Однако его использование посторонними лицами запрещено, что и демонстрирует следующий эксперимент:
· HELO kpnc.krintel.ru
· MAIL FROM:«[email protected]»
· 250 «[email protected]» Sender Ok
· RCPT TO:«[email protected]»
· 550 Relaying denied for «[email protected]»
Сервер, действительно, не делает никаких видимых попыток определить адрес клиента, но в то же время пересылать его корреспонденцию за пределы сервера наотрез отказывается. Причем достоверно известно, что владельцы этого сервера используют его для рассылки сообщений по нелокальным адресам. Отсюда вытекает существование механизма, позволяющего отличить «своих» от «чужих». Права «чужих» ограничиваются доставкой писем по локальным адресам, а «своим» разрешается отправлять сообщения и за пределы сервера. Ввиду отсутствия в протоколе SMTP средств аутентификации пользователей, отличить одних от других помогает IP адрес клиента. Локальные пользователи, находящиеся в одной подсети с сервером, считаются «своими», и наоборот .
Но если сервер не снабжен функцией определения IP адреса клиентов, ему не остается ничего другого, кроме как воспользоваться информацией, предоставленной самим отправителем, поверив тому на слово. Поэтому, существует возможность сообщения подложных данных, и, выдачи себя за локального пользователя, имеющего право отправки сообщений по любому адресу.
Клиент дважды указывает свой адрес: приветствуя сервер, командой “HELO” он сообщает свой домен, а в поле “MAIL FROM” приводит собственный обратный адрес. Некоторые сервера проверяют одно из этих значений, а некоторые оба одновременно.
В эксперименте, приведенном ниже, отправитель сообщает не свой собственный домен, а домен владельца сервера, и в качестве обратного адреса, использует один из адресов локальных пользователей сервера (чтобы его узнать, необходимо получить с этого сервера хотя бы одно письмо, или попробовать выяснить имена зарегистрированных пользователей методом перебора):
· 220 WITHELD FTGate server ready -Fox Mulder
· HELO dore.on.ru
· MAIL FROM:«[email protected]»
· RCPT TO:«[email protected]»
· 250 Recipient Ok
В результате такого подлога, сервер оказался введен в заблуждение и согласился доставить письмо. Очевидно, подлинный отправитель сообщения не может быть установлен по заголовку, поскольку в нем находится только та информация, которую отправитель пожелал оставить самостоятельно.
Для массовой рассылки лучшего способа и придумать невозможно, но вот для обычной переписки такая методика не подходит. Ведь ответ на письмо возвратится по адресу [email protected]! Этого можно избежать, если добавить в заголовок поле “Reply-To”, содержащее истинный адрес отправителя (тот, который он захотел оставить сам). Это может выглядеть, например, таким образом:
· 220 WITHELD FTGate server ready -Fox Mulder
· HELO dore.on.ru
· MAIL FROM:«[email protected]»
· 250 «[email protected]» Sender Ok
· RCPT TO:«[email protected]»
· 250 Recipient Ok
· 354 Start mail input; end with «CRLF».«CRLF»
· Reply-To:«[email protected]»
· 250 Ok Message queued
· 221 dore.on.ru Service closing transmission channel
Заголовок такого письма должен выглядеть приблизительно так:
· Received: from relay1.aha.ru ( verified)
· by aha.ru (CommuniGate Pro SMTP 3.1b2)
· Received: from warlock.miem.edu.ru (miem-as.ins.ru )
· by relay1.aha.ru (8.9.3/8.9.3/aha-r/0.04B) with ESMTP id UAA07173
· Received: from dore.miem.edu.ru (rtuis.miem.edu.ru )
· by warlock.miem.edu.ru (8.9.3/8.9.3) with ESMTP id UAA00637
· Received: from fox by dore.on.ru (FTGate 2, 1, 2, 1);
· Message-ID: «000301bec6ff$c87f5220$16fe7dc1@fox»
· From: «[email protected]»
· To: «[email protected]»
· Subject: TEST
· Reply-To:«[email protected]»
При попытке ответить отправителю, почтовый клиент получателя извлечет содержимое поля “Reply-To” и отправит письмо по указанному в нем адресу. Именно этим и пользуются спамеры для достижения полной анонимности с одной стороны, и возможности получения ответов от заинтересованных лиц - с другой.
Если внимательно посмотреть на заголовок письма, в нем можно обнаружить несколько строк “Received”. Их оставили транзитные сервера, иначе называемые Релеями (от английского relay ).
Любой почтовый клиент может отправить письмо напрямую. Однако для этого придется собственноручно указать в настойках сервера исходящей почты адрес получателя.
Например, чтобы отправить письмо для [email protected] с помощью “OutLock Express” придется зайти в «Учетные записи» (меню «Сервис»), выбрать «Свойства» и перейти к закладке «Серверы», задав для исходящей почты сервер «computerra.ru».
Очевидно, это слишком утомительно и непрактично. До тех пор, пока программное обеспечение не научиться выполнять такую операцию автоматически, пользователи будут вынуждены пользоваться прежними методами.
Работа типичного мелкокорпоративного сервера исходящей почты выглядит приблизительно так: получив в свое распоряжение письмо, он тут же устанавливает соединение с почтовым ящиком получателя, и отправляет послание. При этом он сталкивается с теми же затруднениями, что и обычный клиент. Поэтому, широко используется ретрансляция сообщений. Если письмо по каким-то причинам не может быть передано напрямую, оно передается ретранслятору.
Ретранслятор - точно такой же SMTP-сервер, как и все остальные, обсуждаемые в этой главе. В зависимости от настоек сервера маршрут пересылки письма может варьироваться. Одно сообщение может отправляться напрямую, а другое - долго «крутиться» на Релеях. Доверие это прекрасно, но только когда не касается вопросов безопасности. Кто рискнет доверять ретрансляторам неизвестного происхождения? Тем более, дальнейший маршрут письма каждым из транзитных серверов определяется самостоятельно, и нет никаких гарантий, что в эту цепочку не вклиниться злоумышленник.
Но протокол SMTP позволяет отправителю самостоятельно задавать маршрут пересылки сообщения Параметр команды “RCPT TO” может содержать не только адрес получателя, но и путь ретрансляции!
Формат его следующий:
· RCPT TO:«@s1,@s2,@s3,@sn:name@host»
где s1,s2,s3,sn - имена (или IP адреса) промежуточных хвостов, а name@host почтовый ящик получателя. В первую очередь сообщение передается узлу s1 - самому левому серверу в цепочке. Он модифицирует параметр команды RCPT TO, «выкусывая» из нее имя своего узла:
· RCPT TO:«@s2,@s3,@sn:name@host»
Затем, извлекается адрес следующего получателя - s2. Если сервер s1 не берется за доставку корреспонденции серверу s2, письмо возвращается назад отправителю с сообщением об ошибке. В противном случае процесс повторяется до тех пор, пока сообщение не окажется в почтовом ящике получателя.
Недостаток такой схемы заключается в том, что некоторые SMTP сервера для пересылки на очередной хвост могут прибегать к услугам своих собственных ретрансляторов. Таким образом, гарантируется, что письмо при успешной доставке посетит все заданные узлы в указанном порядке. Но не всегда выполняется прямая пересылка между соседними хвостами в цепочке.
Поэтому, задача подбора транзитных серверов осложняется. Каждый из них должен быть не только защищен от посторонних вторжений, но заведомо не пользоваться услугами сторонних ретрансляторов.
К сожалению, большинство почтовых клиентов, проверяя корректность ввода адреса получателя, считают такую операцию синтаксически неправильной и отказываются отправлять письмо. Приходится в очередной раз запускать telnet и передавать сообщение вручную.
Узнать какие именно команды поддерживаются конкретным SMTP сервером можно с помощью «HELP», а подробнее о назначении каждой из них “HELP command”.
Для получения детальной информации о командах протокола SMTP можно обратиться к RFC-788, RFC-821, RFC-822, RFC-1341, RFC-1342, RFC-1426, RFC-1521, RFC-1806, RFC-1830, RFC-2045, RFC-2046, RFC-2047, RFC-2048, RFC-2049, RFC-2076.
Из книги Техника сетевых атак автора Касперски КрисПротокол SMTP O В этой главе:O Основные команды протоколаO Серверы-ретрансляторыO Непосредственная пересылкаO Автоматизация почтовой рассылки и спамO Анонимная рассылка писемДля доставки почты в большинстве случаев используется протокол SMTP (Simple Mail Transfer Protocol).При его
автора Реймонд Эрик Стивен5.3.1. Учебный пример: SMTP, простой протокол передачи почты В примере 5.7. иллюстрируется транзакция SMTP (Simple Mail Transfer Protocol - простой протокол передачи почты), который описан в спецификации RFC 2821. В данном примере строки, начинающиеся с С:, отправляются почтовым транспортным
Из книги Искусство программирования для Unix автора Реймонд Эрик Стивен5.3.1. Учебный пример: SMTP, простой протокол передачи почты В примере 5.7. иллюстрируется транзакция SMTP (Simple Mail Transfer Protocol - простой протокол передачи почты), который описан в спецификации RFC 2821. В данном примере строки, начинающиеся с C:, отправляются почтовым транспортным
Из книги TCP/IP Архитектура, протоколы, реализация (включая IP версии 6 и IP Security) автора Фейт Сидни М5.24 Протокол ARP Перед тем как датаграмма будет передана с одной системы локальной сети на другую, она будет обрамлена заголовком и завершающей частью кадра. Кадр доставляется на сетевой адаптер, физический адрес которого совпадает с физическим адресом назначения из
Из книги Программирование на языке Ruby [Идеология языка, теория и практика применения] автора Фултон Хэл8.9 Протокол RIP Наиболее широко используемым протоколом IGP является RIP, заимствованный из протокола маршрутизации сетевой системы компании Xerox (Xerox Network System - XNS). Популярность RIP основана на его простоте и доступности.RIP был первоначально реализован в TCP/IP операционной
Из книги Сетевые средства Linux автора Смит Родерик В.8.17 Протокол BGP В Интернете широко используется протокол граничного шлюза (Border Gateway Protocol - BGP). Текущей версией протокола является BGP-4.В современном Интернете существует множество провайдеров, объединенных между собой на манер сети межсоединений. При движении к точке
Из книги автора14.6 Протокол FTP С протоколом FTP связаны следующие понятия:? Команды и их параметры, пересылаемые по управляющему соединению? Числовые коды, возвращенные в ответ на команду? Формат пересылаемых данныхНиже рассмотрен набор команд FTP. Они передаются по управляющему
Из книги автора15.17 Протокол NFS Последней реализацией NFS является версия 3, хотя продолжают успешно применяться реализации версии 2. Программа NFS сервера имеет номер 100003 и, по соглашению, NFS захватывает при инициализации порт
Из книги автора16.9 Команды SMTP Сценарий из раздела 16.6.1 содержал наиболее часто используемые команды SMTP. Полный набор команд SMTP представлен в таблице 16.1.Таблица 16.1 Команды SMTP Команда Описание HELO Идентифицирует отправителя для получателя. MAIL FROM Начало почтовой транзакции и указание на
Из книги автора16.12.2 Диалог в улучшенной версии SMTP Показанный ниже пример демонстрирует, как улучшенный агент пересылки почты формирует транзакцию для отправки сообщения MIME в 8-битном формате:? Получатель объявляет о своих улучшенных возможностях, включая 8BITMIME.? Команда MAIL FROM имеет
Программы, реализующие сервер SMTP в системе Linux sendmail. В составе системы Linux часто поставляется наиболее популярный в настоящее время почтовый сервер sendmail. Этот пакет предоставляет обширные возможности и многие программы по умолчанию считают, что он установлен в
Из книги автора Из книги автораСпециальные функции сервера SMTP В последующих разделах описываются различные характеристики почтового сервера, которые задаются при его настройке. Чтобы не описывать эти характеристики для каждого сервера, рассмотрим их
В этой статье рассмотрены наиболее часто используемые протоколы электронной почты в Интернете - POP3, IMAP и SMTP. Каждый из них имеет определенную функцию и способ работы. В содержании статьи разъясняется, какая конфигурация лучше всего подходит для конкретных потребностей пользователя при использовании e-mail-клиента. А также раскрывается ответ на вопрос о том, какой протокол поддерживает электронную почту e-mail.
Что такое POP3?
Протокол третьей версии (POP3) — это стандартный почтовый протокол, используемый для приема электронной почты с удаленного сервера на локальный почтовый клиент. Позволяет загружать сообщения на ваш локальный компьютер и читать их, даже если пользователь находится в автономном режиме. Обратите внимание, что при использовании протокола POP3 для подключения к вашей учетной записи сообщения загружаются локально и удаляются с сервера электронной почты.
По умолчанию протокол POP3 работает на двух портах:
порт 110 — это незашифрованный порт POP3;
порт 995 — его нужно использовать, если вы хотите безопасно подключиться к POP3.
Что такое IMAP?
Протокол доступа к интернет-сообщениям (IMAP) — это протокол получения сообщений электронной почты, используемый для доступа к ней на удаленном веб-сервере от локального клиента. IMAP и POP3 являются двумя наиболее часто используемыми протоколами для получения писем и поддерживаются всеми современными почтовыми клиентами и веб-серверами.
Протокол POP3 предполагает, что ваш адрес электронной почты доступен только из одного приложения, а IMAP позволяет совершить одновременный вход сразу с нескольких клиентов. Вот почему IMAP подойдет лучше, если вы собираетесь получать доступ к своей электронной почте из разных мест или если ваши сообщения управляются несколькими пользователями.
Протокол IMAP работает на двух портах:
порт 143 - это незашифрованный порт IMAP по умолчанию;
порт 993 - его необходимо использовать, если вы хотите безопасно подключиться с помощью IMAP.
Что такое SMTP?
Протокол - это стандартный протокол для отправки электронной почты через Интернет.
SMTP работает в трех портах:
порт 25 — это незашифрованный по умолчанию;
порт 2525 — он открывается на всех серверах SiteGround, если порт 25 фильтруется (например, вашим интернет-провайдером), и вы хотите отправлять незашифрованные электронные письма с помощью SMTP;
порт 465 — он используется, если вы хотите безопасно отправлять сообщения с помощью SMTP.
По каким протоколам происходит обмен электронной почтой? Понятия и термины
Термин «сервер электронной почты» относится к двум серверам, необходимым для отправки и получения писем, то есть к SMTP и POP.
Сервер входящей почты — это сервер, связанный с вашей учетной записью адреса электронной почты. Для нее не может быть более одного входящего почтового сервера. Для доступа к входящим сообщениям необходим почтовый клиент — программа, которая может получать электронную почту из учетной записи, позволяя пользователю читать, пересылать, удалять и отвечать на сообщения. В зависимости от вашего сервера, вы можете использовать выделенный почтовый клиент (например, Outlook Express) или веб-браузер. Так, Internet Explorer применяют для доступа к учетным записям на основе электронной почты. Письма хранятся на сервере входящей почты до его загрузки. После того, как вы загрузили свою почту с почтового сервера, сделать повторно это будет нельзя. Чтобы успешно загрузить данные, необходимо ввести правильные настройки в электронной почтовой программе. Большинство входящих почтовых серверов используют один из следующих протоколов: IMAP, POP3, HTTP.
Исходящий почтовый сервер (SMTP)
Это сервер, используемый только для отправки писем (для переноса их из вашей почтовой клиентской программы в приемник). Большинство исходящих почтовых серверов используют Protocol) для отправки корреспонденции. В зависимости от ваших сетевых параметров сервер исходящей почты может принадлежать вашему интернет-провайдеру или серверу, на котором вы настраиваете свою учетную запись. В качестве альтернативы вы можете использовать SMTP-сервер на основе подписки, который позволит вам отправлять электронные письма с любой учетной записи. Из-за проблем со спамом большинство исходящих почтовых серверов не позволяют отправлять электронные письма, если вы не вошли в свою сеть. Сервер с открытым ретранслятором позволит вам использовать его для отправки электронных писем, независимо от того, принадлежите ли вы к его сетевой группе или нет.
Порты электронной почты
Для сетей порт означает конечную точку логического соединения. Номер порта определяет его тип. Ниже перечислены порты электронной почты по умолчанию:
POP3 - порт 110;
IMAP - порт 143;
SMTP - порт 25;
HTTP - порт 80;
безопасный SMTP (SSMTP) - порт 465;
безопасный IMAP (IMAP4-SSL) - порт 585;
IMAP4 через SSL (IMAPS) - порт 993;
Secure POP3 (SSL-POP) - порт 995.
Протоколы электронной почты: IMAP, POP3, SMTP и HTTP
В основном протокол относится к стандартному методу, используемому на каждом конце канала связи. Чтобы иметь дело с электронной почтой, вы должны использовать специальный клиент для доступа к почтовому серверу. В свою очередь, они могут обмениваться информацией друг с другом, используя при этом совершенно различные протоколы.
Протокол IMAP
IMAP (протокол доступа к интернет-сообщениям) - стандартный протокол для доступа к электронной почте с вашего локального сервера. IMAP - это протокол типа «клиент/сервер», в котором электронная почта получена, и данные сохраняются вашим интернет-сервером. Поскольку для этого требуется только небольшая передача данных, он хорошо работает даже при медленном соединении, например, при подключении с помощью модема. При попытке прочитать конкретное сообщение электронной почты клиент загружает данные с сервера. Вы также можете создавать и управлять папками или почтовыми ящиками на сервере, удалять сообщения.
Протокол POP3
Протокол передачи электронной почты POP (Post Office Protocol 3) обеспечивает простой, стандартизированный способ доступа пользователей к почтовым ящикам и загрузки сообщений на их компьютеры.
При использовании протокола POP все ваши сообщения электронной почты будут загружены с почтового сервера на локальный компьютер. Вы также можете оставить копии своих электронных писем на сервере. Преимущество заключается в том, что после загрузки ваших сообщений вы можете отключить интернет-соединение и прочитать свой e-mail на досуге, не прибегая к дополнительным расходам на связь. С другой стороны, с помощью этого протокола вы получаете и загружаете много нежелательных сообщений (включая спам или вирусы).
Протокол SMTP
Протокол используется агентом передачи почты (MTA) для доставки электронных сообщений на определенный сервер получателя. SMTP можно использовать только для отправки электронных писем, а не для их получения. В зависимости от настроек вашей сети или интернет-провайдера вы можете использовать SMTP-протокол только в определенных условиях.
Протоколы HTTP
HTTP не является протоколом, предназначенным для связи по электронной почте, но его можно использовать для доступа к вашему почтовому ящику. Его также нередко называют веб-электронной почтой. Он может использоваться для составления или получения электронных писем из вашей учетной записи. Hotmail - хороший пример использования HTTP в качестве протокола электронной почты.
Управляемые передачи файлов и сетевые решения
Ваша способность отправлять и получать электронную почту в основном обусловлена тремя протоколами TCP. Ими являются SMTP, IMAP и POP3.
SMTP
Начнем с SMTP, потому что его основная функция отличается от двух других. Протокол SMTP, или Simple Mail Transfer Protocol, в основном используется для отправки электронной почты от почтового клиента (например, Microsoft Outlook, Thunderbird или Apple Mail) на сервер электронной почты. Он также используется для ретрансляции или пересылки почтовых сообщений с одного почтового сервера на другой. Это необходимо в случае, если у отправителя и получателя есть разные поставщики услуг электронной почты.
SMTP, который указан в RFC 5321, использует порт 25 по умолчанию. Он также может использовать порт 587 и порт 465. Последний, который был представлен как порт выбора для безопасного SMTP (a.k.a. SMTPS), считается устаревшим. Но на самом деле он по-прежнему используется несколькими поставщиками почтовых услуг.
POP3
Протокол почтового отделения, или POP, используется для извлечения сообщений электронной почты с Последняя версия, которая широко используется, - это версия 3, отсюда и термин «POP3».
POP, версия 3, указанная в RFC 1939, поддерживает расширения и несколько механизмов аутентификации. Функции проверки подлинности необходимы, чтобы злоумышленники не получали доступ к сообщениям пользователей.
Клиент POP3 получает электронную почту следующим образом:
подключается к почтовому серверу через порт 143 (или 993 для соединений SSL / TLS);
извлекает сообщения электронной почты;
служит для подключения до закрытия приложения почтового клиента и загрузки сообщений по требованию.
подключается к почтовому серверу на порту 110 (или 995 для соединений SSL/TLS);
удаляет копии сообщений, хранящихся на сервере;
отключается от сервера.
Хотя клиенты POP могут быть настроены так, чтобы сервер мог продолжать хранить копии загруженных сообщений, описанные выше шаги являются обычной практикой.
IMAP
IMAP, особенно текущая версия (IMAP4), является более сложным протоколом. Это позволяет пользователям группировать связанные сообщения и размещать их в папках, которые, в свою очередь, могут быть организованы иерархически. Он также оснащен флагами сообщений, которые указывают, было ли сообщение прочитано, удалено или получено. Он даже позволяет пользователям выполнять поиск по почтовым ящикам сервера.
Логика работы (настройки imap4):
Обратите внимание, что сообщения не удаляются на сервере. Это может иметь серьезные последствия. Спецификации IMAP можно найти в RFC 3501.
Выбор между IMAP и POP3
Поскольку основная функция SMTP принципиально отлична, дилемма выбора лучшего протокола обычно включает только IMAP и POP3.
Если для вас важно место для хранения на сервере, то выбирайте POP3. Сервер с ограниченным объемом памяти является одним из основных факторов, которые могут заставить вас поддержать POP3. Поскольку IMAP оставляет сообщения на сервере, он может потреблять пространство памяти быстрее, чем POP3.
Если вы хотите получить доступ к почте в любое время, то лучше остановиться на IMAP. Есть одна веская причина, по которой IMAP был предназначен для хранения сообщений на сервере. Он используется для поиска сообщений с нескольких устройств — иногда даже одновременно. Поэтому если у вас есть iPhone, планшет Android, ноутбук и рабочий стол и вы хотите читать электронную почту с любого или всех этих устройств, то IMAP будет лучшим выбором.
Синхронизация - еще одно преимущество IMAP. Если вы получаете доступ к сообщениям электронной почты с нескольких устройств, скорее всего, захотите, чтобы все они отображали любые действия, которые вы выполняли.
Например, если вы читаете сообщения A, B и C, то хотите, чтобы они также были помечены как «прочитанные» на других устройствах. Если вы удалили письма B и C, то захотите, чтобы те же сообщения удалялись из вашего почтового ящика на всех гаджетах. Все эти синхронизации могут быть достигнуты только в том случае, если вы используете IMAP.
Поскольку IMAP позволяет пользователям упорядочивать сообщения в иерархическом порядке и размещать их в папках, это помогает пользователям лучше организовывать свою корреспонденцию.
Разумеется, все функциональные возможности IMAP имеют свою цену. Эти решения сложнее реализовать, и в конечном итоге протокол потребляет намного больше ЦП и ОЗУ, особенно когда он выполняет процесс синхронизации. Фактически высокая загрузка процессора и памяти может произойти как на стороне клиента, так и на стороне сервера, если есть тонна сообщений для синхронизации. С этой точки зрения протокол POP3 менее затратен, хотя и менее функционален.
Конфиденциальность также является одной из проблем, которая будет сильно зависеть от конечных пользователей. Они, как правило, предпочли бы загружать все сообщения электронной почты и не оставлять их копии на неизвестном сервере.
Скорость — преимущество, которое варьируется и зависит от ситуации. POP3 имеет возможность загружать все почтовые сообщения при подключении. А IMAP может при необходимости (например, при недостаточном количестве трафика) загружать только заголовки сообщений или определенные части и оставлять вложения на сервере. Только когда пользователь решит, что оставшиеся части стоят загрузки, они станут доступны для него. Поэтому IMAP можно считать более быстрым.
Однако если все сообщения на сервере должны загружаться каждый раз, то POP3 будет работать гораздо быстрее.
Как вы можете увидеть, каждый из описываемых протоколов имеет свои преимущества и недостатки. Вам решать, какие функции или возможности важнее.
Также желаемый способ доступа к e-mail-клиенту определяет предпочтительность протокола. Пользователи, работающие только с одной машины и использующие веб-почту для доступа к своим новым электронным письмам, оценят POP3.
Однако пользователи, которые обмениваются почтовыми ящиками или получают доступ к своим электронным письмам с разных компьютеров, предпочтут IMAP.
Спам-брандмауэры с SMTP, IMAP и POP3
Большинство брандмауэров для спама имеют дело только с протоколом SMTP и защищают его. Серверы отправляют и получают электронную почту SMTP, и они будут проверяться спамом-брандмауэром на шлюзе. Однако некоторые брандмауэры для спама дают возможность защищать POP3 и IMAP4, когда внешним пользователям нужны эти службы для доступа к их электронной почте.
Брандмауэры SMTP прозрачны для конечных пользователей; для клиентов нет изменений конфигурации. Пользователи по-прежнему получают и отправляют почтовые сообщения на сервер электронной почты. Так, Exchange или Dominos должны настраивать маршрутизацию сообщений на брандмауэр на основе прокси-сервера при отправке электронной почты, а также обеспечивать возможность отправки писем с брандмауэра.
