그룹 공용 메일함의 IMAP 지원

martin · 8월 12, 2020, 5:03오전

Discourse에서 IMAP 지원을 제거합니다. 자세한 내용은 이 게시물을 참조하세요 IMAP support for group inboxes - #39 by martin .

그룹 인박스용 IMAP 지원의 알파 버전을 소개합니다. 이 기능은 그룹별로 IMAP 자격 증명과 설정을 입력하여 그룹 인박스를 이메일 인박스와 동기화할 수 있는 기능을 추가합니다.

이것은 알파 단계의 기능으로, 100% 완성되거나 다듬어지지 않았습니다. 깨질 가능성이 매우 높으며, 현재 유지 관리하거나 프로덕션 환경에서 사용하지 않고 있습니다. 사용에 따른 모든 책임은 사용자 본인에게 있습니다!

장점

기존 모든 메일이 동기화되므로, 그룹이 Discourse 인박스를 바로 활용할 수 있습니다.
그룹의 메시지가 Discourse와 이메일 제공업체 사이에 동기화되어 단일 장애점이 없도록 합니다. 사람들은 이메일 계정이나 Discourse 내부에서 모두 답장할 수 있으며, 모든 것이 동기화됩니다.
이제 이메일 제공업체에서 Discourse 수신 메일함으로의 복잡한 전달 규칙을 설정할 필요가 없습니다.
이메일 라벨이 Discourse 태그와 동기화되어 깔끔하게 정리할 수 있습니다.
Discourse에서 답장하더라도, 그룹에 이메일을 보낸 사람에게 _설정된 이메일 주소_에서 답장한 것처럼 보입니다. 더 이상 혼란이 없습니다!

기능

수신 및 발신 메일은 모두 IMAP 서버와 Discourse 사이에 동기화되며, 분석된 이메일을 기반으로 적절한 주제와 게시물 답장이 생성됩니다. 답장은 Discourse 또는 IMAP 서버에서 생성할 수 있으며, 모든 것이 동기화됩니다!
이메일은 Discourse 그룹 인박스 또는 이메일 계정에서 답장할 수 있습니다.
Discourse 주제에 적용된 태그는 IMAP 서버의 이메일에 라벨로 생성되어 적용됩니다(이것은 제공업체에 따라 다름).
IMAP 서버에서 아카이브된 이메일은 그룹 인박스에 아카이브됩니다.
Discourse에서 아카이브된 그룹 개인 메시지 주제는 IMAP 서버에 아카이브됩니다.
IMAP 서버에서 삭제된 이메일은 그룹 인박스의 주제를 삭제합니다.
Discourse에서 삭제된 그룹 개인 메시지 주제는 IMAP 서버에서 삭제됩니다.
이 기능이 활성화된 그룹에서 보낸 이메일은 IMAP 설정에 설정된 것과 동일한 이메일 사용자 이름이 답장 주소로 설정됩니다.

시작하기

우선, 그룹에서 이 기능을 설정하기 전에 구성해야 하는 사이트 설정이 몇 가지 있습니다.

enable imap와 enable smtp 모두 활성화해야 합니다. IMAP는 메일 서버와의 동기화에 사용되고, SMTP는 메일 서버에서 이메일을 보내는 데 사용됩니다.
tagging enabled와 allow staff to tag pms - 라벨 동기화가 개인 메시지에 태그를 적용하므로 모두 활성화해야 합니다.
enable imap write - Discourse에서 만든 변경 사항(예: 태그, 주제 아카이브, 주제 삭제)이 메일 서버에 반영되기를 원한다면 활성화해야 합니다.
enable imap idle - 메일 서버가 IDLE을 지원하는 경우, 메일 서버에서 실시간 업데이트를 받을 수 있게 합니다. 이는 이메일 제공업체의 변경 사항이 Discourse에 반영되는 속도를 크게 높입니다. 이 기능을 켜는 것이 좋습니다(예: Gmail은 이를 지원합니다). 모든 세부 사항이 궁금하시다면 IDLE RFC에서 읽을 수 있습니다.
imap polling period mins - IDLE이 지원되지 않는 경우, IMAP 서버에서 변경 사항을 확인하기 전에 대기하는 분 단위입니다. 또한 enable imap write가 활성화된 경우 Discourse에서 IMAP 서버로 변경 사항을 보내기 사이의 대기 시간입니다. 최소값은 1분입니다.

