Поиски свободного «почтальона Печкина» Часть 1.

Конечно Вы, уважаемый читатель, скажете – да что за ерунда, все они закрыты уже года 2 назад как мера борьбы со спамом. Но! Никто не мешает нам это нам проверить! Более того, эта проверка не преследуется законом.
         Трудясь над этой задачей (а всякий труд, как известно, приносит пользу трудящемуся ) мы сами напишем простые утилитинки демонстрирующие работу с SMTP –сервером, повторим протоколы, сделаем интересные выводы.

Простой протокол передачи почты – Simple Mail Transfer Protocol (SMTP) обычно используется для отправки  письма от отправителя к получателю.

Протокол разрабатывался в начале восьмидесятых годов прошлого века. Окончательная версия была закреплена в RFC 821 1 августа 1982 года. Все годы, прошедшие с того времени, протокол SMTP оставался одним из наиболее часто используемых протоколов семейства TCP/IP .

За это время принципиально изменились многие требования, касающиеся достоверности и защищенности передаваемых сообщений, значительно увеличились средний размер сообщений, и их количество, разнообразнее стала передаваемая информация: это уже не только текстовые сообщения на английском языке – сейчас электронные письма пишутся на многих языках и могут содержать вложения самых разных типов.

Однако протокол SMTP получил за время своего существования такое широкое распространение, что просто заменить его другим протоколом уже не представляется возможным. Вместо этого для него разрабатываются различные расширения ( extensions ), дополняющие возможности базового протокола. Дополненный расширениями протокол SMTP часто называют ESMTP ( Extended SMTP ).

Сам протокол изменился незначительно. На смену команде HELO , использовавшейся для начала диалога, пришла команда EHLO , позволяющая работать с расширениями ESMTP . Команды, применяемые для настройки почтовых систем и для получения справочной информации о пользователях, теперь используются значительно осторожнее, чем в восьмидесятые годы. Эти команды, к сожалению, создают удобства не только для сетевых администраторов, но и для злоумышленников. Поэтому такие команды обычно используют только на этапе настройки почтовой системы. В работающей системе их, как правило, отключают.

В апреле 2001 г . RFC 821 , который на сегодняшний день является основным стандартом, описывающим протокол SMTP . Новый стандарт учитывает изменения, произошедшие в Internet 'е за восемнадцать с половиной лет.

SMTP может работать с различными протоколами транспортного уровня (см. RFC 821 и RFC 1090), но обычно используется TCP . За SMTP закреплен порт TCP 25.

Для передачи письма не достаточно одного лишь TCP-соединения, поэтому устанавливается еще одно SMTP-соединение. Это достигается возвращением ответного приветствия сервера с указанным именем (или IP) узла клиента. Итак, клиент отсылает  команду «HELO», сервер установив SMTP–соединение возвращает код успешного выполнения операции (250) и, в большинстве случае, передает IP–клиента или его доменное имя.     

Почта по протоколу SMTP посылается от клиента к серверу. Клиент запрашивает соединение с сервером. После успешного установления соединения сервер сообщает клиенту свое доменное имя. Он также может сообщить тип и версию установленного программного обеспечения. Однако, из соображений безопасности, чтобы не дать потенциальному взломщику воспользоваться известными ошибками данной версии сервера SMTP, передача этой информации часто блокируется системными администраторами.

Ответ сервера, свидетельствующий о готовности к приему команд клиента, служит сигналом к началу диалога, в котором клиент последовательно посылает серверу команды и ожидает ответы, либо подтверждающие исполнение команд, либо сообщающих о невозможности исполнения, либо содержащих информацию, запрошенную клиентом.

Серьезным недочетом протокола SMTP - есть то, что протокол не требует аутентификации пользователя перед отправкой сообщения и это позволяет использовать чужие сервера для незаконной пересылки писем.

Каждая команда SMTP начинается с ключевого слова – названия команды. За ним могут следовать параметры, отделенные пробелом.

Регистр символов, используемых во всех названиях команд и, за редким исключением, в параметрах базового протокола SMTP , не имеет значения. Однако в некоторых элементах расширений строчные и прописные символы могут различаться. Необходимо также учитывать, что левая часть почтового адреса, до символа @, может быть регистрозависимой.

