Кратко

  • В SMTP 1982 года сервер мог принять письмо для дальнейшей пересылки и сам стать отправителем на следующем участке пути.
  • RFC 2505 в 1999 году потребовал закрыть релей для посторонних: заявления в HELO и MAIL FROM слишком легко подделать, чтобы выдавать по ним разрешение.

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

Спецификация SMTP RFC 821, опубликованная в августе 1982 года, описывала пересылку как обычную возможность. Получающий сервер мог принять письмо, адресованное через него другому серверу, либо отказать. После принятия он становился отправителем на следующем участке. Документ различал конечный почтовый ящик и маршрут через промежуточные машины. Такое устройство помогало почте пересекать границы сетей и несовместимых окружений.

Но кто вправе нанять промежуточную машину? RFC 2505, выпущенный в феврале 1999 года как Best Current Practice 30, назвал пересылку без разрешения расходованием чужих ресурсов и угрозой репутации владельца сервера. Программа передачи почты должна была уметь пресекать такую работу. Формулировка была деловой: серверу предлагалось решать, чьи поручения он исполняет, до того как он возьмёт их в дорогу.

В SMTP-диалоге есть несколько подсказок, но они не равны по надёжности. Имя в HELO сообщает собеседник; его можно выдумать. Обратный адрес в MAIL FROM тоже заявляет собеседник, и его можно подделать. RCPT TO обозначает назначенного получателя. Кроме того, сервер видит сетевой адрес установившего соединение клиента. Если два первых поля превращались в пропуск, достаточно было надеть бумажную корону и потребовать королевский экипаж.

Рекомендация RFC 2505 привязала разрешение к обязанностям самого оператора. Сервер принимает почту для доменов, которые обслуживает или за которые согласился пересылать. Он может передавать письма от клиента с разрешённым адресом источника либо, если оператор доверяет DNS для этой цели, с разрешённым именем машины. Остальным в дальнейшей пересылке отказывают. Клиент вправе произнести любое имя; список собственных доменов и доверенных клиентов составляет тот, кто оплачивает сервер.

Даже адрес назначения иногда прятал продолжение маршрута. RFC 2505 отдельно предупреждал о форме @a,@b:, о трюках с % и о старых путях UUCP через !. Поверхностная проверка могла принять адрес за местный, а полная обработка отправляла письмо дальше. При этом необычная запись встречалась и у законных шлюзов. Оператору следовало разобраться в своих правилах маршрутизации, прежде чем захлопнуть ворота: сторож, читающий только первую строку путевого листа, охраняет не тот выезд.

В июне того же года RFC 2635 под названием DON'T SPEW обратился к провайдерам. Он советовал не оставлять серверы открытыми для пересылки посторонним, публиковать правила пользования, проверять обвинение в злоупотреблении перед наказанием клиента и обеспечивать читаемые людьми адреса abuse и postmaster. Настройка MTA могла остановить сеанс. Разбор жалобы, договора и ошибочного обвинения оставался работой людей.

Новая спецификация SMTP RFC 5321 от октября 2008 года сохранила на виду другое затруднение. У почты есть давняя привычка доставлять письмо или сообщать о неудаче. Потоки нежелательной почты сделали отказ и иногда отбрасывание частью эксплуатации, но молчаливое исчезновение письма подрывает доверие к доставке. Проверить право на пересылку и объяснить судьбу уже принятого письма — разные задачи почтовой службы.

Курьер не потерял работу. Он продолжил возить письма тех, кому оператор разрешил пользоваться маршрутом. Изменился порядок у стойки: слово в HELO перестало выглядеть как подпись владельца грузовика. Это редкий случай, когда важное инженерное правило легко объяснить бухгалтеру.