이 설정들은 기본값으로 남겨둘 수 있으며, 동기화 문제를 발견하면 조정할 수 있습니다:

imap polling old emails - IMAP 박스가 폴링될 때마다 업데이트될 최대의 오래된 이메일(처리됨) 수(0은 전체를 의미함).
imap polling new emails - IMAP 박스가 폴링될 때마다 업데이트될 최대의 새로운 이메일(미처리) 수.
imap batch import email - 가져오기 모드(게시물 알림 비활성화)를 트리거하는 최소의 새로운 이메일 수.

라벨/태그가 IMAP 서버와 동기화되려면 tagging enabled와 allow staff to tag pms 사이트 설정을 활성화해야 합니다.

다음으로, IMAP 서버와 동기화하려는 그룹으로 이동하여 설정을 입력해야 합니다.

이 설정들은 제공업체에 따라 다르며, 자세한 내용은 아래를 참조하세요. 설정과 자격 증명을 입력한 후 "변경 사항 저장"을 클릭하면 IMAP 제공업체의 서버에 대해 자격 증명을 검증합니다. 성공하면 메일함 목록이 채워지며, 동기화할 메일함을 선택해야 합니다(이것도 제공업체에 따라 지침이 다름):

자격 증명 검증에 실패하면 페이지에 오류 메시지가 표시됩니다. 명확히 하자면, 입력된 SMTP 서버는 대량 이메일용으로 구성된 주요 Discourse SMTP가 아니라, 사용자 이름 및 비밀번호 아래에 입력된 계정 이름으로 이메일을 보내는 데 사용됩니다.

마지막으로, app.yml 파일의 env 섹션 내에 DISCOURSE_ENABLE_EMAIL_SYNC_DEMON: true를 추가하고 ./launcher rebuild를 실행해야 합니다. 이렇게 하면 백그라운드 워커가 시작되고 이메일 동기화가 시작됩니다!

제공업체별 정보

Gmail

앱 비밀번호를 생성해야 합니다. 그렇지 않으면 "보안성이 낮은 앱 액세스"를 켜야 하며, Google은 결국 이를 제거할 예정입니다. IMAP 설정에서 Gmail 계정 비밀번호 대신 이 비밀번호를 사용하세요. 자세한 내용은 Sign in with app passwords - Gmail Help 를 참조하세요.
SMTP와 IMAP에 다음 설정을 사용해야 합니다:
- IMAP 포트: 987
- SMTP 포트: 587
- IMAP 서버: imap.gmail.com
- SMTP 서버: smtp.gmail.com
- SMTP와 IMAP 모두 SSL 사용
“[Gmail]/All Mail” 메일함만 선택하여 동기화하는 것이 강력히 권장됩니다(곧 UI 기능이 될 예정).
Gmail에서는 이메일을 즉시 삭제하지 않고, Discourse에서 주제가 삭제될 때만 휴지통 메일함으로 이동합니다. 이후 Gmail 내부의 “30일” 삭제 기능이 작동합니다.
Discourse 주제에 적용된 태그는 Gmail에서 라벨을 생성하고 이메일 스레드에 적용합니다. Gmail의 라벨도 IMAP 메일함입니다!

제한 사항

이것은 알파 단계의 기능으로, 100% 완성되거나 다듬어지지 않았습니다. 따라서 현재 다음과 같은 제한 사항이 적용됩니다:

현재 IMAP 제공업체로는 Gmail만 지원됩니다. 일반적인 IMAP 기능이 일부 있지만, 작동이 보장되지 않습니다. Outlook online이 다음 주요 지원 대상입니다.
Gmail의 휴지통에서 삭제된 이메일을 복원하고 그 상태를 Discourse에 반영하는 것은 현재 불안정합니다.
이미 이메일이 동기화된 후 동기화 메일함을 변경하는 것은 권장되지 않으며, 많은 이상한 문제를 초래할 수 있습니다.
그룹당 하나의 메일함만 동기화할 수 있습니다.
그룹 간 통신은 미개척 영역이며 잘 작동하지 않습니다(예: 각 이메일이 다른 그룹에 설정된 경우, support@yoursite.com에서 team@yoursite.com으로 이메일을 보내는 경우).

