[이 문의에 대한 배경 설명: 우리는 Discourse가 제공하는 인스턴스를 사용하는 오픈소스 프로젝트이며, 이에 감사드립니다.]
우리 커뮤니티 구성원들을 혼란스럽게 만드는 동작을 겪고 있으며, 이 상황을 개선하기 위한 지침이나 모범 사례를 찾고 있습니다. 구체적으로 다음과 같습니다:
우리 Discourse 인스턴스가 보내는 이메일 알림에는 From: 주소로 [project]@discoursemail.com이 표시되며, Reply-To: 주소는 원본 주제로 회신을 올바르게 라우팅합니다.
수신자가 “Reply”(전체 답장) 대신 “Reply To”(수신자에게 답장)를 사용하여 이러한 이메일에 회신할 때(이것이 메시지 원저자에게 포럼 밖에서 답신할 수 있다고 잘못 믿고), 다음과 같은 메시지를 받게 됩니다:
죄송합니다. [“[project]@discoursemail.com”](제목: Re: [제목])로 보낸 이메일 메시지가 작동하지 않았습니다.
여러 이메일 주소를 사용하시나요? 다른 이메일 주소에서 답신을 보낸 건가요? 이메일 답신에는 답신 시 동일한 이메일 주소를 사용해야 합니다. 또는 이메일의 Message-ID 헤더가 수정되었을 수 있습니다.
이로 인해 수신자들은 자신이 보낸 이메일 주소에 문제가 있는 것으로 오해하게 됩니다(받는 주소가 아니라). 하지만 다시 확인해 보면 자신의 계정 주소임을 발견하고, 무엇이 잘못되었는지 궁금해하며 도움을 요청합니다.
이로 인해 다음과 같은 점이 궁금해졌습니다:
이러한 메일이 발송되는 이메일 주소를 noreply@discoursemail.com처럼 보이거나, 적어도 유효한 이메일 주소처럼 보이지 않는 다른 것으로 설정할 방법이 있을까요?
우리나 Discourse가 발송 주소로 보낸 답신에 대한 오류 메시지를 전문화하여, "수신 메일을 받지 않는 이메일 주소로 답신을 보냈습니다. Discourse 알림 메일에 답신하려는 경우 Reply-To: 주소를 사용하거나 저자에게 직접 연락해 주세요."와 같이 더 명확하게 표시할 방법이 있을까요?
[이 게시물을 작성하기 전에 무언가를 놓쳤다면 죄송합니다. meta.discourse.org에서 유사한 질문을 하는 다른 메시지들을 찾았지만, 그 어떤 것도 답변으로 이어지지 않았습니다. 다만, 검색 결과를 좁힐 수 있는 키워드를 찾는 것이 쉽지 않았습니다.]
이 기능을 사용할 수 있는 설정이 있는지 제가 알기론 없습니다. 제 개인 이메일 받은 편지함을 살펴본 결과, 발신자(From)와 답장 주소(Reply To) 필드가 일치하지 않는 경우가 꽤 흔한 것 같습니다. no-reply 이메일 주소에서 메일을 보내되, 답장 주소는 실제 답장을 받을 수 있는 적절한 주소로 설정하는 애플리케이션의 예시를 여러 번 확인했습니다. 다른 애플리케이션들도 Discourse와 유사하게 처리하는 것 같습니다. 즉, 실제처럼 보이는 발신자 주소를 사용하되, 답장은 Reply To 이메일 주소로 이루어진다는 전제 하에 동작합니다.
발신자 주소를 noreply@<domain.com>으로 설정할 수 있는 사이트 설정이 제가 모르는 한이 있다면 모를까, 없다면 해당 설정을 추가하는 것이 합리적인 기능 요청이라고 생각합니다.
잘못 동작하는 메일링 리스트는 답장 주소를 리스트 주소로 설정해 두며, 발신자에게 답장하고 싶은 사용자는 발신자 주소(메시지를 보낸 사람의 주소)로 주소를 변경할 수 있습니다. 저는 이 동작이 너무 강해서 사람들이 메시지의 작성자가 될 수 없는 주소임을 확인하기 위해 주소를 살펴보는 경우가 거의 없을 것이라고 추측합니다.
메일 중심의 특정 커뮤니티를 위해 게시자의 이메일 주소를 표시하여 이메일을 통해 발신자에게 직접 답장할 수 있도록 하는 플러그인을 작성한 적이 있습니다.
이 문제를 겪은 팀원 중 일부는 Thunderbird를 사용하고 있으므로, @Beakerton 님이 언급한 동작과 같은 문제를 겪었을 가능성이 높습니다. (구식 유닉스 기반 메일 클라이언트도 같은 동작을 한다는 것을 알고 있으며, 이 답변을 작성하기 전까지는 Outlook에서 이를 쉽게 할 수 없다는 사실을 실제로 인지하지 못하고 있었습니다.) 관심 있으신 분들을 위해, 메일 클라이언트가 불분명한 다른 사용자들에게 어떻게 이런 상황이 발생했는지 물어볼 수 있지만, 아마도 유사할 것으로 예상됩니다.
그렇게일 수도 있습니다. 아니면 그 생각을 하고 있다면, Discourse의 어떤 “마법 같은” 기능이 발신인 주소를 익명화하지만 응답이 그 사람에게 도달하도록 보장한다고 믿을 수도 있습니다? (이것이 사실 아님을 알며 그 이유를 이해하므로, 이것이 있어야 한다고 제안하는 것은 아닙니다.)
@simon 님이 여기서 언급한 대로 “From:” 주소를 더 합리적인 주소처럼 보이지 않는 것으로 사용자 지정하는 것이 다음과 같은 장점이 있다고 생각합니다:
주의를 기울이는 사람들에게 그런 착각을 해소해 주거나, 아니면 나중에 보낸 메시지를 다시 확인했을 때 일이 제대로 되지 않은 것이 덜 놀랍도록 만들어 줄 수 있습니다. 하지만 “잘못된 수신 주소” 메시지를 사용자 지정할 수 있다면 아마도 95%는 해결할 수 있을 것 같으므로, 이 부분을 더 자세히 살펴보겠습니다.
1월 중순경에 발견하고 테스트해 본 결과, 분명히 Thunderbird의 문제임이 확인되었습니다:
답장 - 메시지 1건 - [noreply@forum.xxxxx.com](mailto:noreply@forum.xxxxx.com)으로 전송됨
전체 답장 - 메시지 2건 - [noreply@forum.xxxxx.com](mailto:noreply@forum.cxxxx.com)
과 [xxxxx.reply+a22deef75085bcafd42f8a99cf58e7cd@gmail.com](mailto:xxxxx.reply+a22deef75085bcafd42f8a99cf58e7cd@gmail.com)
두 곳으로 전송됨
목록으로 답장 - 메시지 1건 -
[xxxxx.reply+a22deef75085bcafd42f8a99cf58e7cd@gmail.com](mailto:xxxxx.reply+a22deef75085bcafd42f8a99cf58e7cd@gmail.com)으로 전송됨
이 문제를 해결하기 위한 Thunderbird용 애드온도 존재하는 것으로 나타났습니다:
@simon님의위 메시지의 팁 덕분에 오류 메시지를 업데이트했으며, 이로 인해 커뮤니티 일부에서 느꼈던 혼란을 해소할 수 있을 것으로 생각합니다. noreply@discoursemail.com과 같이 “From:” 주소를 더 잘 어울리는 형태로 사용자 지정할 수 있는 방법이 있다면 좋겠지만, 현재로서는 훨씬 나아진 상태라고 생각합니다.
다시 한번 도움을 주셔서 감사합니다.
-Brad
P.S. — 이 스레드에서 Thunderbird를 언급하고 있는 만큼, HTML 형식의 메시지 내 URL이 Discourse의 수신 메일 처리 필터에서 무시되는 것처럼 보이는 문제가 여전히 Thunderbird 사용자에게 의아하게 느껴진다는 점을 언급하고 싶습니다. 이 문제가 Thunderbird의 버그인지, 아니면 Discourse의 버그인지는 아직까지 저에게도 명확하지 않습니다.
이 피드백을 바탕으로 에러 메시지도 전반적으로 개선할 예정입니다. 현재 베타 버전과 향후 릴리스에서는 다음과 같이 표시됩니다:
죄송합니다. %{destination}(제목: %{former_title})으로 보낸 이메일 메시지가 처리되지 않았습니다.
다음 항목을 확인해 주세요:
- 여러 이메일 주소를 사용 중이신가요? 원래 사용했던 이메일 주소와 다른 주소에서 회신을 보낸 건 아닌가요? 이메일 회신을 보내려면 동일한 이메일 주소를 사용해야 합니다.
- 이메일 소프트웨어가 회신 시 Reply-To: 이메일 주소를 올바르게 사용했나요? 불행히도 일부 이메일 소프트웨어는 회신을 From: 주소로 잘못 보내며, 이 경우 작동하지 않습니다.
- 이메일의 Message-ID 헤더가 수정되었나요? Message-ID는 일관성을 유지하고 변경되지 않아야 합니다.
더 도움이 필요하신가요? %{base_url}/about의 문의하기 정보를 통해 저희에게 연락해 주세요.
List-Post 필드는 리스트에 게시하는 방법을 설명합니다. 이는 일반적으로 리스트의 주소이지만, модератор(중재자)이거나 다른 형태의 제출 방식일 수도 있습니다. 게시가 허용되지 않는 리스트(예: 공지 리스트)의 특수한 경우, List-Post 필드에는 특수 값 "NO"가 포함될 수 있습니다.
