Передача данных с помощью протокола SMTP

🕛 03.08.2009, 19:13

Для того чтобы понять материал данной главы, надо хотя бы в общих чертах представлять себе принцип передачи почтовых сообщений с помощью протокола SMTP. В частности, необходимо знать различия между заголовками конверта (envelope header), заголовками сообщения (message header) и телом сообщения (message data). Заголовком конверта считаются поля From и То и содержащиеся в них адреса, которые указываются передающим компьютером при установлении SMTP-соединения. В особенности важен заголовок конверта То, так как именно его анализирует принимающая система, определяя, кому адресовано данное сообщение.
В отличие от заголовка конверта, заголовок сообщения входит в состав письма. Нередко этот заголовок составляет значительную часть сообщения, доставляемого адресату. Среди них также присутствуют поля From: и То:, но полагаться на их значения нельзя, так как они могут быть фальсифицированы. К заголовку сообщения относятся также поле Received:, которое отражает путь, проделанный письмом, и поле Subject:, отображаемое большинством программ просмотра писем.

В заголовке сообщения значение поля отделяется от его имени двоеточием. ЗАМЕТКУx В заголовке конверта двоеточие обычно не используется. Если сервер SMTP использует формат maildir, данные, содержащиеся в заголовке конверта, хотя и используются при выполнении SMTP-транзакции, но не сохраняются в сообщении. Некоторые серверы могут быть сконфигурированы так, чтобы адреса, указанные в полях From и То заголовка конверта, сохранялись в составе поля Received: заголовка сообщения. Это помогает в тех случаях, когда надо выяснить причину возникновения проблем при передаче писем.
Чтобы понять, как действует протокол SMTP, надо проследить ход SMTP-транзакции. В листинге 19.1 показан процесс передачи сообщения, осуществляемый вручную с помощью программы telnet. (Как нетрудно догадаться, в обычной SMTP-транзакции программа telnet не участвует).

В большинстве случаев SMTP-соединение начинается по инициативе клиентской программы, в роли которой выступает программа подготовки писем или другой сервер SMTP (в сеансе, представленном в листинге 19.1, действия клиентской программы имитирует пользователь с помощью программы telnet). Клиент объявляет о своем намерении начать взаимодействие, передавая серверу команду HELO или EHLO. Затем с помощью команд MAIL FROM: и RCPT TO: клиент задает заголовки конверта From и То. В ответ на каждую из этих команд сервер SMTP передает числовой код, посредством которого
он сообщает результаты обработки очередной команды. Текст, следующий за числовым кодом, предназначен для пользователя, который следит за ходом взаимодействия. Команда DATA указывает на то, что передающий компьютер готов пересылать тело сообщения. Получив ответ от сервера, клиент начинает передачу заголовков и данных сообщения. (Заголовки сообщения передавать не обязательно. Если исключить их из листинга 19.1, письмо все равно будет доставлено.) Заголовки отделяются от тела сообщения пустой строкой. Строка, содержащая только точку, является признаком окончания сообщения.
Ниже описаны некоторые характерные особенности SMTP-транзакции и передаваемых сообщений, которые должны учитываться при настройке сервера.
- Идентификация отправителя. Передающая система передает свой адрес принимающему компьютеру различными способами, в частности, адрес содержится в составе команд HELO и MAIL FROM, а также поля заголовка From:. Следует заметить, что если передающая система работает в режиме ретранслятора, в команде MAIL FROM и в поле заголовка From: будет содержаться адрес другого компьютера. Так или иначе, IP-адрес отправителя становится известен принимающей системе; в листинге 19.1 этот адрес указывается в ответе на команду HELO.
- Заголовки конверта и сообщения. В листинге 19.1 заголовки конверта и сообщения соответствуют друг другу, но в других случаях ситуация может быть иной. Если вы получите сообщение, адресованное не вам, причина этого может состоять в том, что в поле То заголовка конверта был указан ваш адрес, а в поле То: заголовка сообщения - адрес другого пользователя. Поскольку действия по доставке письма определяются значением поля То заголовка конверта, то такое письмо будет передано вам. Почтовая программа, сохраняющая все данные о заголовках, помогла бы вам выяснить причины происходящего.
- Возможность отказаться от сообщения. Принимающий сервер SMTP может прекратить работу по доставке письма на любом этапе, начиная с установки соединения и заканчивая обработки сообщения после его получения. Чаще всего управление доставкой сообщения осуществляется после ответа на команду RCPT ТО:, но существует также возможность контроля на более ранних этапах взаимодействия. Если получатель прерывает соединение перед получением команды RCPT ТО:, некоторые отправители предпринимают повторную попытку передачи письма, что увеличивают нагрузку на сеть. Отказ от обработки после передачи содержимого письма имеет свой недостаток - если объем сообщения велик, такой подход также приведет к неоправданному увеличению трафика в сети.
- Предоставление информации о сервере. При проведении сеанса, приведенного в листинге 19.1, отправитель получает лишь частичную информацию о сервере и никаких других данных. В данном примере сервер объявляет себя как Exim 3.12. Некоторые программы позволяют скрыть номер версии; если в средствах защиты сервера имеются недостатки, такая мера повышает безопасность системы. Сохраняя в секрете номер реализации сервера, вы лишаете хакера информации о возможных путях незаконного проникновения в систему. В листинге 19.1 в ответ на команды MAIL FROM: и RCPT TO: принимающий сервер возвращает код 250 и сообщение is syntactically correct. Некоторые серверы могут быть сконфигурированы так, что в случае, если в системе отсутствует учетная запись пользователя,
которому адресовано письмо, взаимодействие с передающим компьютером прекратится после обработки команды RCPT ТО:. Такая конфигурация предоставляет информацию, полезную для злоумышленника: посредством команд почтового сервера он может подобрать корректное имя пользователя. В этом примере сервер Exim не предоставляет подобных данных, однако это порождает другую проблему. Если в письме указан несуществующий пользователь, сервер должен обработать, а затем проигнорировать письмо.