이것은 알파 기능이기 때문에 다른 미묘한 함정이나 거친 부분도 있을 수 있습니다.

피드백 및 로드맵

Gmail로 이 기능을 사용하는 모든 분의 피드백을 환영합니다. 저는 버그/이슈를 해결하는 작업을 담당할 것입니다. 디버깅은 현재 약간 까다롭지만, 그 작업을 진행 중입니다!

다음으로 작업할 내용:

IMAP 로그를 더 쉽게 보고 문제가 발생한 부분을 파악할 수 있도록 디버깅 개선.
Gmail에서 선택할 수 있는 메일함을 제한하고 메일함 변경을 억제/허용하지 않도록 그룹 이메일 인터페이스 개선.
여러 그룹에서 동일한 IMAP 세부 정보를 사용하는 것을 방지하기 위한 검증 추가.
그룹 IMAP 설정 저장 방식 개선 및 자격 증명 검증에 대한 더 나은 UX.
Outlook 지원.

현재 이 기능을 숙달하는 동안, 이 기능은 호스팅 고객에게 제공되지 않습니다.

특별 감사

@dan과 @j.jaffeux는 이 거대한 기능의 주요 기여자이며, 이 기능은 오래된 기간 동안 작업되었습니다. 그들의 놀라운 작업 없이는 이 기능을 이 지점까지 발전시키고 이 발표를 할 수 없었을 것입니다 .

hellekin · 8월 12, 2020, 7:09오전

이것은 동시에 놀라운 소식이자 끔찍한 소식입니다. 설명해 드리겠습니다. 먼저, IMAP가 Discourse 그룹과 통합된다는 것은 훌륭한 소식입니다. 이는 그룹 정체성(올바른 원래 주소 사용)에 대해 여러 유용한 해결책을 제공하고, 여러 사용자가 동일한 IMAP 계정을 사용하는 것을 용이하게 합니다(원래 지원이 잘 되어 있지 않음, 예: 공유 읽기 상태 없음). 또한 ActivityPub 수신함으로의 길을 열어줍니다… 하지만 이는 연방 서비스(federated service)를 상당 부분 중앙 집중식 시스템으로 전환시킨 대형 이메일 기업들에게 유리한 구현 방식이기 때문에 끔찍한 소식이기도 합니다. 대규모 제공업체와 협력하는 유혹을 이해하지만, 이 기능이 베타 상태에 도달할 때까지 모든 이메일 제공업체가 지원되도록 IMAP 표준이 제공업체별 확장 기능보다 우선시되기를 바랍니다.

이를 가능하게 해주셔서 감사드립니다.

sam · 8월 12, 2020, 8:18오전

이 기능이 “알파” 버전으로 분류되는 데에는 큰 이유가 있습니다.

관찰자 입장에서 IMAP의 문제는 해석의 여지가 많은 부분을 다뤄야 한다는 점입니다.

물론 더 많은 제공업체와 호환되도록 만들고 싶습니다. 내부적으로 구글에 대한 선호가 있는 이유는, Discourse에서 실제로 구글을 사용하고 있기 때문에 먼저 우리 자신의 문제를 해결하고 싶었기 때문입니다.

더 많은 제공업체와의 호환성을 개선하기 위한 PR은 언제나 환영하며, 해당 PR이 없는 경우 시간이 지나면서 다른 제공업체와 함께 이 기능을 사용하려는 요구가 늘어나면 지원 기능을 구축할 것입니다.

martin · 8월 12, 2020, 8:52오전

