디스코urs에서 알림을 받는 사용자들의 이메일 클라이언트에서 “작성자에게 답장” 또는 "전체에게 답장"을 선택할 수 있는 옵션이 어떻게 트리거될 수 있는지 알고 싶습니다.
현재 모든 메시지는 동일한 “답장 금지” 주소에서 발송되며, 수신자에게만 전송됩니다.
이메일 수신기(email-receiver)가 있는 시나리오에서, 발신자로 author_of+{reply_id}@my.discourse를 사용하고 수신자로 여러 주소(실제 수신자와 audience_of+{reply_id}@my.discourse)를 지정하는 단순한 접근 방식이 사용자로 하여금 이메일 클라이언트에서 수신자(작성자 또는 전체)를 선택할 수 있게 할 수 있을지에 대한 의견을 듣고 싶습니다.
이 문제는 꽤 나쁜 해결책이라고 생각합니다. 하지만 누군가가 요청해서 https://github.com/pfaffman/discourse-email-include-address를 작성했습니다.
이것은 이메일에 발신자 이메일 주소를 추가하여, 원할 경우 사람들이 직접 답장할 수 있게 해줍니다. 이렇게 하면 모든 사람의 이메일 주소가 노출되므로, Discourse 대신 Mailman을 사용하는 편이 낫다고 생각하는 사람들에게만 정말로 적합합니다.
제가 이 클라이언트를 위해 작성한 것이 2020년 11월 이후로 업그레이드되지 않았을 가능성이 높기 때문에, 여전히 작동하는지 알 수 없습니다. 첫눈에 보기에는 작동하는 것으로 보입니다.
공유해 주셔서 감사합니다.
저는 일반적으로 사용자 이메일 주소를 노출하지 않는 해결책을 찾고 있었습니다.
다만, 특정 카테고리는 이메일로 비공개 답변을 허용하도록 표시할 수 있으며, 이 경우 공식 이메일 주소를 추가로 노출할 수 있습니다. 이 공식 이메일 주소는 우리 사용자에게 이미 (또는 되어야) 잘 알려져 있을 것입니다.
이 경우, Discourse 내에서 비공개 또는 기밀 정보를 다룰 필요가 전혀 없습니다.
이 문제를 더 생각할수록 점점 더 마음에 듭니다.
다만, 귀하의 구현 방식과 달리 이메일 템플릿을 변경하는 대신 이메일 헤더를 변경하여 이 기능을 작동시키는 방식을 선호합니다.
DMARC 요건을 충족하기 위해 발신자 주소는 여전히 do-not-reply@my.discourse와 같은 형식이 되어야 한다고 생각합니다. reply-to: 헤더는 my.name@official.site가 되고, to: 필드에는 수신자와 reply-to-forum 이메일 주소가 포함됩니다.
네. 제 '해결책’은 확실히 거칠긴 합니다. #contribute:feature를 #support로 취급한 또 다른 사례인 것 같아 죄송합니다.
좋은 아이디어입니다. 얼마나 구현하기 어려울지 확실하지는 않습니다. 그래도 여전히 이메일 주소를 노출하게 되므로 코어에 포함되기는 어려울 것 같지만, 플러그인으로 구현하는 것은 가능할 것입니다. 바로 그 정도가 얼마나 어려울지는 잘 모르겠습니다