지식 베이스
기존 메일함 가져오기
지금 쓰는 곳에서 내보낸 아카이브든 계정 자체든, 이미 가지고 있는 메일을 그대로 가져옵니다. 스레드는 원래대로 묶이고 있어야 할 자리에 정리됩니다.
아직 미구현
아직 어떤 종류의 가져오기 기능도 없습니다. 이미 해결된 한 가지는 스레드 구성인데, 원본 헤더를 유지한 채 가져온 메일은 이후에 도착하는 메일과 자연스럽게 같은 스레드로 묶이기 때문입니다.
세부 사항
- 출시되지 않았습니다. 이곳의 어떤 것도 mbox, .eml 파일, 제공자 아카이브, IMAP 계정을 읽지 않으며, 가져오기를 시작할 화면도 없습니다. 그 읽기를 수행할 파서는 이미 의존성으로 들어와 있고 도착하는 모든 메시지에 이미 실행되고 있습니다. 없는 것은 아카이브를 메시지 단위로 쪼개어 파서에 넘겨줄 무언가입니다.
- 스레드 구성은 새로 할 일이 전혀 없습니다. 대화는 메시지의 References 헤더 첫 항목을 기준으로 묶이고, 없으면 In-Reply-To로, 그다음에는 메시지 자신의 id로 내려갑니다. 다른 모든 메일 시스템이 쓰는 규칙이므로, 그 세 헤더를 보존한 가져오기는 id 매핑 테이블도 두 번째 패스도 없이 스레드를 그대로 재현합니다. 그러면 가져온 메일은 이후에 도착하는 메일과 함께 묶입니다. 둘 다 같은 함수를 거치기 때문입니다.
- 배달 경로는 재사용할 수 있지만 그것이 하는 일의 대부분은 꺼야 합니다. 도착한 메시지는 피싱 점수가 매겨지고, AI 작성 여부가 검사되고, 요약되고, 검색용으로 임베딩되고, 파일 색인에 들어가고, 열려 있는 모든 탭으로 방송됩니다. 오래된 메시지 8만 건을 그 경로로 돌리면 모델 호출 8만 번과 알림 8만 번이 됩니다. 그래서 가져오기는 배달 경로의 다섯 번째 스위치가 아니라, 의도적으로 조용한 수집의 선례로 이미 존재하는 일회용 받은편지함 경로 옆에 있어야 합니다.
- 오래된 메일이 받은편지함에 떨어져서는 안 됩니다. 여기서 폴더는 라벨일 뿐이므로, 8년치 아카이브를 정리하는 일은 INBOX와 UNREAD 대신 ARCHIVE를 쓰는 문제입니다. 오늘 그 일을 하는 스위치는 부수 효과로 배달 보고서 연결도 억제하므로, 가져오기는 그것을 빌려 쓰지 말고 자체 스위치를 가져야 합니다. 날짜는 메시지에서 가져오므로 2019년 스레드는 이사한 날이 아니라 2019년으로 정렬됩니다.
- 같은 가져오기를 두 번 실행해도 메일함이 두 배가 되어서는 안 됩니다. 메시지는 이미 여기서 생성한 id가 아니라 메시지 id와 발신자 쌍으로 중복 제거되므로, 실패 후 재실행은 구조적으로 안전하며 이것이 재개 가능한 가져오기를 가능하게 하는 조건입니다. 그 주변에 없는 것은 장부입니다. 작업 레코드, 커서, 지켜볼 수 있는 진행 수, 그리고 들어오지 못한 항목의 목록입니다.
- 들어오는 길은 두 가지이며 규모가 같지 않습니다. 이미 가지고 있는 파일에는 파서와 큐만 있으면 되고, 모든 제공자가 요청하면 파일을 내줍니다. 살아 있는 계정을 그 제공자의 API로 읽으려면 OAuth 클라이언트, 동의 화면, 심사, 그리고 메일함 전체를 읽을 만큼 넓은 스코프가 필요한데, 그 스코프는 이 제품이 의도적으로 포기한 것입니다. 파일은 기록을 가지고 이곳으로 오는 길이고, 계정은 얼마나 넓은 접근 권한을 요구할지에 대한 별개의 결정입니다.