공정한 비판입니다. @sam이 말했듯이, 우리가 Gmail을 먼저 집중적으로 다룬 이유는 우리가 Gmail을 사용하므로 우리에게 가장 관련성이 높기 때문입니다. 하지만 우리의 기본 “일반” 제공자는 RFC에 100% 준수하지는 않고 기능이 완전하지는 않지만, IMAP 프로토콜을 상당히 충실히 따르고 있다고 생각합니다… https://github.com/discourse/discourse/blob/master/lib/imap/providers/generic.rb 를 참고해 주세요. 이 구현에 필요한 추가 사항은 아카이빙(Archiving)과 삭제(Deleting)에 대한 특수 처리라고 생각합니다. 현재 우리는 삭제 시 단순히 \Deleted 플래그를 붙이고 EXPUNGE 명령을 보내지만, 특정 이메일 클라이언트에서는 이 방법을 사용하거나 먼저 휴지통 폴더로 이동시킨 후 EXPUNGE를 보내는 방식을 선택할 수 있습니다. IMAP에서 아카이빙의 표준이 무엇인지 정확히 알지 못합니다. 우리는 이러한 일반 메서드 중 일부를 오버라이드하는 Gmail 전용 제공자 클래스를 가지고 있습니다.

Gmail은 자체적인 특수 처리 방식과 Gmail IMAP 확장 기능이 있으므로, 테스트할 수 있는 더 “일반적인” IMAP 서버/제공자에 대한 제안이 있다면 큰 도움이 될 것입니다.

또한 Sam이 말했듯이, 개선에 대한 PR은 언제든지 환영합니다. 그렇지 않으면 수요에 맞춰 대응할 것이며, 이 기능을 원할 조직들의 또 다른 주요 사용 사례로 Outlook이 다음에 나올 것으로 예상됩니다(Outlook도 자체적인 특수 규칙이 있습니다… 예를 들어 아카이브가 폴더/메일박스인 경우와 레이블 지원이 없는 경우 등).

itsbhanusharma · 8월 12, 2020, 8:57오전

매우 흥미롭네요. 저희 회사는 최근 자체 메일서버에서 G-Suite로 전환했는데, 이 통합 기능을 통해 고객 문의에 응답하고 진행 상황 트래커를 관리하는 것이 훨씬 쉬워질 것 같습니다. @martin 님께 한 가지 질문이 있습니다. 그룹 인박스에서 수신된 메시지에 회신할 때 Gmail SMTP를 사용하는지, 아니면 Discourse를 대신하여 이메일을 보내도록 구성된 대량 SMTP를 사용하는지 명확하지가 않습니다. 플러그인 설명에 Gmail SMTP가 언급되어 있기는 하지만, 이 부분에 대해 확실한 답변을 듣고 싶습니다.

martin · 8월 12, 2020, 8:58오전

Gmail SMTP 서버가 답장을 보내는 데 사용됩니다. 이는 IMAP 동기화에 사용된 이메일 계정을 대신하여 답장을 보내기 때문입니다. 명확성을 위해 원글(OP)에 이에 대한 참고 사항을 추가하겠습니다.

itsbhanusharma · 8월 12, 2020, 9:02오전

정말 멋진 아이디어네요. 이걸 활용할 수 있는 용도가 정말 많을 것 같아요. @martin @dan @j.jaffeux님, 수고하셨습니다!

martin · 8월 17, 2020, 12:10오전

간단한 업데이트입니다. 지난주에 이 두 개의 PR을 병합했습니다. 첫 번째는 아카이빙 및 삭제가 작동하려면 태그 기능이 활성화되어 있지 않아도 되도록 수정한 것입니다:

github.com/discourse/discourse