В командах допускается использование только кодировки us - ascii , то есть символов, кодируемых семью битами. Это цифры, латинские буквы, и знаки препинания. Если информация передается восьмибитными блоками (октетами), старший бит должен быть равен нулю. Корректная интерпретация символов, старший, восьмой бит которых равен единице, например, русских букв, не гарантируется, использовать такие символы не следует.

Конец строк в протоколе SMTP обозначается последовательностью символов "возврат каретки" (шестнадцатеричный код 0D) и "перевод строки" (шестнадцатеричный код 0А). Эта последовательность обозначается CRLF . Сервер начинает выполнение команды только получив от клиента строку, завершающуюся последовательностью CRLF .

Сервера SMTP должны принимать командные строки длинной до 512 символов. Это значение может быть увеличено по желанию разработчиков. Для серверов, поддерживающих расширения ESMTP , требующие дополнительных параметров, максимально допустимая длина командной строки увеличивается. Соответствующие требования приведены в RFC, описывающих эти расширения.

Если не используется расширение, позволяющее серверу принимать несколько команд подряд, клиент передает серверу следующую команду только после получения ответа на предыдущую.

Рассмотрим команды SMTP , необходимые для отправки сообщения.

1. EHLO (Расширенное HELO)

Формат команды:

EHLO полное_доменное_имя_клиента CRLF

или

EHLO адрес_отправителя CRLF

Диалог клиента и сервера, как правило, начинается с приветствия. В RFC 821 в качестве приветствия предлагалась команда HELO . Однако с введением расширений ESMTP , эта команда была заменена на EHLO . Использование расширений ESMTP возможно только после выполнения команды EHLO.

Передача почты возможна только после выполнения одной из двух названых команд. Другие команды, не связанные с передачей почты (NOOP, HELP, EXPN, VRFY, RSET и QUIT), в принципе могут быть исполнены и без приветствия.

В качестве аргумента клиент передает серверу свое полное доменное имя, если таковое имеется. Если клиент не имеет доменного имени, например, если в качестве клиента выступает MUA , установленный на компьютере, получающем адрес динамически, то в качестве аргумента передается адрес электронной почты отправителя. Желательно, чтоб полученная от клиента информация была исчерпывающей для его идентификации.

Сервер проверяет соответствие указанного клиентом в приветствии доменного имени его адресу IP . Результат проверки добавляется к заголовку письма, но диалог продолжается независимо от достоверности полученного сервером идентификатора.

В ответ на команду EHLO сервер присылает список, каждая строка которого содержит ключевое слово, соответствующее расширению, поддерживаемому вызываемым сервером, и, при необходимости, уточняющие параметры. Это единственный предусмотренный базовым протоколом SMTP ответ сервера, в котором клиентская программа должна проанализировать не только числовой код ответа, но и его текст. Из ответа на команду EHLO клиент узнает, какие дополнительные функции он может использовать при отправке сообщения.

Если устаревшее программное обеспечение сервера не поддерживает команду EHLO, то выдается сообщение об ошибке. В этом случае клиент должен попытаться повторить приветствие, используя команду HELO . Естественно, расширениями ESMTP уже не удастся воспользоваться.

2. HELO (Приветствие)

Формат команды:

HЕLO полное_доменное_имя_клиента CRLF

или

HЕLO адрес_отправителя CRLF

RFC 2821 рекомендует использовать команду HELO , только если программное обеспечение не поддерживает команду EHLO. Отличие этой команды только в том, что она делает невозможным использование расширений ESMTP .

В ответ на эту команду сервер сообщает, готов ли он к продолжению диалога.

3. MAIL (Отправитель)

Формат команды:

MAIL FROM : адрес_отправителя дополнительные_параметры CRLF

Отправка электронного сообщения невозможна без успешного выполнения этой команды, для каждого письма команда MAIL должна быть выполнена только один раз.

Команда MAIL может быть выполнена только после успешного выполнения команды EHLO или HELO.

