다음은 제가 시행착오를 통해 관찰했지만, 문서화되어 있거나 경고나 오류 메시지로 확인한 적은 없는 내용입니다.
디스코스가 호스팅하는 저희 사이트(매우 감사드립니다!)에서, 카테고리에 대해 커스텀 수신 이메일 주소를 설정할 때 해당 주소가 foo+{something}@discoursemail.com 형식(여기서 'foo’은 저희 사이트의 일반 슬러그)으로 시작해야만 작동하는 것처럼 보입니다.
구체적으로, 저는 종종 새로운 카테고리를 만들고, 직관적이라고 생각하는 이메일 주소를 설정한 후, 해당 주소로 테스트 메일을 보내곤 합니다. 그런데 바운스 메일(수정: 결국 몇 시간 뒤에 한 통은 받았습니다)을 받지 못하거나, 저희 사이트의 수신 또는 거부 이메일 로그에 해당 메일이 표시되는 것을 볼 수 없었습니다. 그러다 결국 이전 경험을 떠올리고 주소를 foo+<이름>으로 설정한 후 다시 테스트를 해보았더니 즉시 작동했습니다.
제가 잘못 본 것이 아니라면, 이는 디스코스가 여러 호스팅 사이트 중 특정 사이트로 의도된 메일을 구별하기 위한 수단으로 이해할 수 있을 것 같습니다. 하지만 제 추측이 맞는지 확인하고 싶었습니다. 혹은 제 추측이 틀렸다면, 제가 처음 선택한 이메일 주소들이 왜 /dev/null로 사라지는 것처럼 보이는지에 대한 다른 설명이 있는지 알고 싶습니다.
저희 (호스티드) 사이트의 경우, …@{OUR PREFIX}.discoursemail.com이 옵션이라는 사실을 몰랐고, 기본 “수신 이메일 허용” 주소에서 …@discoursemail.com을 호스트네임으로 사용하도록 되어 있어서 이 형식만 사용해 보았습니다. (원래 질문에서 호스트네임을 누락했기 때문에 위 원본 질문을 수정하여 이 부분을 명확히 하였습니다.) 이 방법을 시도해 보겠습니다. 팁을 알려 주셔서 감사합니다!
다만, Discourse가 자체 호스팅 인스턴스의 이메일 주소를 검증할 수 없다는 점은 이해하고 있습니다. 하지만 호스티드 인스턴스에서 이메일 주소가 예상되는 형식이 아닐 경우 경고나 오류를 생성하는 것이 가능할까요? (또는 …discoursemail.com 주소를 사용할 때의 예상 형식일 경우요?)
저희와 같은 호스팅된 Discourse 사이트에서 발생하는 특정 문제라는 제 추측이 확인된 것 같습니다. 해당 필드에 입력된 …discoursemail.com 주소가 유효한지 검증하도록 하는 데 필요한 작업 수준은 정확히 모르겠지만, 그런 기능이 있었다면 지난 몇 년간 새 메일링 리스트와 별칭을 설정하면서 왜 작동하지 않는지 고민했던 시간과 답답함을 상당 부분 줄여 주었을 것입니다. 다른 사용자들에게도 도움이 될 것이라 생각합니다.
대안으로, 호스팅 사이트의 해당 필드에 slug+...@discoursemail.com 또는 ...@slug.discoursemail.com 형식의 유효한 주소가 필요하다는 작은 툴팁만 표시해도 큰 도움이 될 것입니다. 다만 호스팅된 Discourse 사이트에 한정하여 그 팁을 표시하는 것이 이 접근 방식의 실행 가능성을 떨어뜨리는지 모르겠습니다.
@supermathie — 배송지가 우편이 수신되는 주소보다 더 관련이 있다는 지적은 좋은 지적입니다.
이전 요청을 좀 더 구체적으로 다듬어 보면, @discoursemail.com 또는 @*.discoursemail.com 패턴에 해당하지만 slug+…로 시작하거나 @slug.discoursemail.com로 끝나지 않는 수신 이메일 주소를 입력하려는 시도에 대해 경고가 표시되면, Discourse에서 호스팅되는 커뮤니티에 여전히 유용할 것 같습니다.
이 방식은 첫 번째 경우(접미사로 discoursemail.com이 없으므로)를 허용하면서, slug-users@discouresmail.com과 같은 주소를 설정하려는 시도에 대해서는 여전히 경고를 표시합니다. 저는 항상 이런 패턴의 주소를 설정하려고 했다가, 해당 주소로 온 메일이 조용히 폐기되는 것을 보고 혼란을 겪곤 했습니다.
(contoso가 커뮤니티의 슬러그라고 가정하면, 두 번째 경우에도 경고가 표시되지 않을 것입니다.)