Где задержалось письмо: как читать строки Received

Чтобы найти задержку письма по Received, постройте хронологию доверенных серверных отметок и приведите их время к одной зоне. Самый большой интервал подскажет участок для проверки журналов. Он не доказывает, что всё это время письмо стояло именно в очереди, и не объясняет задержку до первого подтверждённого приёма.

Возьмите оригинал сообщения

Скриншот времени в списке писем для такого разбора недостаточен. Нужен оригинал заголовков именно задержавшегося сообщения. Обычная пересылка может добавить собственный маршрут и оставить нужное письмо только в теле; тогда легко начать измерять совсем другую доставку.

В инструкции Gmail описано получение полного заголовка через меню письма и действие «Показать оригинал». В другом клиенте ищите соответствующий просмотр исходного сообщения. Сохраните неизменённую копию для анализа, а для обсуждения подготовьте отдельную обезличенную выписку.

Почему новые отметки находятся сверху

По RFC 5321, раздел 4.4, принимающий SMTP-сервер добавляет свою Received в начало сообщения, сохраняя порядок прежних строк. Поэтому обычную хронологию передачи восстанавливают снизу вверх. Время каждой отметки относится к приёму тем сервером, который её добавил.

Сначала выделите поля принимающей стороны by и передающей стороны from, время и доступный идентификатор события. Не путайте время Date, которое относится к сообщению, с очередной серверной отметкой. Расхождение этих значений полезно заметить, но автоматически приписывать его сетевой очереди нельзя.

Поставьте границу доверия до расчётов

Все строки одинаково выглядят как текст, но вы не обязаны считать каждую из них достоверной. Начните с известной принимающей инфраструктуры и сопоставьте её записи с журналом или сведениями провайдера. Нижние отметки за пределами подтверждённой цепочки оставьте непроверенными. RFC также разбирает подмену сведений SMTP; длинный маршрут сам по себе не является подтверждением происхождения.

Из этого следует полезное рабочее правило: сначала установить, каким переходам можно доверять, потом вычислять интервалы. Если доступна лишь одна подтверждённая отметка, честный результат — «дальнейший участок не установлен». Дописывать недостающий сервер по похожему имени или одному IP не нужно.

Учебное письмо с тремя отметками

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

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

Тридцать минут указывают на промежуток между соседними зафиксированными приёмами. Внутри могли быть подготовка передачи, очередь, повторная попытка и другая обработка, не раскрытая этими строками. Без журналов нельзя разложить весь интервал на причины или заявить о тридцатиминутном отказе получателя.

Как проверить подозрительный участок

1. Убедитесь, что отметки относятся к одной копии сообщения, а не к пересылке или повторной отправке.
2. Сохраните порядок строк и выделите известную принимающую цепочку.
3. Приведите дату и время каждой используемой отметки к общей зоне, не теряя исходного смещения.
4. Посчитайте интервалы между последовательными подтверждёнными событиями и отдельно отметьте пробелы.
5. Запросите сведения об очереди и попытках передачи на найденном участке, приложив время и безопасные идентификаторы.

При отрицательном интервале сначала перепроверьте дату, смещение, порядок и часы узлов. Не исправляйте время в исходнике, чтобы получить правдоподобный результат. Несогласованность сама является наблюдением, которое нужно передать администратору. Для поддержки почты такая выписка полезнее общего предположения «провайдер тормозит».

Приём сервером ещё не равен появлению в клиенте

Последняя известная серверная отметка не измеряет момент, когда сотрудник увидел письмо в приложении. Если подтверждённая передача прошла быстро, а сообщение появилось позже, следующий вопрос — что происходило между серверной обработкой, состоянием ящика и показом в клиенте. Для него нужны другие наблюдения.

Также Received не покрывает время, пока сайт ещё формировал уведомление до первой передачи. В споре «клиент ждал код» разделите создание события на сайте, начало отправки, приём почтовой системой и отображение сообщения. Сопровождение сайта и почтовая диагностика отвечают за разные границы этого пути.

Что передать провайдеру без лишних данных

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

RFC отдельно отмечает, что трассировочные поля могут раскрывать внутренние имена. Поэтому обезличивание должно сохранять порядок и временные значения, но убирать ненужные сведения. Если проблема касается собственной инфраструктуры, через поддержку сервера согласуйте, какие журналы и очереди относятся к выбранному участку. Изменять фильтры доставки до установления причины не требуется.