У нас есть рабочий процесс, в котором мы используем Discourse как архив электронной почты. У нас есть общий адрес электронной почты, и наши агенты копируют его (Cc) при начале почтовой цепочки с клиентом.
Это работает отлично, пока клиент не ответит напрямую агенту, игнорируя все заголовки Cc и даже Reply-To. В таком случае агент должен переслать письмо (bounce) на общий адрес электронной почты. Пересылка (bounce) является предпочтительным методом здесь, чтобы Discourse архивировал исходное письмо со всеми оригинальными заголовками, временными метками и т. д.
Пересылка письма осуществляется путем копирования точного сообщения и добавления заголовков Resent-From и Resent-To. К сожалению, они игнорируются Email::Receiver. Система должна просто добавлять все заголовки Resent-* к соответствующим обычным полям.
Я начал реализовывать это и дошел до того, что create_incoming_email учитывает эти поля. После этого я мог видеть письма, включая получателей, взятых из Resent-To, в списке входящих писем в Discourse.
Однако мне не удается заставить get_all_recipients учитывать заголовки Resent-*. Я добавил resent-to resent-cc resent-bb в массив %i() полей письма, но это, похоже, всё ещё не возвращает получателей из этих полей.
Любая помощь будет приветствоваться, чтобы я мог создать PR для этого изменения!
Это выглядит как довольно опасная функция, подверженная подмене личности. Как вы предлагаете аутентифицировать пересылающего?
С помощью заголовка Resent-From. Но на самом деле это не имеет значения; ключевой вопрос в том, можно ли аутентифицировать оригинального отправителя, а не пересылающего.
Кроме того, в Discourse уже есть обработка пересланных писем.
Только для цитируемых пересылок. Это имеет несколько недостатков:
Оно не архивирует оригинальное письмо, а только цитируемую копию его тела
Нет поддержки сообщений, пересланных как вложение (с полными заголовками)
Реализация неполная (она полагается на один специальный префикс в теме для распознавания пересланного письма)
И как именно это происходит? Что, если пересылающий просто солжёт и полностью сфабрикует письмо, которое якобы было отправлено только ему?
Тогда он мог бы просто опустить все заголовки Resent- и сразу подделать письмо, не утверждая, что оно сначала было отправлено ему.
Кажется, у вас неверное представление о том, что делают заголовки Resent- — на самом деле они ничего не делают. При проверке SPF или DKIM почтовыми серверами они также не учитываются, поэтому подделка пересланного письма так же сложна, как и подделка оригинального.
В моём случае пересланное письмо от незнакомца извне будет заблокировано спам-фильтром из-за нарушения SPF. Причина, по которой мой сценарий с агентами, пересылающими письма в Discourse, работает, заключается в том, что после аутентификации на нашем почтовом сервере они освобождаются от этих проверок.
Таким образом, разрешение Discourse использовать заголовок Resent-To — это лишь функция удобства, поскольку именно так обычные почтовые клиенты создают поддельную копию ранее полученного письма. Это ничего не меняет в плане аутентификации.