이메일이 실제로는 거부되지 않아야 하는데도 불구하고 거부되는 이상한 사례가 많이 있는 것 같습니다. 이는 때때로 사용자가 보낸 지원 이메일을 우리가 전혀 확인하지 못하게 된다는 뜻입니다.
예를 들어, mac.com 주소에서 지원 주소로 보낸 이메일은 본문이 없다는 이유로(Email::Receiver::NoBodyDetectedError) 자주 거부됩니다. 하지만 해당 이메일에는 실제로 본문 텍스트가 있는 경우가 많으므로, 파싱 문제가 있을 수 있습니다.
하지만 잘못된 거부의 원인을 수정하는 것 외에도, 새로운 거부 사례가 발생하면 알림을 받을 수 있으면 좋겠습니다. 그러면 해당 거부 사례를 살펴보고 적절한 조치였는지 확인할 수 있습니다.
이는 모든 거부 사례에 대해 직원에게 알림을 보내는 옵션, 또는 모든 거부 이메일을 직원에게 CC(참조)로 보내는 옵션의 형태로 구현될 수 있습니다.
그렇지 않으면, 수신되는 지원 이메일을 하나도 놓치지 않으려면 Discourse 백엔드의 ‘거부된 이메일’ 목록을 계속 수동으로 확인해야 합니다. 이는 지루하고 불필요한 작업입니다.
2개의 좋아요
구체적인 예시에 초점을 맞추는 것이 더 나을 것 같습니다. “자주” 거부된다고 하셨는데, 이메일 콘텐츠에서 어떤 패턴을 발견하셨나요? 만약 일관된 문제였다면 mac.com에서 온 모든 이메일이 실패할 것으로 예상했을 것입니다.
2개의 좋아요
음… '자주’라는 건 '좀 짜증 날 정도로 자주’라는 뜻이죠. 저희가 가장 우려하는 부분은 지원팀의 응답 부족으로 인해 사람들이 화를 내는 것입니다.
제가 목격한 사례들을 패턴별로 살펴보았습니다. 처음에는 mac.com이 이메일을 처리하는 방식에 문제가 있는 것 같았지만, 이후 mac.com 주소를 사용하는 약 30명의 사용자에게는 아무런 문제가 발생하지 않는다는 것을 확인했습니다.
또한 mac.com에 웹메일 클라이언트가 있다면 HTML 이메일을 비표준 방식으로 처리하고 있을 수도 있다고 생각했습니다. 하지만 mac.com에 웹메일 클라이언트가 있는지도 정확히 모르겠습니다.
최근 발생한 사례의 이메일 본문이 인용된 줄로만 구성되어 있다는 사실을 깨달았을 때 문제를 파악했다고 생각했지만, 이후 테스트 결과 Discourse는 그런 이메일을 정상적으로 파싱하는 것으로 나타났습니다.
이런 일이 얼마나 자주 발생하는지, 그리고 패턴이 있는지 확인하기 위해 로그를 검토하겠습니다. 물론 Discourse가 가끔 이런 실수를 할 가능성이 존재하는 한, 경고 이메일은 충분히 간단한 안전장치라고 생각합니다.
조사 결과를 여기에 공유하겠습니다.
2개의 좋아요
Stephen
9월 12, 2020, 8:19오후
4
mac.com 이메일 주소는 실제로 iCloud.com 계정입니다. 애플은 5~6년 전 Mac.com과 me.com 계정을 iCloud로 이전했습니다.
설명해 주셔서 감사합니다. 기본적으로 mac.com 주소의 이메일에 문제가 발생하면 i.com 및 기타 iCloud 주소에도 영향을 미치겠군요.
실제 패턴은 없습니다. 거절 사유가 명확하지 않거나 옳지 않아 보이는 경우가 21건 있습니다.
1회 “Email can not be processed: Body is too similar to what you recently posted”
8회 “Email can not be processed: Email::Receiver::BadDestinationAddress” - 다소 미스터리한 부분입니다. 왜 주소가 잘못된 것일까요?
3회 “Email can not be processed: Email::Receiver::NoBodyDetectedError” - 두 건은 본문 텍스트가 정상적으로 보이며, 한 건은 'no body’라고만 표시되어 있습니다.
1회 “Email can not be processed: Email::Receiver::TooShortPost”
6회 “Email can not be processed”
1회 “Email can not be processed: Sorry, new users can only put one image in a post.”
1회 “Uncaught Error: Syntax error, unrecognized expression: #xxxxxx-email:product at company dot com”
이 중 여러 건은 고객의 정당한 소통 시도와 관련이 있었습니다. Discourse가 보낸 거절 이메일이 발신자의 스팸 폴더로 갔거나 단순히 무시되었는지는 여전히 명확하지 않습니다.
pfaffman
9월 14, 2020, 1:55오후
7
jrivettcsa:
왜 주소가 잘못된 건가요?
그들은 지원(support)과 같이 당신이 처리하지 않는 주소로 메일을 보냈습니다.
제 생각에는, 본문이 있다고 말했지만 실제로는 본문이 없는 부분만이 버그일 수 있는 것처럼 보입니다. 그 이유는 그들이 오래되고 고장 난 메일 클라이언트를 사용했기 때문일 수 있습니다.
이 중 몇 건(Email::Receiver::BadDestinationAddress)을 확인해 보니, 고객들의 정당한 회신으로 보이는 경우가 많았습니다. 수신자 주소 형식은 replies+긴식별자@discourse.site.com이었습니다. Discourse가 발신자에게 보내는 알림 이메일은 해당 이메일이 참조된 주제와 연관된 주소가 아닌 다른 주소에서 발송되었음을 시사하며, 이것이 아마도 원인이겠지만, 이런 경우에도 여전히 스태프에게 알림이 가기를 원합니다.
버그처럼 보이기는 하지만, 수정되기를 원하긴 해도 이런 경우는 항상 발생할 것이라고 생각합니다. 따라서 가능한 이메일 파싱 버그를 추적하는 것 외에도, 스태프에게 알림 이메일을 보내는 것이 그 사이 적시에 지원을 제공할 수 있게 해줄 것입니다.
저도 그렇게 생각하고 있었습니다. 다음에 이런 상황이 발생하면 고객에게 어떤 메일 클라이언트를 사용 중인지 물어보겠습니다.
1개의 좋아요
제가 하려는 말씀은, 이메일이 거부되는 경우 대부분 악의적인 목적이 아니라 단순히 지원을 요청하려는 사람들인 경우가 있다는 것입니다.
물론 Discourse가 거부하는 이메일 중에는 정말로 거부되어야 하는 것이 있는 경우도 있지만, 지원 요청 이메일을 놓칠 위험을 감수할 수 없으므로, 거부된 목록을 폴링하는 방식에 의존할 수밖에 없습니다.
그동안, 혼란을 겪는 발신자들은 웹사이트에 있는 연락처 양식과 같은 다른 수단을 통해 우리에게 연락할 수밖에 없습니다.
규모가 큰 사이트의 경우, 이메일 거부 알림이 처리하기엔 너무 많을 수 있지만, 우리 같은 경우엔 화난 고객을 대응하는 것보다 그 알림을 처리하는 것이 훨씬 쉬울 것입니다.
또한, Discourse가 발신자에게 유용한 정보를 포함하여 거부 이메일을 보내긴 하지만, 때때로 해당 이메일이 스팸 폴더로 들어가면서 영향을 받는 고객들의 혼란을 더욱 키우는 것 같습니다.
1개의 좋아요
pfaffman
9월 14, 2020, 5:21오후
10
그건 좀 골치 아픈 문제네요. 그 문제의 일부는 IMAP support for group inboxes 을 통해 해결할 수 있을 것 같습니다.
다만, 잘못된 메일함에서 회신하는 문제는 어떻게 해결해야 할지 모르겠네요. (그리고 나는 어떤 입장에 있든 상관없이 연락처 폼을 정말 싫어합니다!)
1개의 좋아요
justin
9월 14, 2020, 5:43오후
11
jrivettcsa:
이 중 몇 가지를 확인해 보니(Email::Receiver::BadDestinationAddress), 상당수가 고객으로부터 온 정당한 회신으로 보이며, 수신자 주소는 replies+longidentifier@discourse.site.com 과 같은 형식입니다. Discourse가 발신자에게 보내는 경고 이메일은 해당 이메일이 참조된 토픽에 연결된 주소가 아닌 다른 주소에서 발송되었음을 시사하며, 이것이 아마도 원인일 것입니다. 하지만 이런 경우에도 스태프에게 알림이 가기를 원합니다.
사용자가 이메일이 발송된 주소와 다른 주소에서 회신하는 경우, 이는 예상되는 상황입니다.
만약 이러한 이메일에 다른 이메일 주소로부터의 회신을 허용한다면, 다른 사용자가 특정 사용자를 사칭하여 이메일을 통해 계정을 악용하는 문제가 발생할 수 있습니다. 우리는 meta의 자체 지원 메시지에서도 가끔 이러한 문제에 부딪힙니다.
연락처 이메일 양식을 사용하는 경우, 보통 특정 이메일에서 발송되고 Reply-To 헤더를 설정하므로, 위에서 언급한 것과 동일한 문제에 직면하게 됩니다.
개인적으로는 좋은 해결책이 떠오르지 않습니다 – 아마 팀의 다른 누군가가 아이디어를 낼 수 있을지 모르겠습니다.
2개의 좋아요
네, 말씀드린 것처럼 이러한 응답을 거부하는 것이 합리적입니다. 하지만 이런 상황이 발생했을 때 알림을 받기를 원합니다.
연락처 양식을 언급한 이유는, 고객이 Discourse가 처리하는 지원 이메일 주소로 우리에게 연락할 수 없을 때 다른 대안을 찾아야 하기 때문에, 이는 이상적인 상황이 아니기 때문입니다.
1개의 좋아요
pfaffman
9월 14, 2020, 6:29오후
13
정확히 어떻게 해야 하는지 잘 모르겠습니다. /admin/email/rejected을 감시할 수는 있지만, 실제 알림을 받으려면 현재 플러그인이 필요합니다.
저도 잘 모르겠습니다. 그래서 이 내용을 기능 요청으로 게시한 것입니다.
네, 이해했습니다. 하지만 몇 분마다 해당 페이지로 가서 새로고침을 누르는 것은 다소 비효율적인 것 같습니다.
플러그인도 괜찮지만, 왜 이 기능이 Discourse에 직접 추가되지 않는지 이해가 되지 않습니다. 제 생각에는 당연한 기능입니다. Discourse는 이미 사이트 관리자와 스태프에게 다양한 알림을 보내고 있습니다. 설정(이메일 거부 시 알림)을 기본적으로 비활성화 상태로 두면 많은 사이트에서 작동할 것으로 생각합니다.
3개의 좋아요
또 다른 예로, 고객이 구매 관련 문제를 신고하기 위해 지원 주소로 이메일을 보냈습니다. Discourse는 해당 이메일을 거부했습니다: [Email::Receiver::InactiveUserError].
비활성화 상태의 사용자로부터 오는 이메일을 Discourse가 거부하는 것은 매우 합리적인 조치라는 점을 이해합니다. 하지만 동시에 우리 지원 팀에게도 알림이 간다면, 고객에게 즉시 연락하여 어떤 일이 발생했는지 그리고 어떻게 해결할 수 있는지 설명할 수 있을 것입니다.
그렇지 않으면, 거부 목록을 자주 확인하지 않는 한 고객은 두 가지 문제에 직면하게 됩니다. 이 두 문제 모두 자동화된 시스템의 결과이며, 우리 지원 팀은 이를 알지 못하게 됩니다. 이 단계에서的人工 개입은 중요하지만, 다시 한번 거부 목록을 수동으로 확인해야 하므로 응답 시간에 지연이 발생할 수 있습니다.
관리자가 이메일 거부 사항을 알림으로 받을 수 없는 기술적인 이유가 있을까요?
2개의 좋아요
이메일로 답글을 보낼 때, 내용이 너무 짧으면(예: “OK”) 잘못된 오류 메시지 이메일이 사용자에게 다시 전송됩니다. 이 문제는 다음 링크에서 보고했습니다: Wrong Error Message for too short replies for Reply-by-Email
또한 이러한 거절은 /admin/email/rejected에서 기록되지 않습니다. 이러한 사항이 어딘가에 기록되도록 개선되면 좋겠습니다.
1개의 좋아요
