Message-ID: зачем каждому письму нужен уникальный идентификатор

Message-ID это поле заголовка, в котором лежит глобально уникальный идентификатор письма. Его формирует исходный MTA (или почтовый клиент) в момент создания сообщения, и дальше он остаётся с письмом всю его жизнь: при доставке, хранении, пересылке и в ответах. Двух писем с одинаковым Message-ID быть не должно.

Дедупликация сообщений

Основная функция Message-ID на стороне получателя - дедупликация. Если одно и то же письмо доставлено дважды (из-за сетевого сбоя, retry после таймаута, или пересылки через несколько путей), почтовый клиент или сервер сравнивает Message-ID с уже имеющимися. Совпадение означает дубликат, который можно отбросить.

Gmail активно использует дедупликацию по Message-ID. Если вы отправите одно и то же письмо (с тем же Message-ID) на один адрес Gmail дважды, второе не появится в ящике. Это защищает пользователей, но может сбить с толку отправителя при тестировании: письмо "не дошло", хотя оно просто было отфильтровано как дубликат.

Threading: In-Reply-To и References

Когда вы отвечаете на письмо, почтовый клиент берёт Message-ID исходного сообщения и помещает его в заголовок In-Reply-To нового сообщения. Заголовок References содержит цепочку всех Message-ID в треде:

Почтовые клиенты используют References для группировки писем в беседы (threads). Без корректных Message-ID эта система ломается: ответы отображаются как отдельные письма, а не как часть переписки.

Message-ID в массовых рассылках

Для ESP Message-ID выполняет ещё одну задачу: идентификация конкретного письма в логах. Когда получатель жалуется на спам или bounce возвращается с ошибкой, Message-ID позволяет найти именно это сообщение в системе отправки и понять, что пошло не так.

Хороший ESP генерирует уникальный Message-ID для каждого отдельного получателя в рассылке. Если одна кампания отправляется 50 000 адресатам, создаётся 50 000 разных Message-ID. Это правильное поведение. Если ESP использует один Message-ID для всех копий, дедупликация на стороне получателей может отбросить легитимные письма.

Отсутствие или подделка Message-ID

Письмо без Message-ID - аномалия. RFC 5322 обязывает его наличие. Если отправляющий MTA не сгенерировал Message-ID, принимающий сервер обычно создаёт его сам и добавляет в заголовки. Но само отсутствие заголовка от отправителя расценивается спам-фильтрами как признак плохо настроенного или подозрительного источника.

Подделка Message-ID (повторное использование чужого идентификатора) может привести к тому, что письмо будет отброшено дедупликацией. Некоторые спамеры копируют Message-ID легитимных писем, рассчитывая обойти фильтры, но результат обычно обратный: письмо не доставляется, потому что получатель уже видел этот ID.

Домен в Message-ID

Часть после @ в Message-ID обычно совпадает с доменом отправляющего сервера. Некоторые спам-фильтры проверяют это соответствие. Если письмо утверждает, что отправлено от company.com, а Message-ID содержит @random-vps.net, это расхождение может повысить спам-скор.

На практике строгая проверка домена в Message-ID не является стандартом. Но рекомендация проста: используйте домен своего почтового сервера в Message-ID. ESP делают это автоматически (Message-ID содержит домен ESP или кастомный домен клиента).

Message-ID и Feedback Loop

Когда получатель нажимает "Спам" в Gmail или Yahoo, почтовый провайдер отправляет Abuse Report (ARF) на адрес, зарегистрированный в Feedback Loop. Этот отчёт содержит Message-ID исходного письма. ESP использует его для идентификации: какое именно письмо вызвало жалобу, из какой кампании, для какого клиента.

Без уникального Message-ID привязать жалобу к конкретному сообщению невозможно. Это делает анализ complaint rate неточным и затрудняет работу над улучшением рассылок.

Message-ID в диагностике

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

Лог Postfix, например, записывает Message-ID для каждого обработанного сообщения. Одна команда grep по ID покажет весь путь письма через систему: приём, обработка, передача на следующий hop, финальный статус.