С помощью этой команды серверу сообщается адрес отправителя письма. На этот адрес письмо должно вернуться в случае невозможности доставки. Если возврат не желателен, адрес может быть оставлен пустым: <>:

MAIL FROM : <> CRLF

Обычно это бывает, если отправляемое сообщение уже и есть возвращаемое письмо. Это делается для того, чтобы избежать петли: письмо не может быть доставлено адресату и возвращается отправителю, но, если оно не может быть доставлено отправителю, то посылается обратно и так далее. Если же адрес отправителя не известен, то попытки вернуть его предприниматься не будут: в случае невозможности доставки получателю, письмо будет удалено.

Поскольку базовый протокол SMTP не предусматривает никакой авторизации отправителя, адрес отправителя может быть указан произвольно и не может считаться достоверным. В последние годы большинство MTA проверяют существование почтового домена отправителя и отвергают сообщения с адресами отправителей в несуществующих доменах. К сожалению, более детальная проверка возможна только при использовании дополнительных средств авторизации и обычно не применяется.

Базовый протокол SMTP не предусматривает дополнительных параметров для команды MAIL, но такие параметры использует ряд расширений ESMTP .

4. RCPT (Получатель)

Формат команды:

RCPT TO: адрес_получателя дополнительные_параметры CRLF

Доставка сообщения возможна, только если указан хотя бы один доступный адрес получателя. Команда RCPT принимает в качестве аргумента только один адрес. Если нужно послать письмо большему числу адресатов, то команду RCPT следует повторять для каждого. Согласно RFC 2821, сервера SMTP должны быть готовы принять до ста команд RCPT на одно сообщение. Если письмо адресовано большему числу получателей, то для оставшихся клиент должен передать сообщение повторно. Максимальное число получателей может быть изменено администратором.

Команда RCPT может быть выполнена только после успешного выполнения команды MAIL.

Сервер анализирует каждый адрес и после каждой команды RCPT выдает сообщение, свидетельствующее о возможности или невозможности доставки письма по указанному адресу.

При возникновении потребности в отправке одного и того же сообщения нескольким получателям достаточно вызвать «RCPT TO» еще один (или более) раз (максимальное количество получателей, как правило, не ограничено). Если кому либо из них сервер не возьмется доставлять сообщение, он вернет ошибку, что никак не скажется на остальных получателях.

Базовый протокол SMTP не предусматривает дополнительных параметров для команды RCPT, но такие параметры использует ряд расширений ESMTP .

5. DATA (Текст сообщения)

Формат команды:

DATA CRLF

C помощью этой команды серверу передается текст сообщения, состоящий из заголовка и отделенного от него пустой строкой тела сообщения.

Команда DATA может быть выполнена только после успешного выполнения хотя бы одной команды RCPT.

Команда DATA не требует никаких параметров и завершается последовательностью CRLF.

В ответ на правильно введенную команду DATA сервер сообщает о готовности к приему или об ошибке, если прием сообщения невозможен.

В случае положительного ответа сервера, клиент передает сообщение.

Передача заканчивается строкой, состоящей из одной точки. Эта строка не является частью сообщения и удаляется на приемной стороне. Чтобы исключить ложное срабатывание в случае, если сообщение содержит строку, состоящую из одной точки, на передающей стороне к началу каждой строки, начинающейся с точки, добавляется еще одна точка. На приемной стороне добавленные точки удаляются.

Распознав окончание сообщения, сервер должен принять решение о возможности или невозможности доставки и послать соответствующий ответ клиенту. Сделать это следует как можно быстрее, если нет явных свидетельств невозможности доставки сообщения, его рекомендуется принять, сообщив клиенту об успешном завершении операции. Если доставка в последствии окажется, невозможна, следует просто отправить письмо обратно, сообщив в квитанции причину отказа. Это делается для того, чтобы избежать проблемы, описанной в RFC1047 : не дождавшись ответа сервера, клиент разрывает соединение, считая передачу закончившейся неудачей, хотя сервер, возможно, позже осуществил доставку. Через некоторое время клиент снова пытается послать то же самое сообщение, что может привести к многократной передаче одного и того же письма. На ожидание ответа после завершения отправки сообщения рекомендуется выделять не меньше десяти минут. На ожидание других ответов отводятся от двух до пяти минут.

