Кратко

  • RFC 1429 описал BITNET LISTSERV DISTRIBUTE: одна копия проходила по сильно нагруженному каналу там, где знание топологии позволяло сгруппировать получателей. Автор сообщал о двух–шести миллионах почтовых сообщений в день на тот момент.
  • Перед крупной отправкой следовало выбрать близкий сервер, проверить возраст файла основных узлов — не более двух месяцев — и согласовать с администратором нагрузку свыше 10 000 адресатов за день.

Сколько чужих писем обязана принять университетская машина? RFC 1429, опубликованный в феврале 1993 года, отвечал вполне по-операторски: если планируется более 10 000 получателей в день, сначала попросите разрешения у администратора выбранного сервера LISTSERV. Сообщите ему объём сообщений и адресов. У площадки могли быть ограничения на часы пик, плановые остановки или несколько машин с разной ролью.

Просьба была разумной, потому что DISTRIBUTE превращал множество отдельных отправок в общую сетевую работу. Владелец списка передавал сообщение и адреса серверу; сеть BITNET по своей карте направляла одну копию через перегруженный канал и размножала её ближе к группе получателей. Эрик Томас писал, что тогда система обслуживала два–шесть миллионов сообщений в день. Для достаточно хорошо подключённых получателей BITNET он указывал типичное время пять–пятнадцать минут.

Нельзя было выбрать любой LISTSERV по удобному адресу. Пример автора прост: если отправитель сидит в Калифорнии, а большинство адресатов в США, посылать весь список сначала на сервер в Швеции бессмысленно. Ещё неприятнее была разница между двумя подключениями одной площадки: T1-доступ к IP не мешал ей иметь BITNET-линии всего на 9,6 килобита в секунду. Скорость внешней витрины не определяла ширину входа в распределительную сеть.

Проверка карты была столь же конкретной. Файл Master nodes выбранной машины не должен был быть старше двух месяцев. Некоторые сайты держали устаревшие таблицы из-за нехватки персонала. Сеть, оптимизирующая путь по этим таблицам, могла аккуратно раскладывать почту по уже неправильной схеме. Поэтому RFC связывал эффективность прежде всего с качеством и точностью топологических сведений, а иногда и с текущей нагрузкой.

Ошибки имели разные обратные адреса. SMTP-поле MAIL FROM предназначалось для человека, способного разобраться, если запрос не добрался до LISTSERV. Поле RFC822 From внутри запроса принимало сообщения о более поздних проблемах доставки. Если поставить туда адрес приёма сообщений самого списка, возвраты могли снова попасть в рассылку и образовать цикл. Отправить много писем мало; надо решить, кому достанутся неудавшиеся.

Запрос состоял из карточки JOB, команды DISTRIBUTE MAIL, списка адресов с пометкой BSMTP и текста сообщения. DEBUG=YES позволял посмотреть маршруты без настоящей доставки; TRACE=YES давал отчёт во время неё. В примере RFC три получателя отправлялись через UGA, а два передавались местному SMTP-агенту. В штатном режиме ECHO=NO отключал отчёт о расходе ресурсов. Подробная диагностика сама тратила пропускную способность и процессорное время.

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