Как я могу проанализировать электронную почту, чтобы получить первоначального получателя электронной почты?

У меня был с собой источник электронной почты, и я хочу проанализировать исходного получателя электронной почты.

Допустим, "user1@example.com" получает электронное письмо, но в списке "Кому" упоминаются user1@example.com, user2@example.com и user3@example.com. Я хочу получить только user1 из источника электронной почты.

При первоначальном анализе письмо от сервера mdeamon содержит тег «X-MDaemon-Deliver-To:». Точно так же электронное письмо от почтового сервера Devcot содержит "Delivered-To:". Но не получить общую логику синтаксического анализа для получения исходного получателя электронной почты.

В общем случае это невозможно делать то, о чем вы просите. Это также явно обескураженный в стандартной электронной почте Интернета.

Это может быть возможно в некоторых конкретных сценариях, но они будут очень конкретный. (Вероятно, в зависимости от конкретного используемого программного обеспечения, конфигурации программного обеспечения и т. Д.)

Причина в том, что сообщение электронной почты (RFC 5822) не содержит всей информации транспортного уровня (при этом SMTP RFC 5821). Дополнительно, включая вся эта информация может очень легко привести к раскрытию информации; смотрите также RFC 7258.

Тривиальный случай для иллюстрации этого - если вы отправляете электронное письмо нескольким получателям в одном домене, используя поле Bcc :. в этом случае передаваемое сообщение (данные полезной нагрузки, включая заголовки) не содержит информации о получателе конверта, и в этом случае заголовки трассировки обычно не содержат адреса получателя. Это означает, что синтаксический анализ адреса получателя из электронного письма становится не просто трудным, но и совершенно невозможным, поскольку информации там даже нет. Другие, совершенно достоверные примеры могут быть построены как расширение этого примера.

Цитата из RFC 5822, раздел 7.2:

Не существует внутренней взаимосвязи между «обратными» (из команд MAIL, SAML и т. Д.) Или «прямыми» (RCPT) адресами в транзакции SMTP («конверт») и адресами в разделе заголовка. Приемным системам НЕ СЛЕДУЕТ пытаться вывести такие отношения и используйте их для изменения раздела заголовка сообщения для доставки. Популярное поле заголовка «Очевидно-кому» является нарушением этого принципа, а также является частым источником непреднамеренного раскрытия информации, и его НЕ СЛЕДУЕТ использовать.

Обратите внимание на определение SHOULD NOT из RFC 2119:

НЕ СЛЕДУЕТ. Эта фраза или фраза «НЕ РЕКОМЕНДУЕТСЯ» означают, что в определенных обстоятельствах могут существовать веские причины, когда конкретное поведение является приемлемым или даже полезным, но следует понимать все последствия и тщательно взвешивать ситуацию, прежде чем реализовывать любое поведение, описанное с этот ярлык.

Цитата из RFC 7258, раздел 2:

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