Необходимо принимать строки сообщения длиной до 1000 символов, включая последовательность CRLF, но не включая точку, добавляемую в начало строки во избежание ложного обнаружения конца сообщения.

Минимальный размер письма, которое должен принимать сервер SMTP – 64 килобайта, включая как тело сообщения, так и его заголовок.

6. QUIT (Выход)

Формат команды:

QUIT CRLF

Командой QUIT клиент заканчивает диалог с сервером. Сервер посылает подтверждение и закрывает соединение. Получив это подтверждение, клиент тоже прекращает связь.

Перечисленных команд вполне достаточно для того, чтобы передать сообщение. Однако RFC 2821 предусматривает еще ряд команд, которые могут быть использованы в основном в процессе отладки сервера.

7. VRFY (Проверить)

Формат команд:

VRFY адрес CRLF

Команда VRFY используется для проверки наличия указанного в качестве аргумента почтового ящика. В ответ сервер посылает информацию о владельце ящика или сообщение об ошибке, свидетельствующее о том, что указанный ящик не существует.

Если указанный адрес указывает на несколько почтовых ящиков, команда VRFY возвращает список пользователей, внесенных в соответствующую рассылку, либо сообщение об ошибке, свидетельствующее о неоднозначности ответа на полученный запрос.

Для получения адресов, внесенных в список рассылки, используется команда EXPN .

Используя эти команду, злоумышленники могут получить список адресов пользователей сервера.

Обе команды могут быть полезны в процессе отладки сервера, потому они, как правило, поддерживаются. Но на серверах, используемых в реальном окружении, их обычно отключают. Возможен также вариант, при котором вызов команд возможен, но они проверяют только синтаксическую верность адреса.

Согласно RFC 821 , команды VRFY и EXPN не являются обязательными. Поэтому, если сервер их поддерживает, они должны быть перечислены в ответе сервера на команду EHLO, как расширения ESMTP.

2. Ответы, предусмотренные для команд SMTP

Таблица 1

* В случае переадресации почты допускается также использование ответа 250. В этом случае клиент о переадресации не информируется. Сервер может также отказать в приеме почты для уже не существующего пользователя и послать ответ 551 с указанием нового адреса или ответ 550.

Таблица 2

4. Программы отсылающей письмо через заданный SMTP-сервер.

        Рассмотрим пример программы, которая отсылает письмо от определенного е-mail-ом отправителя к определенному e-mail – ом получателю через определенный IP–адресом SMTP – сервер. Для наглядности в работе с программой необходимо подключение к линии Интернет. Так же мы локально установим MDaemon v.6.7. в тестовом режиме. Этот SMTP-шник, на мой взгляд, удобно отражает диалог с клиентом.
        Приведем пример программы, разберем ее по «интересным» местам. Далее проанализируем результаты.

