우리는 메일 서버를 설정하여 HTTP를 통해 API로 Discourse로 메일을 전달하도록 했는데, 이는 잘 작동하고 있습니다. 이제 reply_by_email을 활성화하여 사용자가 메시지를 직접 답장할 수 있도록 하려고 합니다.
따라서 Rails 콘솔에서 reply_by_email을 활성화하려고 했지만, Discourse가 제 요청을 거부합니다:
discourse(prod)> SiteSetting.reply_by_email_address
=> "reply+%{reply_key}@<our-valid-domain>.de"
discourse(prod)> SiteSetting.email_in
=> true
discourse(prod)> SiteSetting.reply_by_email_enabled = true
lib/site_settings/type_supervisor.rb:271:in `validate_value': reply_by_email_enabled: You must enable either manual, POP3 polling or have a custom mail poller enabled before enabling reply by email. (Discourse::InvalidParameters)
from lib/site_settings/type_supervisor.rb:177:in `to_db_value'
from lib/site_setting_extension.rb:623:in `add_override!'
from lib/site_setting_extension.rb:990:in `block in setup_methods'
from (discourse):15:in `<main>'
맞습니다. 저는 두 가지를 모두 설정하지 않았으며, 대신 Postfix 메일 서버를 설정하여 Discourse의 API를 통해 이메일을 전달하도록 했습니다. 이것이 지원되는 구성인지 확실하지 않지만, 가능하다면 다른 메일 서버(mail-receiver)를 실행하는 것을 피하고 싶습니다.
“수동 폴링 활성화” 설정은 관리자 → 모든 사이트 설정 → 이메일 섹션에서도 찾을 수 있습니다.
그리고 저는 분명히 잠을 잘 수 없어서 이것저것 찾아보았는데, API를 통해 이메일 수신(email-in)을 설정하려는 사례는 매우 드문 것 같았습니다. 진행하시는데 도움이 될지 모르겠지만, 제가 발견한 내용은 다음과 같습니다:
(링크 목록)
검색하던 중 Discobot이 아마도 오래된 정보가 될 수 있는 내용을 보여 주었습니다:
Discourse API를 사용하면 메일 리시버 컨테이너에 의존하지 않고 수신된 이메일을 처리할 수 있습니다. /admin/email/handle_mail 엔드포인트는 POST를 통해 원본 이메일 내용을 받아들이므로, 스크립트나 커스텀 통합을 사용하여 이메일을 Discourse에 직접 전송할 수 있습니다. 이 방법은 SMTP 폴링이나 메일 리시버 컨테이너의 필요성을 완전히 우회합니다.
예를 들어, 원본 이메일 내용을 포함하는 email 파라미터를 가진 curl 명령을 사용하여 이메일을 Discourse로 보낼 수 있습니다. 이 접근 방식은 AWS Lambda나 다른 서버리스 함수와 같은 서비스를 사용할 때 커스텀 이메일 전달 설정에서 일반적으로 사용됩니다.
2018년: 이 게시글은 이메일 가이드를 언급하고 있습니다(거기 더 이상 존재하지 않는 용어를 참조하고 있음). 또한 다음과 같이 권장하고 있습니다: “이메일로 답장 기능을 작동시키는 가장 쉬운 방법은 다양한 프로바이더의 여러 API를 다루려고 하지 말고 메일 리시버 컨테이너 템플릿을 사용하는 것입니다.”