우리는 Discourse를 이메일 아카이브로 사용하는 워크플로우를 갖추고 있습니다. 그룹 메일 주소를 하나 두고 있으며, 에이전트가 고객과 이메일 스레드를 시작할 때 해당 주소를 Cc로 지정합니다.
고객이 에이전트에게만 직접 회신하여 모든 Cc와 심지어 Reply-To 헤더를 무시하는 경우를 제외하면 이 방식은 잘 작동합니다. 이 경우 에이전트는 이메일을 바운스(재전송)하여 그룹 메일 주소로 다시 보내야 합니다. 여기서는 바운싱이 선호되는 방법입니다. 이렇게 하면 Discourse가 모든 원래 헤더, 타임스탬프 등을 포함한 원본 이메일을 아카이브할 수 있기 때문입니다.
이메일 바운싱은 정확한 메시지를 복사하고 Resent-From 및 Resent-To 헤더를 추가하는 방식으로 수행됩니다. 불행히도 Email::Receiver는 이 헤더들을 무시합니다. Resent-* 헤더를 각각의 일반 필드에 단순히 추가해야 합니다.
저는 이를 구현하기 시작하여 create_incoming_email이 해당 필드를 고려하도록 만드는 단계까지 도달했습니다. 그러면 Discourse의 수신 이메일 목록에서 Resent-To에서 가져온 수신자를 포함한 이메일들을 확인할 수 있었습니다.
하지만 get_all_recipients가 Resent-* 필드를 존중하도록 만드는 것에는 아직 성공하지 못했습니다. 메일 필드의 %i() 배열에 resent-to resent-cc resent-bb를 추가했지만, 여전히 이러한 필드에서 수신자를 반환하지 않는 것 같습니다.
이 변경 사항에 대한 PR을 만들 수 있도록 도움이 필요합니다. 어떤 도움이라도 환영합니다!
그리고 정확히 어떻게 그런 일이 일어나는 건가요? 재발신자가 거짓말을 하고, 실제로는 자신에게만 발송된 것처럼 완전히 가짜 이메일을 만들어낸다면 어떻게 될까요?
그렇다면 Resent- 관련 헤더를 전부 빼고, 처음부터 메일을 위조하는 편이 훨씬 쉬울 겁니다. 처음에 자신에게 발송된 것처럼 주장하지 않아도 되니까요.
Resent- 헤더가 실제로 하는 역할에 대해 오해하고 계신 것 같습니다. 사실 Resent- 헤더는 아무것도 하지 않습니다. 메일 서버가 SPF나 DKIM을 확인할 때 이 헤더들은 고려되지 않으므로, 재발신된 메일을 위조하는 것은 원래 메일을 위조하는 것과 똑같이 어렵습니다.
제 경우, 외부의 낯선 사람으로부터 온 재발신 메일은 SPF 위반으로 인해 스팸 필터에 의해 차단됩니다. 에이전트가 메일을 Discourse로 재발신하는 시나리오가 제 경우 작동하는 이유는, 에이전트가 메일 서버에 인증된 후 이러한 검사에서 면제되기 때문입니다.
따라서 Discourse가 Resent-To 헤더를 사용하도록 허용하는 것은 단순한 편의 기능일 뿐입니다. 이는 일반 메일 클라이언트가 이전에 받은 메일의 위조된 사본을 만드는 방식과 동일하기 때문입니다. 인증 방식에는 아무런 변화가 없습니다.