.386 .model flat, stdcall option casemap :none include \masm32\include\windows.inc include \masm32\include\masm32.inc include \masm32\include\kernel32.inc include \masm32\include\ws2_32.inc include \masm32\include\user32.inc includelib \masm32\lib\masm32.lib includelib \masm32\lib\kernel32.lib includelib \masm32\lib\ws2_32.lib includelib \masm32\lib\user32.lib .data SOCKADDR STRUCT sin_family WORD ? sin_port WORD ? sin_addr in_addr <> sin_zero BYTE 8 dup (?) SOCKADDR ENDS wsadata WSADATA <> s_addr SOCKADDR <> sock dd 0 r_buf db 512 dup(0) ;============================================================ s_helo db "HELO EHLO",0dh,0ah szhelo equ $ - offset s_helo s_from db "MAIL FROM:<_follower@mail.ru>",0dh,0ah szfrom equ $ - offset s_from s_to db "RCPT TO: <animator@e-mail.ru>",0dh,0ah szto equ $ - offset s_to s_data db "DATA",0dh,0ah szdata equ $ - offset s_data s_headers db "TO: animator@e-mail.ru",0dh,0ah db "Subject: smtp",0dh,0ah db "FROM: _follower@mail.ru",0dh,0ah s_body db "My first mail.",0dh,0ah db 0dh,0ah,".",0dh,0ah szbody equ $ - offset s_body szheaders equ $ - offset s_headers s_quit db "QUIT",0dh,0ah szquit equ $ - s_quit crlf db 13,10,0 ;IP db "192.168.1.12",0 ;IP db "199.149.62.15",0 ; www.e-mail.ru ;IP db "195.161.118.50",0 ; www.e-mail.ru ;IP db "194.67.23.111",0 ; www.mail.ru IP db 20 dup(0) .data? .code ;============================================================ start: invoke GetCL,1,ADDR IP .if eax != 1 ret .endif invoke WSAStartup,101h,offset wsadata invoke socket,AF_INET,SOCK_STREAM,0 mov sock,eax mov s_addr.sin_family,AF_INET invoke htons,25 mov s_addr.sin_port,ax invoke inet_addr,ADDR IP mov s_addr.sin_addr,eax invoke connect,sock,addr s_addr,sizeof s_addr invoke recv,sock,addr r_buf,512,0 ;invoke StdOut,ADDR crlf invoke send,sock,addr s_helo,szhelo,0 call recvlp ;invoke StdOut,ADDR crlf invoke send,sock,addr s_from,szfrom,0 call recvlp ;invoke StdOut,ADDR crlf invoke send,sock,addr s_to,szto,0 call recvlp ;invoke StdOut,ADDR crlf invoke send,sock,addr s_data,szdata,0 call recvlp ;invoke StdOut,ADDR crlf invoke send,sock,addr s_headers,szheaders,0 call recvlp ;invoke StdOut,ADDR crlf invoke send,sock,addr s_quit,szquit,0 call recvlp ;invoke StdOut,ADDR crlf invoke closesocket,sock invoke WSACleanup ;invoke ExitProcess,0 ret ;Clear Buffer clear: mov ecx,512 lea edi,offset r_buf r: mov byte ptr [edi],00h inc edi loop r ret ;============================================================ recvlp: invoke recv,sock,addr r_buf,512,0 .IF EAX!=SOCKET_ERROR ;int 3 invoke StdOut,ADDR r_buf .ENDIF call clear ret ;============================================================ end start

Разбор кода:

s_headers db "TO: animator@e-mail.ru",0dh,0ah db "Subject: smtp",0dh,0ah db "FROM: _follower@mail.ru",0dh,0ah

Первая строка кажется разорванной, то есть сервер вернул на самом деле:

250 relay.orel.bk.ru0Ah0DhSMTP Postfix

Если заменить нашу функцию функцией, которая вместо ‘0Ah0Dh’ подставить ‘..’,

recvlp proc uses EDI ESI invoke recv,sock,addr r_buf,512,0 .IF EAX!=SOCKET_ERROR lea EDI, r_buf mov ESI,EDI @@: mov ax,[EDI] cmp ax,0A0Dh je __chenge_p cmp ax,00h je __exit inc EDI jmp @B __chenge_p: mov word ptr [EDI],2e2eh inc EDI jmp @B __exit: invoke StdOut,ESI .ENDIF call clear ret recvlp endp

:)) А не настроенный PostFix, если помните, на пересылку согласился. Вот так, а Вы говорите что программы под Windows – плохие, вот Вам пример – поставил и не думаешь. «Вот, вот, не думаешь …» - возмутятся юниксоиды. Только хочется спросить - кто сейчас за эти знания в России  платит ? Есть SMTP–шник ? есть , работает ? - работает ! все , гуд ! И никому не важно на чем он. Ну это мы влезли в другую степь, извините за отступление.

Итак, что мы имеем. Письмо переслал только не отстроенный PostFix ( юниксовый почтовик под FreeBSD). Но мы еще не закончили , и поможем «своему горю» в следующих статьях. При следующей встрече мы посмотрим, как поработать с командой VRFY. По крайней мере, мне было интересно, надеюсь Вам, уважаемый читатель, будет то же. До свиданья.

Исходник