И другие агенты пересылки сообщений используют 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-операция состоит из трёх последовательностей команда/ответ (см. пример ниже). Описание последовательностей:
Помимо промежуточных ответов для 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 - всего лишь протокол доставки. Он не может по требованию взять сообщения с удаленного сервера. Для извлечения почты и управления почтовым ящиком разработаны другие протоколы, такие как POP и IMAP. Тем не менее, SMTP предоставляет возможность начать на удаленном сервере обработку очереди сообщений, при которой запрашивающая система может получать все направленные ей сообщения (см. Remote Message Queue Starting ниже). POP и IMAP предпочтительны, когда компьютер пользователя включен не постоянно, или же временно подключен к Интернету.
Remote Message Queue Starting (запуск удаленной очереди сообщений) - особенность SMTP, позволяющая удаленнному хосту начать обработку очереди сообщений на сервере так, что он может получать предназначенные ему сообщения с помощью команды TURN. Однако эта особенность считалась небезопасной и была расширена в RFC 1985 командой ETRN, которая работает надёжнее благодаря основанному на информации DNS методу аутентификации .
ODMR (On-Demand Mail Relay - ретрансляция почты по требованию) - стандартизированное в RFC 2645 SMTP-расширение, позволяющее проводить ретрансляцию сообщения аутентифицированному пользователю.
Многие пользователи, чей набор символов отличается от латиницы, сталкиваются с требованием адреса электронной почты на латинице. Для решения этой проблемы был создан RFC 6531 , предоставляющий возможности для интернационализации для SMTP - расширение SMTPUTF8. RFC 6531 предоставляет поддержку многобайтных и не-ASCII символов в почтовом адресе, например: δοκιμή@παράδειγμα.δοκιμή или 测试@测试.测试. Текущая поддержка ограничена, но есть большой интерес в широком распространении RFC 6531 и связанных с ним RFC в странах с обширной базой пользователей, для которых латиница не является родным алфавитом.
Почтовый клиент должен знать IP-адрес SMTP-сервера, который задается как часть конфигурации (обыкновенно в виде DNS-имени). Сервер будет доставлять исходящие сообщения от лица пользователя.
Администраторам сервера необходимо контролировать то, какие клиенты могут использовать сервер. Это позволяет им бороться с такими злоупотреблениями, как спам. Обычно используются два решения:
В этом случае SMTP-сервер интернет-провайдера не разрешит допуск пользователям «за пределами» сети провайдера. Точнее, сервер может допустить лишь тех пользователей, чей IP-адрес предоставлен данным провайдером, что эквивалентно требованию соединения с Интернетом с помощью этого провайдера. Мобильный пользователь часто может оказаться в сети, отличной от сети своего провайдера, и потому сообщения не будут отправляться.
У данной системы есть несколько разновидностей. Например, SMTP-сервер организации может предоставлять доступ только пользователям той же сети, блокируя остальных пользователей. Также сервер может проводить ряд проверок клиентского IP-адреса. Эти методы обычно использовались организациями и учреждениями, например университетами, для внутреннего пользования сервером. Однако, большая их часть теперь использует описанные ниже методы аутентификации.
Благодаря ограничению доступа определенным адресам, администраторы сервера могут легко определить адрес любого злоумышленника. Если пользователь может использовать различные провайдеры для соединения с Интернетом, этот вид ограничения становится нецелесообразным, а изменение настроенного адреса SMTP-сервера исходящей почты непрактично. Крайне желательно иметь возможность использовать такую информацию о настройках клиента, которая не нуждается в изменении.
Вместо описанного ранее ограничения по местоположению, современные SMTP-сервера обычно требуют аутентификацию пользователей перед получением доступа. Эта система, будучи более гибкой, поддерживает мобильных пользователей и предоставляет им фиксированный выбор настроенного сервера исходящей почты.
Сервер, доступный для широкой сети и не предоставляющий эти виды ограничения доступа, называют открытым релеем . Сейчас такие сервера считаются дурным тоном.
Администраторы сервера выбирают, какой порт будут использовать клиенты для ретрансляции исходящей почты - 25 или 587. Спецификации и многие сервера поддерживают и тот, и другой порты. Хотя некоторые сервера поддерживают порт 465 для безопасного SMTP,но предпочтительнее использовать стандартные порты и ESMTP-команды, если необходима защищенная сессия между клиентом и сервером.
Некоторые сервера настроены на отклонение всех ретрансляций по порту 25, но пользователям, прошедшим аутентификацию по порту 587, позволено перенаправлять сообщения на любой действительный адрес.
Некоторые провайдеры перехватывают порт 25, перенаправляя трафик на свой собственный SMTP-сервер вне зависимости от адреса назначения. Таким образом, их пользователи не могут получить доступ к серверу за пределами провайдерской сети по порту 25.
Некоторые сервера поддерживают аутентифицированный доступ по дополнительному, отличному от 25, порту, позволяя пользователям соединяться с ними, даже если порт 25 заблокирован.
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 не включала средств для аутентификации отправителей. Впоследствии, в 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.
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
SMTP реализуется в современных сетях стандарта TCP/IP. Впервые информация об использовании протокола появилась еще в 1982 г. Несмотря на то, что сервер SMTP может быть использован и для получения сообщений, на сегодняшний день большинство почтовых клиентов используют его только для отправки, предпочитая другие технологии (например, POP или IMAP) для приема информации. Протокол является одним из наиболее популярных и используется подавляющим числом почтовых программ и серверов.
Функция SMTP заключается в проверке правильности указания настроек и параметров для отправки письма. По данному протоколу проходит верификация настроек компьютера пользователя, пытающегося отправить сообщения, а затем производится доставка, если все настройки были выполнены правильно. После этого работа SMTP не заканчивается и сервер дожидается сообщения об успешной доставке данных. Если сообщение по каким-то причинам не может быть доставлено, отправляется соответствующее сообщение отправителю.
Настройка SMTP заключается в установке нужного программного обеспечения и определения адреса сервера, используемого для отправки. Для отправки со стороны пользователя требуется установить программу-клиент, которая умеет передавать письма и связываться с сервером SMTP по протоколу TCP/IP. После этого программа запускается и настраивается на работу с сервисом отправки и получения почты путем указания нужных настроек. Затем пользователь пытается отправить сообщение. Если настройка осуществлена верно, письмо будет доставлено адресату.
Большинство современных сервисов электронной почты уже имеют настроенные серверы для отправки сообщений. Если вы не пользуетесь сторонним программным обеспечением для отправки писем, вы сможете отправить письмо без произведения дополнительных настроек на сайте сервиса, где у вас зарегистрирован аккаунт.
Современные администраторы SMTP-серверов требуют от пользователей прохождения аутентификации перед тем, как они смогут отправить свое сообщение. Пользователю необходимо сначала указать свой логин и пароль на сервере, а лишь затем перейти к отправке. Данная защита используется для блокирования возможности рассылки спама, использующего простые SMTP-протоколы. Ранее же для идентификации в протоколе SMTP использовался уникальный IP-адрес отправителя.
Это простой протокол передачи почты. С английского языка переводится, как Simple Mail Transfer Protocol . Исходя из названия, можно сделать вывод, что SMTP сервер отвечает за отправку почтовых рассылок. Его задача, как правило, состоит из двух основных функций:
Отправляя email сообщения, SMTP-сервер отправителя устанавливает связь с тем сервером, который будет получать это сообщение. Такое "общение" происходит путем отправки и получения команд, формируя SMTP-сессию с неограниченным количеством SMTP-операций. Обязательными командами для каждой операции являются три:
Определение адреса отправителя, получателя и наличие содержимого письма – это обязательные условия, без которых письмо не будет отправлено, даже по обычной, знакомой нам "бумажной" почте. Что уже говорить про электронную.
Если вы планируете заниматься легальным email маркетингом, задумайтесь об использовании внешнего SMTP-сервера для безопасности и скорости рассылки своих массовых email кампаний.
4085/2, Сорокин Д. С. Почтовые протоколы.Методы борьбы со спамом
SMTP (англ. Simple Mail Transfer Protocol - простой протокол передачи почты) - это широко используемый сетевой протокол, предназначенный для передачи электронной почты в сетях TCP/IP.
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-аутентификация обязательно только для последнего.
SMTPS относится к методам защиты SMTP на транспортном уровне. Он предназначен для обеспечения аутентификации сторон, целостности и конфиденциальности данных. SMTPS не является проприетарным протоколом или расширением SMTP, это всего лишь способ обезопасить SMTP на транспортном уровне.
Клиент и сервер используют обычный SMTP на уровне приложений, но соединение защищено SSL или TLS. Это происходит после установления соединения перед отправкой любых почтовых данных.
SMTPS использует 465 порт.
POP3 (англ. Post Office Protocol Version 3 - протокол почтового отделения, версия 3) - стандартный Интернет-протокол прикладного уровня, используемый клиентами электронной почты для извлечения электронного сообщения с удаленного сервера по TCP/IP-соединению. POP и IMAP (Internet Message Access Protocol) - наиболее распространенные Интернет-протоколы для извлечения почты. Практически все современные клиенты и сервера электронной почты поддерживают оба стандарта. Протокол POP был разработан в нескольких версиях, нынешним стандартом является третья версия (POP3). Большинство поставщиков услуг электронной почты (такие как Hotmail, Gmail и Yahoo! Mail) также поддерживают IMAP и POP3. Предыдущие версии протокола (POP, POP2) устарели.
POP поддерживает простые требования «загрузи-и-удали» для доступа к удаленным почтовым ящикам. Хотя большая часть POP-клиентов предоставляют возможность оставить почту на сервере после загрузки, использующие POP клиенты обычно соединяются, извлекают все письма, сохраняют их на пользовательском компьютере как новые сообщения, удаляют их с сервера, после чего разъединяются.
POP3-сервер прослушивает общеизвестный порт 110. Шифрование связи для POP3 запрашивается после запуска протокола, с помощью либо команды STLS (если она поддерживается), либо POP3S, которая соединяется с сервером используя TLS или SSL по TCP-порту 995.
Аргументы | Ограничения | Возможные ответы |
||
Её поддержка не является | * +OK maildrop has n message |
|||
[имя] | * -ERR password suplied for |
|||
обязательной |
||||
[имя] is incorrect |
||||
* +OK name is a valid mailbox |
||||
* -ERR never heard of mailbox |
||||
* +OK maildrop locked and |
||||
Работает после успешной передачи | ||||
* -ERR invalid password |
||||
имени почтового ящика |
||||
* -ERR unable to lock |
||||
[сообщение] | Доступна после успешной | * +OK message deleted |
||
идентификации | * -ERR no such message |
|||
[сообщение] | Доступна после успешной | * +OK scan listing follows |
||
идентификации | * -ERR no such message |
|||
Доступна после успешной | ||||
идентификации |
||||
[сообщение] | Доступна после успешной | * +OK message follows |
||
идентификации | * -ERR no such message |
|||
Доступна после успешной | ||||
идентификации |
||||
Доступна после успешной | ||||
идентификации |
||||
[сообщение] | Доступна после успешной | |||
[количество |
||||
идентификации | * -ERR no such message |
|||
Альтернативным протоколом для сбора сообщений с почтового сервера является IMAP. IMAP (англ. Internet Message Access Protocol) - протокол прикладного уровня для доступа к электронной почте.
Базируется на транспортном протоколе TCP и использует порт 143.
POP3 имеет ряд недостатков, и наиболее серьёзный из них - отсутствие возможностей по управлению перемещением и хранением сообщений на сервере. Сообщения, как правило, загружаются с почтового сервера все сразу, после чего они с сервера удаляются, то есть отсутствует возможность выбирать сообщения для получения.
Для решения проблем, связанных с этой особенностью POP3, в Вашингтонском университете был разработан новый протокол, предполагающий возможность получения пользователями электронной почты из одного почтового ящика из различных мест, при этом сообщения не распределяются между точками получения. Пользователю предоставляется возможность управлять сообщениями в его почтовом ящике и дополнительными функциями по обслуживанию почтовых ящиков на сервере.
При использовании POP3 клиент подключается к серверу только на промежуток времени, необходимый для загрузки новых сообщений. При использовании IMAP соединение не разрывается, пока пользовательский интерфейс активен, а сообщения загружаются только по требованию клиента. Это позволяет уменьшить время отклика для пользователей, в чьих ящиках имеется много сообщений большого объёма.
Протокол POP требует, чтоб текущий клиент был единственным подключенным к ящику. IMAP позволяет одновременный доступ нескольких клиентов к ящику и предоставляет клиенту возможность отслеживать изменения, вносимые другими клиентами, подключенными одновременно с ним.
Благодаря системе флагов, определенной в IMAP4, клиент может отслеживать состояние сообщения (прочитано, отправлен ответ, удалено и т. д.); данные о флагах хранятся на сервере.
Клиенты IMAP4 могут создавать, переименовывать и удалять ящики и перемещать сообщения между ящиками. Кроме того, можно использовать расширение IMAP4 Access Control List (ACL) Extension (RFC 4314) для управления правами доступа к ящикам.
Поиск сообщений происходит на стороне сервера. IMAP4 имеет явный механизм расширения.
Современная спам-рассылка распространяется в сотнях тысяч экземпляров всего за несколько десятков минут. Чаще всего спам идет через зараженные вредоносными программами пользовательские компьютеры - зомби-сети. Что можно противопоставить этому натиску? Современная индустрия IT-безопасности предлагает множество решений, и в арсенале антиспамеров есть различные технологии. Однако ни одна из существующих технологий не является магической «серебряной пулей» против спама. Универсального решения просто не существует. Большинство современных продуктов используют несколько технологий, иначе эффективность продукта будет не высока.
DNSBL - DNS blacklist или DNS blocklist - списки хостов, хранимые с использованием системы архитектуры DNS. Обычно используются для борьбы со спамом. Почтовый сервер обращается к DNSBL, и проверяет в нём наличие IP-адреса клиента, с которого он принимает сообщение. При положительном ответе считается, что происходит попытка приёмаспам-сообщения. Серверу отправителя сообщается ошибка 5xx (неустранимая ошибка) и сообщение не принимается. Почтовый сервер отправителя создаёт «отказную квитанцию» отправителю о недоставке почты.
Существует 2 метода использования данной технологии.
1. Однозначная блокировка - отклонение сообщений, которые пришли с IP адреса находящегося в DNSBL
2. Взвешенный подход. При таком подходе сообщение, пришедшее с IP адреса
находящегося в DNSBL, не блокируется, но этот факт учитывается при классификации «спамности» письма.
При использовании первого подхода все письма с IP адресов, попавших в DNSBL однозначно отклоняются. Независимо от того попал ли IP адрес в черный список заслуженно или же по ошибке (что всё чаще и чаще встречается на практике). Использование второго подхода отлично иллюстрируется opensource спам-фильтром spamassassin. Когда для классификации сообщения применяется взвешенный подход, то есть анализ по множеству критериев. В таком случае нахождение IP адреса отправителя в черном списке не является единственным и результирующим фактором, который влияет на решение о классификации сообщения, что в свою очередь означает снижение количества ложных срабатываний фильтра в тех случаях, когда IP адрес отправителя попал в черный список по нелепой случайности.
Технология предполагает выявление в потоке почты массовых сообщений, которые абсолютно идентичны или различаются незначительно. Для построения работоспособного «массового» анализатора требуются огромные потоки почты, поэтому эту технологию предлагают крупные производители, обладающие значительными объемами почты, которую они могут подвергнуть анализу.
Плюсы: Если технология сработала, то она гарантировано определила массовую рассылку.
Минусы: Во-первых, «большая» рассылка может оказаться не спамом, а вполне легитимной почтой (например, Ozon.ru, Subscribe.ru тысячами расылают практически одинаковые сообщения, но это не спам). Во-вторых, спамеры умеют «пробивать» такую защиту с помощью интеллектуальных технологий. Они используют ПО, генерирующее разный контент - текст, графику и т.п. - в каждом спамерском
SMTP (Simple Message Transfer Protocol), или в дословном переводе простой протокол передачи сообщений, был рожден в среде UNIX и предназначался исключительно для общения между собой почтовых серверов. В терминах модели OSI протокол SMTP находится на уровне приложений.
В настоящее время SMTP стал стандартом де-факто. В большой степени такая популярность объясняется сравнительной простотой реализации и широкими возможностями расширяемости без ущерба для обратной совместимости с существующими версиями почтовых систем. Немаловажным фактором является также широкая доступность спецификаций и отсутствие необходимости отчислять средства за их использование.
SMTP-системы за последнее время активно развивались в следующих направлениях:
расширение протокола общения сервер-сервер (собственно SMTP);
создание и улучшение протокола общения клиент-сервер (POP3, IMAP4);
внедрение и расширение нового формата сообщений (MIME).
Начальная версия протокола SMTP поддерживала ограниченный набор команд и сервисов для приема и передачи сообщений. В последнее время был разработан его расширенный вариант (Extended или ESMTP), обеспечивающий стандартную возможность дальнейшего расширения и поддержку таких функций как подтверждение доставки (Delivery Notification Request или DNR), согласование максимального допустимого размера сообщений, передаваемых между серверами и принудительная инициация передачи накопленной почты (dequeue). Однако одной из слабых сторон на данный момент SMTP было и продолжает быть отсутствие возможности аутентификации входящих соединений, шифрования диалога и потока передачи данных между серверами.
Отсутствие средств аутентификации входящих соединений не позволило использовать SMTP для обслуживания клиентского доступа. Классическая почтовая SMTP-система требует наличия файлового доступа клиента к своему почтовому ящику для получения и работы с сообщениями. Для реализации работы в режиме клиент-сервер был создан протокол обслуживания почтового офиса (Post Office Protocol или POP). Наиболее удачной оказалась версия POP3, широко используемая в современных SMTP-системах. Наиболее продвинутые реализации поддерживают аутентификацию с шифрованием имени и пароля и шифрование трафика по протоколу Secure Socket Layer (SSL). Однако, при использовании протокола POP3 отсутствует возможность просмотра характеристик сообщения без предварительной загрузки его на станцию клиента. Для решения проблемы просмотра и манипуляции свойствами почтового сообщения непосредственно на сервере, а также преодоления ряда других функциональных ограничений был разработан протокол IMAP4, его поддержка в большинстве коммерческих систем ожидается в ближайшем будущем. Следует заметить, что как для случая использования классического клиента (команда mail), так и для случая применения POP3 или IMAP4 отправка подготовленных клиентом сообщений требует наличия сервера SMTP. На рисунке 1.6 приведена схема представления типичной SMTP-системы, использующей как традиционный для ОС UNIX файловый метод доступа к почтовому ящику, так и доступ по протоколам POP3 и IMAP4.
Изначально SMTP-системы рассчитывались на передачу информации исключительно в текстовом виде и не были ориентированы на передачу символов национальных алфавитов, т.е. использовали 7-битный набор символов. Для решения проблемы передачи двоичных файлов был разработан стандарт UUENCODE, позволяющий внедрять предварительно преобразованные из бинарного в текстовый вид произвольные данные непосредственно в текст сообщения. Однако всеобъемлющим данный подход назвать было трудно, ибо в общем случае никакой информации о природе вложения (типе передаваемых данных и породившем их приложении) принимающая сторона не имела. По мере расширения сети Internet, усложнения программного обеспечения и активного внедрения мультимедиа назрела необходимость создания универсального формата типизации и представления двоичных данных и текста, содержащего национальные символы. Таким универсальным форматом стали многофункциональные расширения почты Internet (Multipurpose Internet Mail Extensions или MIME). Формат MIME оказался чрезвычайно удачным, поскольку в него были заложены возможности неограниченного расширения, как поддерживаемых типов данных, так и национальных кодировок.
Схема типичной SMTP-системы с поддержкой POP3 и IMAP4
Сообщение SMTP, подобно сообщению X.400, использует понятия конверта и содержимого, которое в свою очередь имеет заголовок и тело. Функциональное назначение их полностью идентично. Состав полей в заголовке определяется форматом тела сообщения (UUENCODE или MIME). Ни одно поле не является обязательным, но, как правило, указываются такие поля как, кому (To:), от кого (From:) и тема (Subject:). В случае использования формата MIME, в заголовке обязательно должна присутствовать строка "MIME-Version: 1.0". Полный перечень возможных полей в заголовке сообщения SMTP содержится в RFC 2076.
Отличительной особенностью SMTP-систем является то, что в них, как правило, обеспечивается фактическая независимость процесса передачи от формата содержимого. За интерпретацию содержимого должна отвечать только клиентская программа (mail reader). Однако платой за совместимость на уровне MTA в данном случае является неэффективность передачи любых нетекстовых данных или сообщений, использующих символы национальных алфавитов, вследствие предварительной трансляции информации в текстовое представление. В зависимости от используемого алгоритма преобразования размер фактически передаваемых данных может возрасти на 30-100%.
Немаловажной проблемой при передаче данных через SMTP-системы является обеспечение конфиденциальности. Поскольку сообщения передаются в текстовом виде, они могут быть легко перехвачены и произвольным образом изменены. Для решения проблем с защитой информации был создан стандарт на шифрование тела сообщения, так называемый засекреченные многофункциональные расширения почты (Secure MIME или S/MIME). Однако, этот протокол не в состоянии защитить от перехвата заголовки сообщений.
Simple Mail Transfer Protocol не зависит от транспортной среды и может использоваться для доставки почты в сетях с протоколами, отличными от TCP/IP и Х.25. Достигается это за счет концепции IPCE (InterProcess Communication Environment). IPCE позволяет взаимодействовать процессам, поддерживающим SMTP в интерактивном режиме, а не в режиме "STOP-GO".
Модель протокола. Взаимодействие в рамках SMTP строится по принципу двусторонней связи, которая устанавливается между отправителем и получателем почтового сообщения. При этом отправитель инициирует соединение и посылает запросы на обслуживание, а получатель на эти запросы отвечает. Фактически, отправитель выступает в роли клиента, а получатель - сервера.
Схема взаимодействия по протоколу SMTP
Канал связи устанавливается непосредственно между отправителем и получателем сообщения. При таком взаимодействии почта достигает абонента в течение нескольких секунд после отправки.