FIX: Do not require tagging to be enabled for IMAP archive and delete (#10426)

master ← issue/imap-do-not-require-tagging-for-archive-and-delete

merged 04:04AM - 13 Aug 20 UTC

martin-brennan

+39 -9

Previously we did an early return if either SiteSetting.tagging_enabled or Site…Setting.allow_staff_to_tag_pms was false when updating the email on the IMAP server -- however this also stopped us from archiving or deleting emails if either of these were disabled.

두 번째는 이제 모든 IMAP 로그를 데이터베이스에 기록하여 더 쉽게 검사할 수 있도록 했습니다. 5일 이상 지난 로그를 삭제하는 작업이 매일 실행됩니다:

StanD · 8월 21, 2020, 10:47오후

정말 너무 좋네요! 감사합니다.

참고로, discourse가 제 사용자 이름/비밀번호를 받아들이도록 구글 이메일 계정에 애플리케이션 비밀번호를 생성해야 했습니다.

sunjam · 8월 23, 2020, 3:25오후

구글 측에서 2단계 인증을 사용하고 계신가요? 그렇다면 이는 표준적인 절차입니다.

StanD · 8월 23, 2020, 4:34오후

네. 앱 비밀번호를 만들려면 필요했던 것 같습니다(확실히 기억은 나지 않지만).

martin · 8월 23, 2020, 11:40오후

OP(첫 번째 게시물)에 이미 언급되어 있습니다. 그렇지 않으면 Gmail 계정이 “보안 수준이 낮은 앱”을 허용하도록 만들려면 매우 복잡한 절차를 거쳐야 합니다. Google의 OAuth를 지원해야 할 시점이 올 것 같습니다. 상황이 그렇게 흘러가고 있기 때문입니다.

StanD · 8월 24, 2020, 1:19오전

아! 제 독해력이 형편없다는 걸 언급했었나요?

martin · 8월 24, 2020, 1:25오전

괜찮아요! 중요한 사항이라 Gmail 목록 맨 위로 올리고 경고 표시도 몇 가지 추가했어요. 이런 문제를 다른 사람들에게 알려서 불편함을 줄여주려 해준 데 대해 감사해요

thoka · 2월 6, 2021, 1:10오전

Dovecot IMAP 서버와 메일 동기화에서 왜 실패하는지 이해하려고 합니다. (불행히도 Ruby나 Rails에 대한 경험이 없습니다.)

imap_sync_logs를 읽어보니, import 데몬이 루프에 갇혀 있습니다:

UIDVALIDITY = 1612565899 does not match expected 0, invalidating IMAP cache and resyncing emails for mailbox INBOX

따라서 이 경우 @group.imap_uid_validity가 업데이트되어야 하는지 궁금합니다:

github.com/discourse/discourse

lib/imap/sync.rb

f34fa999a


      
          # (synced emails) and fetches new emails.
          
          # TODO: Use `Net::IMAP.encode_utf7(@group.imap_mailbox_name)`?
          @status = @provider.open_mailbox(@group.imap_mailbox_name)
          
          if @status[:uid_validity] != @group.imap_uid_validity
            # If UID validity changes, the whole mailbox must be synchronized (all
            # emails are considered new and will be associated to existent topics
            # in Email::Reciever by matching Message-Ids).
            ImapSyncLog.warn("UIDVALIDITY = #{@status[:uid_validity]} does not match expected #{@group.imap_uid_validity}, invalidating IMAP cache and resyncing emails for mailbox #{@group.imap_mailbox_name}", @group)
            @group.imap_last_uid = 0
          end
          
          if idle && !can_idle?
            ImapSyncLog.warn("IMAP server for group cannot IDLE or imap idle site setting is disabled", @group)
            idle = false
          end
          
          if idle
            raise 'IMAP IDLE is disabled' if !SiteSetting.enable_imap_idle

이 값을 수동으로 업데이트한 후, import 데몬은 또 다른 루프에 갇힙니다.

Dovecot은 다음 코드에서 'LABELS'를 지원하지 않습니다:

github.com/discourse/discourse

lib/imap/sync.rb

f34fa999a


      
          
              # the email has moved mailboxes, we don't want to try marking as spam again next time
              ImapSyncLog.debug("Updating incoming ID #{incoming.id} uid data FROM [UID #{incoming.imap_uid} | UIDVALIDITY #{incoming.imap_uid_validity}] TO [UID #{matching_spam.uid} | UIDVALIDITY #{response.spam_uid_validity}] (SPAM)", @group)
              incoming.update(imap_uid_validity: response.spam_uid_validity, imap_uid: matching_spam.uid)
            end
          end
          
          def process_new_uids(new_uids, import_mode, all_old_uids_size, all_new_uids_size)
            ImapSyncLog.debug("Syncing #{new_uids.size} new emails (oldest first)", @group)
          
            emails = @provider.emails(new_uids, ['UID', 'FLAGS', 'LABELS', 'RFC822'])
            processed = 0
          
            # TODO (maybe): We might need something here to exclusively handle
            # the UID of the incoming email, so we don't end up with a race condition
            # where the same UID is handled multiple times before the group imap_X
            # columns are updated.
            emails.each do |email|
              # Synchronously process emails because the order of emails matter
              # (for example replies must be processed after the original email
              # to have a topic where the reply can be posted).

이로 인해 Net::IMAP::BadResponseError가 발생하지만, 불행히도 로그에 기록되지 않습니다.

이제 다음 사항들이 궁금합니다.

Dovecot의 커스텀 플래그 지원이 Discourse와의 양방향 동기화에 충분한지
lib/imap/providers/detector.rb에서 Dovecot을 어떻게 감지하는지
Dovecot 프로바이더에서 label 기능을 어떻게 에뮬레이션하는지

…

martin · 2월 7, 2021, 11:39오후

그룹 메일함의 IMAP 동기화는 아직 초기 단계의 기능으로, 현재는 Gmail만 지원합니다. 이론적으로는 dovecot 제공자를 작성할 수 있지만, 몇 주 전 메인 코드에서 Gmail 전용 기능을 사용하는 부분이 있어 이를 제공자별 코드로 이동해야 한다는 것을 발견했습니다. 죄송합니다만, 이 기능이 좀 더 안정화될 때까지 기다려 보시는 것이 좋을 수 있습니다.

thoka · 2월 8, 2021, 2:54오후

IIUC(제 이해가 맞다면), 'LABELS'는 Gmail의 비표준 기능입니다.
구글 IMAP와 표준 IMAP의 차이를 이해하고 싶습니다.

지금까지 제가 정리한 내용은 다음과 같습니다:

표준 IMAP	구글 IMAP
아카이브된 메일은 하위 폴더에 저장됨	모든 메일은 하나의 폴더에 저장됨 아카이브된 메시지는 “\INBOX” 레이블이 없음
사용자 정의 플래그는 시스템 플래그와 함께 저장됨	사용자 정의 플래그를 레이블로 저장

표준 IMAP 동기화를 시작하기 위해 다음 조치가 충분한가요?

표준 IMAP에서 플래그를 시스템 플래그와 사용자 정의 플래그로 분리하여 레이블을 에뮬레이션하는 것
email_is_archived를 프로바이더가 처리하도록 하는 것 (예: “archived” 플래그를 추가하고 테스트하는 것)

이것은 다음 줄에 영향을 미칩니다:

github.com/discourse/discourse

lib/imap/sync.rb

f34fa999a


      
                update_email(incoming_email)
                incoming_email.update(imap_sync: false)
              end
            end
          end
          
          def update_topic_archived_state(email, incoming_email, opts = {})
            topic = incoming_email.topic
          
            topic_is_archived = topic.group_archived_messages.size > 0
            email_is_archived = !email['LABELS'].include?('\\Inbox') && !email['LABELS'].include?('INBOX')
          
            if topic_is_archived && !email_is_archived
              ImapSyncLog.debug("Unarchiving topic ID #{topic.id}, email was unarchived", @group)
              GroupArchivedMessage.move_to_inbox!(@group.id, topic, skip_imap_sync: true)
            elsif !topic_is_archived && email_is_archived
              ImapSyncLog.debug("Archiving topic ID #{topic.id}, email was archived", @group)
              GroupArchivedMessage.archive!(@group.id, topic, skip_imap_sync: true)
            end
          end

github.com/discourse/discourse

lib/imap/sync.rb

f34fa999a


      
          # don't do any of these type of updates on anything but the OP in the
          # email thread -- archiving and deleting will be handled for the whole
          # thread depending on provider
          return if post&.post_number != 1
          topic = incoming_email.topic
          
          # if email is nil, the UID does not exist in the provider, meaning....
          #
          # A) the email has been deleted/moved to a different mailbox in the provider
          # B) the UID does not belong to the provider
          email = @provider.emails(incoming_email.imap_uid, ['FLAGS', 'LABELS']).first
          return if !email.present?
          
          labels = email['LABELS']
          flags = email['FLAGS']
          new_labels = []
          new_flags = []
          
          # Topic has been deleted if it is not present from the post, so we need
          # to trash the IMAP server email
          if !topic

github.com/discourse/discourse

lib/imap/sync.rb

f34fa999a


      
            return @provider.trash(incoming_email.imap_uid)
          end
          
          # the topic is archived, and the archive should be reflected in the IMAP
          # server
          topic_archived = topic.group_archived_messages.any?
          if !topic_archived
            # TODO: This is needed right now so the store below does not take it
            # away again...ideally we should unarchive and store the tag-labels
            # at the same time.
            new_labels << "\\Inbox"
          
            ImapSyncLog.debug("Unarchiving UID #{incoming_email.imap_uid} (incoming ID #{incoming_email.id})", @group)
          
            # some providers need special handling for unarchiving too
            @provider.unarchive(incoming_email.imap_uid)
          else
            ImapSyncLog.debug("Archiving UID #{incoming_email.imap_uid} (incoming ID #{incoming_email.id})", @group)
          
            # some providers need special handling for archiving. this way we preserve
            # any new tag-labels, and archive, even though it may cause extra requests

이 줄은 제게 이상해 보입니다:

github.com/discourse/discourse

lib/imap/sync.rb

f34fa999a


      
          
              # some providers need special handling for archiving. this way we preserve
              # any new tag-labels, and archive, even though it may cause extra requests
              # to the IMAP server
              @provider.archive(incoming_email.imap_uid)
            end
          
            # Sync topic status and labels with email flags and labels.
            if tagging_enabled?
              tags = topic.tags.pluck(:name)
              new_flags = tags.map { |tag| @provider.tag_to_flag(tag) }.reject(&:blank?)
              new_labels = new_labels.concat(tags.map { |tag| @provider.tag_to_label(tag) }.reject(&:blank?))
            end
          
            # regardless of whether the topic needs to be archived we still update
            # the flags and the labels
            @provider.store(incoming_email.imap_uid, 'FLAGS', flags, new_flags)
            @provider.store(incoming_email.imap_uid, 'LABELS', labels, new_labels)
          end
          
          def tagging_enabled?

모든 시스템 플래그는 Discourse의 태그에 의해 덮어쓰기됩니다.
이것이 모든 IMAP 플래그(\Answered, \Deleted, \Draft, \Flagged, \Recent and \Seen / $Forwarded, $MDNSent, $SubmitPending and $Submitted)를 잘 처리하는 것인가요?

StanD · 3월 29, 2021, 2:58오전

일段时间后 다시 이 문제를 확인하고 있습니다.

reply-to 헤더가 제대로 작동하는 방법을 아직 찾지 못했습니다. 특정 Gmail 계정으로 동기화될 그룹을 설정할 수는 있지만, 이메일로 회신을 시도하면 reply-to 주소가 Discourse에서 설정된 알림 이메일이 아니라 IMAP 주소로 설정되어 있습니다.

무엇을 놓치고 있는 건가요?

mognet · 10월 16, 2021, 4:15오후

GoDaddy 이메일 제공업체로 직접 테스트해 보았지만 성공하지 못했습니다. Gmail에서는 잘 작동하지만, 아쉽게도 저희는 자체 도메인을 사용하길 원합니다. 이 기능이 언제 정식 출시될 예정인지 업데이트가 있나요?

pfaffman · 10월 16, 2021, 5:58오후

참고로, Gmail에서는 유료로 자체 도메인을 사용할 수 있습니다.

글		댓글	조회수
Is it possible to use Discourse for e-mail? Product Support	5	1521	9월 9, 2021
Discourse settings: IMAP Product Support	1	102	8월 14, 2024
Discourse as a private email support portal Feature rfc , spec	43	23924	5월 10, 2016
Replacing Mailing lists: Email-In Feature	66	17939	10월 4, 2014
Migrate a mailing list to Discourse (mbox, Listserv, Google Groups, etc) Migrating to Discourse how-to	109	27237	4월 3, 2026

장점

기능

시작하기

제공업체별 정보

Gmail

제한 사항

피드백 및 로드맵

특별 감사

Related topics