Доставлено — запись, по которой считают всё

критично

d
Самая массовая запись учёта — и основа любой цифры об объёме

Запись появляется, когда сервер назначения принял письмо для конкретного получателя. По одной на получателя — значит эта запись самая массовая из всех, и любая цифра об объёме отправки в итоге считается по ней.

Тип записи в строке — d. Первое поле каждой строки учёта называет тип, и по нему записи и разбирают: d — доставлено, b — отбито, t — временная неудача.

Полей тридцать шесть, по умолчанию пишется двадцать два. Набор тот же самый, что у записей об отказе и о временной неудаче, — это удобно: разбор всех трёх типов пишется один раз.

Что в записи есть. Исход и его код, время постановки в очередь и время события, адрес отправки, задание, размер, защита передачи и данные прокси, если он был. То есть достаточно, чтобы ответить и «сколько ушло», и «с какого адреса», и «шифровалась ли передача».

Чего в ней нет. Того, что случилось с письмом после приёма сервером назначения: попало ли оно в папку «Входящие», открыл ли получатель. Запись говорит только о передаче.

Главная ловушка — считать доставку по этой записи доставкой получателю. Она означает, что письмо принял сервер назначения, и ровно это. Дальше письмо может уехать в спам, быть отброшено фильтром получателя или тихо удалено правилом — записи об этом не будет ни одной. Цифра «доставлено 98%» описывает передачу, а не то, что письмо увидели.
Что делает Хаб. Забирает записи учёта с узлов и строит на них всю аналитику: объёмы, доставляемость по провайдерам, коридоры по парку. Эта запись — источник числителя почти во всех формулах.

Приходит она потоком через веб-крючок, а не чтением файла: узел настроен отдавать записи Хабу по мере появления.

⚠️ Именно поэтому мы показываем доставляемость, а не долю «Входящих» — данных о папке у нас нет и быть не может: узел о ней не знает. Инбокс-мониторинг потребовал бы контрольных ящиков и опроса по IMAP, и это отдельная задача.

Рекомендуемые значения

Что этой записью можно измерить, а что нет:

Вопрос Отвечает ли запись
сколько писем принято серверами назначения да, это она и есть
с какого адреса и по какому заданию да, поля есть
шифровалась ли передача да, защита передачи записана
попало ли письмо во «Входящие» нет — узел этого не знает
открыл ли получатель нет — это другой источник

Двадцать два поля из тридцати шести — умолчание, а не предел. Состав пишущихся полей настраивается; расширять его стоит осознанно: запись самая массовая, и каждое лишнее поле умножается на объём отправки.

Тот же набор полей у трёх типов записей — доставки, отказа и временной неудачи. Разбор, написанный под один тип, читает и остальные два.

Разграничение «что измеряет, а что нет» наше. Из руководства здесь условие появления записи, буква типа, число полей и то, что набор общий с записями об отказе и временной неудаче.
Пример в конфигурации
# строка учёта о доставке: тип в первом поле
d,2019-02-08 21:53:41+0000,2019-02-08 21:53:41+0000,CB-A=example.com@bounce.foo.com,#   A@example.com,,delivered,2.0.0,smtp;250 OK,mail.example.com (10.1.2.3),...
Выделенная строка начинается с буквы типа — по ней разбор и отличает доставку от отказа. Дальше идут время постановки в очередь и время события, обратный адрес, получатель и исход.
жёлтым — — имена директив, голубым — блоки. Так же они подсвечены и в тексте карточки.
▲

Типичные ошибки и проблемы

что делают не так и чем это кончается3 ошибки▶

Читают запись как доставку получателю

§ 12.2

Чем чреватоЗапись означает приём сервером назначения. Что было дальше — папка «Спам», фильтр, правило получателя — учёт не знает и знать не может. Доля доставленных описывает передачу, а не попадание в почтовый ящик.
Как заметитьДоставляемость по отчёту высокая, отклик получателей низкий.
Как правильноНазывать эту величину доставляемостью, а не попаданием во «Входящие». Про папку отвечают контрольные ящики, а не учёт узла.

Расширяют состав полей, не считая объём

§ 12

Чем чреватоЗапись самая массовая: одно добавленное поле умножается на число доставленных получателей. Учёт растёт быстрее, чем ожидалось, и упирается в место на разделе.
Как заметитьФайлы учёта растут заметно быстрее прежнего при том же объёме отправки.
Как правильноДобавлять поля осознанно и держать ротацию учёта настроенной заранее.

Ищут пропавшие записи в файле, а не в конфигурации

§ 3.3.10

Чем чреватоОтдельные виды записей отключаются директивой, и тогда события происходят, а следа не остаётся. Отсутствие записей неотличимо от отсутствия событий.
Как заметитьВ учёте нет записей одного типа, при этом отправка идёт.
Как правильноПроверить, не отключён ли этот вид записей для приёмника или адреса отправки.
Совместимость
PowerMTA 6.0
описана в руководстве этой версии · платформа: любая
С какой версии директива доступна, вендор указывает не для всех — здесь пометки нет. Имя встречается и в издании руководства 5.0.
Наследование
Наследования у записи нет — это факт, а не настройка. Наследуется то, куда она попадёт и какие поля будут написаны: и назначение учёта, и состав полей задаются директивами блока учёта, а отдельные виды записей можно вовсе отключить директивой disable-acct-records — тогда события останутся, а следа от них не будет.
⇄

Связанные записи

3 связи

Как проверить на узле
Проверить, что записи пишутся и что в них ожидаемые поля:
head -3 /var/log/pmta/acct-*.csv
cut -d, -f1 /var/log/pmta/acct-*.csv | sort | uniq -c
Первая покажет заголовок и первые строки — по нему видно состав полей. Вторая печатает сводку по типам записей: если доставок нет вовсе, а отправка идёт, стоит проверить, не отключён ли этот вид записей.
В Хабе
Цена ошибки
безопасно: неверное значение ничего не ломает
Сценарии
Разобраться с доставляемостью · Собрать телеметрию
Важность
критично