
снабжается новыми заголовками, никак не связанными с заголовкам
предыдущего письма. Возможна еще одна разновидность перенаправления
письма, когда тело старого письма (без заголовков) снабжается новыми
заголовками и отправляется новому (или старому, не важно) адресату.
Процедура Resent предполагает, что существующее письмо со всеми его
неизменными заголовками СНОВА отправляется, и только в ТАКОМ случае
возможно дополнение существующих заголовков письма набором заголовков,
начинающихся с Resent- дабы подчеркнуть, что письмо ПОВТОРНО посылается.
В случае, если письмо повторно посылается несколько раз, оно должно быть
снабжено заголовками Resent- столько раз, сколько раз письмо повторно
отсылалось.
Переходим к рассмотрению трассировочных заголовков электронного
письма. Таких заголовков два, рассматриваем заголовок Return-Path. В этот
заголовок письма переносится аргумент команды MAIL, т.е. адрес отправителя
письма, включая маршрут от источника, указанный отправителем. Данная
информация позволяет получателю письма узнать обратный маршрут,
указанный отправителем письма для того, чтобы в случае генерации ответа,
включить в аргумент команды RCPT путь, указанный отправителем исходного
письма.
Второй трассировочный заголовок – Received. Этот заголовок НЕ
формируется отправителем письма, вместо этого такой заголовок формирует
КАЖДЫЙ почтовый сервер, через который передавалось письмо по мере его
продвижения по сети. Когда отправитель посылает письмо на первый почтовый
сервер, тот включает в письмо заголовок Received, в котором указывает, как
представился тот, кто передал письмо серверу (в данном примере –
отправитель) в команде HELO/EHLO. Так же сервер размещает в заголовке
Received IP адрес того, кто передал ему письмо, помимо этого сервер может
сопоставить FQDN, которым представился отправитель в команде HELO/EHLO с
его истинным FQDN, выяснив его на основании обратного DNS запроса на
основании известного IP адреса, в случае, если указанное клиентом имя
совпадает с разрешенным с помощью DNS сервер может отметить это отдельно в
заголовке Received, в противном случае сервер может отметить, что адрес не
соответствует записям в DNS. Когда первый сервер передает письмо второму, то
второй сервер вносит в письмо еще один заголовок Received, в котором в свою
очередь отмечает, кто передал письмо ЕМУ, то вносит в письмо аналогичную
информацию о ПЕРВОМ сервере и так далее. Таким образом, письмо,
перемещаясь по сети, обрастает заголовками Received, из анализа этих
заголовков получатель письма сможет сделать выводы о том, через какие
почтовые сервера прошло письмо прежде, чем было доставлено получателю.
КРАЙНЕ важно отметить, что, так как в протоколе SMTP нет авторизации,
проверка с помощью команды HELO/EHLO не достоверна, подписать письмо
отправитель может каким угодно адресом, то заголовки Received, особенно
первый, который вписывает ПЕРВЫЙ почтовый сервер, получающий письмо от
клиента, являются ЕДИНСТВЕННЫМ средством, позволяющим пролить свет на
ИСТИННОГО отправителя письма, т.е. узнать IP адрес той станции, которая
послала письмо. Кроме того, заголовки Received служат для решения еще одной,
очень важной задачи: возможно, что вследствие неправильной конфигурации
почтовых сервером, письмо попадет в маршрутную петлю, то есть будет
передаваться двумя или несколькими серверами по кругу, занимая тем самым
пропускную способность линий связи. Количество заголовком Received может
служить в некотором роде своеобразным «TTL» письма – каждый транзитный
почтовый сервер может быть сконфигурирован таким образом, чтобы не
передавать далее письмо, количество заголовков Received которого превысило