Блог

Я пытаюсь проанализировать заголовок почты, чтобы выяснить, какой элемент (MUA, MTA …) создает каждый. Мое предположение:

• MUA отправителя составляет тело (включая Content-Type, Mime, Content-Transfer-Encoding) и отправляет его через SMTP пограничному MTA отправителя. MUA предоставляет информацию для начальных заголовков (From, To, Reply-To, ), которые вставлены этим MTA
• Этот MTA вставляет MessageId и Return_Path (и все дополнительные заголовки и X-заголовки, которые он желает)
• Затем он начинает «надеяться». При каждом переходе получающий MTA вставляет заголовок ‘Received:’ и каждый другой заголовок, который он рассматривает

Если порядок сохранен, и каждый MTA вставляет свои заголовки В верхней части сообщения, должно быть легко определить, какой MTA вставил каждый заголовок… но я не могу найти допустимую схему

• Такие поля, как DKIM-Подпись, Аутентификация-Результаты, Получено-SPF …, отображаются в разных местах. Какой MTA создает каждый из них? Кто DKIM подписывает электронное письмо (я полагаю, это должен быть MTA границы отправителя) Кто проверяет подлинность SPF-DKIM-DMARC?
• Добавлено много X-заголовков, многие из которых связаны с контролем над спамом, и я не могу найти, какой MTA (включен с помощью hop) создал каждый

Не могли бы вы мне помочь, пожалуйста?

MUA (почтовый пользовательский агент, термин RFC для почтового клиента) добавит большинство заголовков, которые вы можете видеть в почтовых клиентах, в частности From: и To: . (Иногда вы можете увидеть это в To: заголовке, когда у кого-то есть «забавные» псевдонимы для кого-то в их адресной книге. Или когда «From:» и SMTP-конверт from (как в MAIL FROM: команде) не совпадают, даже если серверы may будут отклонять такие сообщения, поскольку это часто является индикатором спама.) MUA также установит Reply-To: заголовок, особенно если MUA действительно является системой управления клиентами. MTA (агент передачи почты, фактический SMTP-сервер) может содержать информацию об отказе (VERP).

Затем MUA отправляет сообщение в MTA. Каждая программа (почтовый сервер, брандмауэр и т.д.), Которая касается электронной почты, Может добавлять заголовки. Например, MTA обычно выполняет подпись DKIM (и добавляет соответствующие заголовки). Он должен предшествовать Received: заголовку (т. Е. помещать его сверху) и не должен смешиваться с другими Received: заголовками. Тем не менее, некоторые программы, такие как брандмауэры, могут испортить заголовки.

Вы можете видеть несколько подписей DKIM (см. селекторы DKIM), например, когда электронное письмо повторно отправляется в контексте списка рассылки. Вы могли видеть подпись DKIM от исходного отправителя в списке, затем другие заголовки, включая дополнительный заголовок DKIM, когда сервер списка рассылки отправляет его конечным получателям.

Что касается X-... заголовков: это нестандартные заголовки (отсюда и X- префикс). Здесь все отключено. Некоторые отправляющие MTA вставляют их в целях отслеживания (например, чтобы поймать спамеров среди своих клиентов), некоторые получатели почты помещают свои оценки спама в специальный x-заголовок. Даже MUA может помещать некоторые x-заголовки в электронные письма, например, Claws Mail помещает заголовок для учетной записи, с которой пришло письмо, когда оно было загружено, и так далее. Вы можете доверять им, а можете и не доверять, и фактически, MUA могут иметь настройки, указывающие, каким x-заголовкам они должны доверять.

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

Итак, указывает ли порядок, какая почтовая программа вставила заголовок? Да, но … почтовые серверы могут соответствовать или не соответствовать всем частям RFC, и многие почтовые серверы следуют закону Postel и несколько снисходительны к тому, что они принимают.