arasystem/docs/mail/api-contract.md

인증·메일 API 계약 (1단계)

백엔드와 프론트엔드를 병렬로 만들기 위한 계약이다. 구현이 끝나면 Swagger(/api-docs)와 프론트 타입이 기준이며, 이 문서와 어긋나면 이 문서를 고친다. 바꿔야 할 일이 생기면 한쪽에서 조용히 바꾸지 말고 이 문서부터 고친 뒤 양쪽에 알린다.

공통 규칙은 그대로 따른다 — 표준 응답 래퍼(response-format), 에러 코드(error-codes), API 규약(api-design).

• 성공 { "success": true, "data": … } / 실패 { "success": false, "error": { "code", "message", "traceId" } }
• 날짜·시각은 ISO 8601 UTC 문자열, 목록은 { items, pageInfo }
• 이 단계에서 쓰는 에러 코드: AUTH_001 AUTH_002(클라이언트 전용) AUTH_003 AUTH_004 AUTH_005 VAL_001 RES_001 REQ_001 FILE_001 FILE_002 MAIL_001 MAIL_002 MAIL_003 MAIL_004 MAIL_005 MAIL_006 MAIL_007 MAIL_008 MAIL_009 MAIL_010 MAIL_011 MAIL_012 MAIL_013 SYS_001
• 적용 범위: 1단계는 웹(브라우저) 전용이다. 인증은 HttpOnly 쿠키뿐이고 토큰을 본문으로 주지 않는다. 모바일 앱(Flutter)의 인증 방식(토큰 발급·flutter_secure_storage)은 앱 착수 때 이 문서에 추가한다.
• 배포 형태: 화면과 API 는 같은 주소(origin)를 쓴다. 운영은 프론트 nginx 가 /api 를 백엔드로 넘기고, 개발은 vite 프록시가 넘긴다. 그래서 CORS 가 필요 없고 CSP connect-src 'self' 로 충분하다.
• 출처 검사(CSRF): 상태를 바꾸는 요청(POST·PATCH·PUT·DELETE)은 브라우저가 붙이는 Sec-Fetch-Site·Origin 을 검사한다. 다른 사이트에서 온 요청은 403 AUTH_003. 출처 정보가 아예 없는 요청(브라우저가 아닌 클라이언트)은 통과한다.
• 프록시가 직접 내는 오류: 프론트 nginx 가 백엔드에 닿기 전에 끝내는 요청도 표준 실패 형식으로 온다 — 본문 한도 초과 413 FILE_002, 백엔드 응답 없음 502·시간 초과 504 SYS_001. traceId 는 nginx 요청 ID 이고 message 는 비어 있을 수 있으니 클라이언트는 코드로 사전 문구를 쓴다.

---

1. 인증 (쿠키 기반 — 토큰은 응답 본문에 없다)

쿠키	내용	속성
access_token	액세스 JWT (JWT_ACCESS_EXPIRES_IN, 기본 1h)	HttpOnly · SameSite=Lax · Path=/api · 운영 Secure
refresh_token	리프레시 JWT (JWT_REFRESH_EXPIRES_IN, 기본 14d)	HttpOnly · SameSite=Strict · Path=/api/auth · 운영 Secure

직원 계정 = 메일 계정이다. 백엔드는 로그인할 때만 비밀번호를 메일 엔진(Stalwart)에 확인하고 저장하지 않는다.

POST /api/auth/login

// 요청
{ "email": "ara.kim@arasystem.it.kr", "password": "…" }
// 200 + Set-Cookie(access_token, refresh_token)
{ "email": "ara.kim@arasystem.it.kr", "name": "김아라" }

실패	코드
계정 없음 · 비밀번호 틀림 · 사내 도메인이 아닌 주소 · 메일 엔진 관리자 계정(웹메일 로그인 대상이 아니다) (구분하지 않는다)	401 AUTH_004
형식 오류	400 VAL_001
시도 과다 — 같은 IP 에서 1분에 실패 20회, 같은 주소로 15분에 실패 10회 (성공한 로그인은 세지 않는다 — 사무실처럼 여러 직원이 한 IP 를 쓰는 환경 때문). 이와 별도로 같은 IP 의 로그인 요청은 1분에 60회까지. "같은 IP" 는 IPv6 를 /64 단위로 묶는다(IPv4-mapped 주소는 IPv4 로). 사내 도메인이 아닌 주소는 IP 한도에만 센다. 비밀번호 변경(PUT /api/auth/password)의 지금 비밀번호 틀림도 같은 한도로 함께 센다	429 REQ_001
같은 주소의 로그인 · 비밀번호 변경이 아직 처리 중 (버튼을 두 번 누른 경우 등)	429 REQ_001
대량 공격으로 서버가 기억하는 시도 기록이 상한에 닿았고 밀어낼 수 있는 기록이 없음 — 새 IP·주소의 로그인 (잠금 기록을 지키려고 막는 쪽을 택한다)	429 REQ_001
메일 엔진 장애	503 MAIL_001

GET /api/auth/me

앱 시작 시 세션 복원용. 200 { "email", "name" } / 로그인 안 됨 401 AUTH_001.

POST /api/auth/refresh

리프레시 쿠키로 두 쿠키를 새로 발급한다(회전). 200 { "email", "name" }.

실패	응답	세션·쿠키
쿠키 없음·만료·끊긴 세션, 메일 엔진이 계정을 찾지 못함(대리 접근 401), 그 계정이 엔진 관리 권한을 얻음	401 AUTH_001	쿠키 삭제·세션 폐기
메일 엔진 장애, 게이트웨이의 대리 접근 권한 문제(엔진 403 — 설정 실수)	503 MAIL_001	유지 — 설정을 고치면 그대로 이어 쓴다
서버 쪽 드문 불일치(회전 충돌)	500 SYS_001	유지 — 같은 쿠키로 다시 시도할 수 있다

세션 규칙 (서버에 저장한다)

• 로그인하면 서버에 세션이 하나 생긴다. 리프레시 토큰은 1회용이다 — 갱신할 때마다 새 토큰을 주고 이전 토큰은 폐기한다.
• 이미 쓴 리프레시 토큰이 다시 오면 탈취로 보고 그 세션 전체를 끊는다 → 401 AUTH_001.
  • 예외(유예): 회전 직후 30초 안에 바로 이전 토큰이 오면(탭 여러 개가 동시에 갱신한 경우) 세션을 끊지 않고 200 { "email", "name" } 으로 답하되 쿠키는 새로 주지 않는다 — 먼저 갱신한 요청이 받은 쿠키를 같이 쓴다. 두 번 이상 지난 토큰이나 30초가 지난 이전 토큰은 위 규칙대로 세션을 끊는다.
• 세션은 로그인 후 최대 30일(절대 만료)이다. 그 안에서도 리프레시 토큰을 14일 동안 쓰지 않으면 끝난다.
• 액세스 토큰은 서버 조회 없이 검증한다. 그래서 세션을 끊어도 이미 발급된 액세스 토큰은 만료(최대 1시간)까지 유효하다.

POST /api/auth/logout

항상 200 (data: null). 두 쿠키를 지우고 서버의 세션을 폐기한다.

PUT /api/auth/password — 4단계

// 요청 (로그인 필요)
{ "currentPassword": "…", "newPassword": "…" }
// 200 (data: null)

실패	코드
지금 비밀번호가 틀림	400 AUTH_005 — 세션은 그대로다. 401 이 아닌 까닭: 클라이언트는 401 이면 세션을 갱신하고 같은 요청을 다시 보낸다
새 비밀번호가 8자 미만 · 128자 초과 · 지금 비밀번호와 같음, 엔진 규칙에 어긋남 · 지금 비밀번호가 비었거나 256자 초과(로그인과 같은 한도) — 길이는 JS 문자열 길이	400 VAL_001
지금 비밀번호 틀림이 잦음 — 로그인 실패와 같은 한도(같은 IP 1분 20회 · 같은 주소 15분 10회)를 함께 센다. 같은 주소의 로그인 · 변경이 처리 중	429 REQ_001
웹메일로 다루지 않는 계정(메일 엔진 관리자 · 게이트웨이 · 막은 계정 — 엔진에 묻지 않는다)	401 AUTH_001
메일 엔진 장애 — 바꾸는 요청의 결과를 알 수 없는 실패(시간 초과 · 연결 끊김 · 5xx)도	503 MAIL_001 — 결과를 모를 때는 바뀌었을 수 있으므로 다른 세션을 끊어 둔다

• 서버는 메일 엔진에 그 직원 본인의 자격으로(지금 비밀번호) 본인 비밀번호 변경(Stalwart x:AccountPassword/set 에 currentSecret · secret)을 보낸다 — 게이트웨이 대리 접근이나 관리자 권한을 쓰지 않는다. 엔진은 지금 비밀번호 없이는 바꾸지 않고 8자 미만을 거절한다 (2026-10-28 개발 엔진에서 확인). 세션은 같은 값으로 열렸는데 엔진이 바꾸기를 거절하면(forbidden · currentSecret 의 invalidProperties · 바꾸기 요청의 401 — 앱 비밀번호를 넣은 경우 · 역할의 권한 설정) AUTH_005 로 답하되 실패 횟수로 세지 않고 세션도 끊지 않는다(추측이 아니라서). 결과를 알 수 없는 실패도 실패 횟수로 세지 않는다.
• 바뀌면 그 직원의 다른 로그인 세션을 모두 끊는다 — 이 요청의 리프레시 쿠키(Path=/api/auth 라 이 요청에도 온다)가 가리키는 세션만 남긴다. 쿠키가 없거나 다른 직원 것이면 이 세션도 끊긴다(다음 갱신에서 로그인 화면으로). 끊긴 기기의 액세스 토큰은 만료(최대 1시간)까지 쓰인다(위 세션 규칙). 휴대폰 · PC 메일 프로그램(IMAP)은 새 비밀번호를 다시 넣어야 한다.
• 비밀번호는 바뀌었는데 세션 끊기가 실패하면 200 으로 답하고 오류 로그를 남긴다 — 실패로 답하면 사용자가 옛 비밀번호로 다시 시도하기 때문이다.
• 비밀번호는 로그 · 응답에 남기지 않는다. 바꾼 일은 info 로그에 주소(가린 것)만 남긴다.
• 클라이언트: 같은 규칙(8자 이상 · 지금과 다름 · 확인 칸 일치)을 먼저 보고, AUTH_005 는 지금 비밀번호 칸 아래에 사전 문구로 보인다. 성공하면 세 칸을 비운다. 요청 한도는 30초다 — 서버가 엔진을 두 번 부르고 세션을 끊으므로, 기본 한도(10초)로는 서버가 바꾼 뒤 화면만 실패로 볼 수 있다.

클라이언트 처리 규칙

• 보호 API 가 401 AUTH_001 을 주면 한 번만 /auth/refresh 를 시도하고, 성공하면 원래 요청을 다시 보낸다. 실패하면 기존 규칙대로 AUTH_002 로 승격하고 로그인 화면으로 보낸다. /auth/login · /auth/refresh · /auth/me · /auth/logout 은 이 재시도 대상이 아니다.
• /auth/refresh 의 200 은 Set-Cookie 가 없어도 성공으로 다룬다 (위 유예 응답).
• 세션이 끝난 것은 /auth/refresh 의 401 AUTH_001 뿐이다. 5xx(MAIL_001·SYS_001)·네트워크 오류는 일시 장애로 알리고 로그아웃으로 다루지 않는다.
• 로그인 버튼은 응답이 올 때까지 다시 누를 수 없게 한다 — 같은 주소로 동시에 보낸 두 번째 요청은 429 REQ_001 이다.
• 로그아웃하면 같은 브라우저의 다른 탭에도 알린다(BroadcastChannel). 알림을 받은 탭은 로그인 화면으로 간다.
• 로그아웃(어느 탭에서든) 뒤에 도착한 /auth/refresh 성공은 쓰지 않고 /auth/logout 을 한 번 더 부른다. 갱신과 로그아웃이 겹치면 서버가 로그아웃 뒤에 새 쿠키를 구울 수 있기 때문이다 (세션은 끊겼어도 액세스 토큰은 만료까지 유효).
• 앱 시작 시 /auth/me 로 세션을 복원한다. 이 호출의 AUTH_001 은 로그인 전 정상 상태이므로 알림을 띄우지 않는다.
• 복원 중 /auth/me 가 AUTH_001 이면 액세스 토큰만 만료됐을 수 있으므로 /auth/refresh 를 알림 없이 한 번 부르고, 성공하면 복원 완료, 실패하면 로그아웃 상태로 시작한다. → 백엔드는 액세스 쿠키가 없거나 만료돼도 리프레시 쿠키만으로 /auth/refresh 가 동작해야 한다.

---

2. 메일 (모두 로그인 필요 — 없으면 401 AUTH_001)

타입

interface Address { name: string | null; email: string }

interface Mailbox {
  id: string
  name: string            // 역할이 있으면 한국어 표준 이름, 없으면 서버의 이름
  role: 'inbox' | 'drafts' | 'sent' | 'junk' | 'trash' | 'archive' | null
  parentId: string | null
  sortOrder: number
  totalCount: number
  unreadCount: number
}

interface MessageSummary {
  id: string
  threadId: string
  mailboxIds: string[]
  from: Address | null
  to: Address[]
  subject: string         // 제목이 없으면 빈 문자열
  preview: string
  receivedAt: string
  isRead: boolean
  isFlagged: boolean
  hasAttachment: boolean  // 본문 그림(아래)만 있으면 false — 서명 그림만 붙은 메일은 첨부 표시를 하지 않는다
  size: number            // 바이트
}

interface MessageDetail extends MessageSummary {
  cc: Address[]
  bcc: Address[]
  replyTo: Address[]
  sentAt: string | null
  messageId: string | null    // Message-ID 헤더 (답장 스레드 연결용)
  references: string[]
  htmlBody: string | null     // 서버가 정화한 HTML (아래 참고)
  textBody: string | null
  hasBlockedImages: boolean   // 외부 이미지를 지웠으면 true → "외부 이미지 차단" 안내
  isHtmlBodyOmitted: boolean  // HTML 이 있었지만 정화 한도를 넘어 htmlBody 를 비웠으면 true (아래 "읽기 한도")
  isBodyTruncated: boolean    // 보여 줄 본문(htmlBody — null 이거나 공백뿐이면 textBody)이 읽기 한도에서 잘렸으면 true
  attachments: MessageAttachment[]
}

interface Attachment { id: string; name: string; type: string; size: number }

interface MessageAttachment extends Attachment {
  isInline: boolean           // 돌려준 htmlBody 안에 그림으로 들어갔다(cid → data:) — 읽기 화면의 첨부 목록에서 뺀다. 전달할 때는 함께 붙인다
}

역할별 한국어 이름: inbox 받은편지함 · drafts 임시보관함 · sent 보낸편지함 · junk 스팸메일함 · trash 휴지통 · archive 보관함.

htmlBody 정화 규칙 (서버 책임): 스크립트·스타일 태그·이벤트 핸들러·폼·iframe·object·embed·svg 제거, 링크는 http · https · mailto 만 남기고 새 창(target="_blank" rel="noopener noreferrer"), 외부(http/https) 이미지는 제거하고 hasBlockedImages = true. 본문 안 인라인 이미지(cid:)는 작은 것만 data: URI 로 바꿔 넣고 나머지는 지운다. 넣은 그림은 attachments 에 isInline: true 로 남는다 — 읽기 화면은 첨부 목록에서 빼고, 전달은 원문 그림을 잃지 않게 함께 붙인다 (인용 본문에서는 그림이 빠지기 때문이다). 넣지 못한 그림(크거나 많거나 읽지 못함)은 isInline: false 로 첨부 목록에 보인다. 클라이언트는 그래도 격리된 iframe 에만 그린다 (스크립트 비허용 sandbox + 내부 CSP — 이중 방어).

hasAttachment 는 엔진 값이 아니라 서버가 첨부 부분의 머리로 정한다 — "본문 그림"이 아닌 첨부가 하나라도 있으면 true. 본문 그림 = 본문에 넣을 수 있는 그림 형식(PNG·JPEG·GIF·WebP) · Content-ID 있음 · Content-Disposition 이 attachment 가 아님(inline 이거나 없음) · 크기 1바이트~300KB. 목록은 본문을 읽지 않으므로 이 판정은 "실제로 본문에 들어갔나"(isInline)와 드물게 다를 수 있다 (본문이 가리키지 않는 그런 그림, 20장·합계 2MB 를 넘는 본문 그림 — 목록은 클립이 없는데 상세의 첨부 목록에는 보인다).

읽기 한도: 상세 조회는 본문 한 부분을 UTF-8 2,000,000바이트까지 읽는다 — 넘는 부분은 잘린 채 오고, 보여 줄 본문이 잘렸으면 isBodyTruncated: true 다. HTML 은 정화하기 전에 길이(HTML 부분이 여럿이면 이어 붙인 것이 2,000,000자 이하)와 파서 비용을 본다 — 약 2만 단을 넘는 중첩이나, 깊게 열린 태그 아래로 짝 없는 닫는 태그를 아주 많이 둔 HTML 은 정화가 서버를 수십 초씩 붙잡기 때문이다. 넘으면 정화하지 않고 htmlBody: null·hasBlockedImages: false·isHtmlBodyOmitted: true 로 내려준다. textBody 는 그대로라 클라이언트는 그것을 보여 주고 답장·전달 인용도 그것으로 만든다 (HTML 만 있는 메일이면 둘 다 null). 수백 단의 인용 스레드·2MB 짜리 큰 표·Outlook 조건부 주석은 한도 안이다. 클라이언트는 두 표시를 읽기 화면에 알리고(서식 없이 표시 · 표시할 수 없음 · 앞부분만 표시), 잘린 본문을 인용할 때는 인용 끝에 생략 표시를 둔다.

엔드포인트

메서드 · 경로	요청	성공	주요 실패
GET /api/mailboxes	—	200 { items: Mailbox[], pageInfo } (hasNext=false)	MAIL_001
POST /api/mailboxes	{ name, parentId? } (아래 "메일함 관리")	201 Mailbox	400 VAL_001, 404 RES_001(없는 parentId), 409 MAIL_009(같은 자리에 같은 이름), 503 MAIL_001
PATCH /api/mailboxes/{id}	{ name }	200 Mailbox	400 VAL_001(기본 메일함), 404 RES_001, 409 MAIL_009, 503 MAIL_001
DELETE /api/mailboxes/{id}	—	200 MailboxDeletion — 안의 메일을 휴지통으로 옮긴 뒤 지운다	400 VAL_001(기본 메일함 · 하위 메일함 있음), 404 RES_001, 429 REQ_001(같은 메일함의 처리가 진행 중), 503 MAIL_001
PATCH /api/mailboxes/{id}/messages	{ isRead: true } — 그 메일함 전체를 읽음으로	200 MailboxBulkResult	400 VAL_001, 404 RES_001, 429 REQ_001(같은 메일함의 처리가 진행 중), 503 MAIL_001
DELETE /api/mailboxes/{id}/messages	— 휴지통 · 스팸메일함 비우기(영구 삭제)	200 MailboxBulkResult	400 VAL_001(휴지통 · 스팸메일함이 아님), 404 RES_001, 429 REQ_001(같은 메일함의 처리가 진행 중), 503 MAIL_001
GET /api/mail-vacation	—	200 MailVacation (아래 "부재중 자동 응답")	503 MAIL_001
PUT /api/mail-vacation	MailVacation (전체 교체)	200 MailVacation(저장한 값)	400 VAL_001 · MAIL_013(필터와 함께 만든 엔진 규칙이 한도를 넘음 — 6단계), 503 MAIL_001
GET /api/mail-filters	—	200 MailFilterSet (아래 "메일 필터", 6단계)	503 MAIL_001
PUT /api/mail-filters	{ rules, version } (전체 교체)	200 MailFilterSet	400 VAL_001 · MAIL_013(만든 규칙이 엔진 한도를 넘음), 409 MAIL_012(그사이 다른 곳에서 필터가 바뀜 — 저장 안 함), 503 MAIL_001
GET /api/mail-quota	—	200 MailQuota	MAIL_001
GET /api/mail-state	—	200 MailState (아래 "새 메일 확인")	503 MAIL_001
GET /api/mail-events	—	text/event-stream (표준 래퍼 없음 — 아래 "실시간 알림", 5단계)	401 AUTH_001, 429 REQ_001(한 직원의 연결 5개 초과), 503 MAIL_001
GET /api/messages	mailboxId · cursor · limit(기본 20, 최대 100) · q — mailboxId 와 q 중 하나는 있어야 한다(q 만 있으면 휴지통·스팸메일함을 뺀 모든 메일함에서 찾는다 — 아래 "검색")	200 { items: MessageSummary[], pageInfo } — 받은 시각 내림차순, total 포함	400 VAL_001, MAIL_001
GET /api/messages/{id}	—	200 MessageDetail — 조회만으로 읽음 처리하지 않는다	404 RES_001
PATCH /api/messages/{id}	{ isRead?, isFlagged?, mailboxId?, isJunk? } (하나 이상 — isJunk 는 4단계 "스팸 · 원문")	200 MessageSummary	404 RES_001, 400 VAL_001
PATCH /api/messages	{ ids, isRead?, isFlagged?, mailboxId?, isJunk? } — 여러 통 (아래 "여러 통 한꺼번에")	200 MessagesPatched	400 VAL_001, 404 RES_001(없는 mailboxId — 아무것도 바꾸지 않음), 503 MAIL_001
DELETE /api/messages/{id}	—	204 — 휴지통이 아니면 휴지통으로 이동, 휴지통에만 있으면 영구 삭제(확인한 상태 그대로일 때만 — 아래). 휴지통과 다른 메일함에 함께 있으면 휴지통에서만 뺀다. 웹 클라이언트는 쓰지 않는다(3단계 — 아래 "여러 통 한꺼번에")	404 RES_001, 503 MAIL_001(확인하는 사이 계속 바뀜 — 지우지 않았다)
POST /api/message-deletions	{ ids } — 휴지통에서 영구 삭제, 여러 통 (아래 "여러 통 한꺼번에")	200 MessageDeletionResult	400 VAL_001, 503 MAIL_001(확인하는 사이 계속 바뀜 · 휴지통 없음 — 지우지 않았다)
POST /api/messages	아래 발송 본문 + Idempotency-Key 헤더	201 SentMessage (보낸편지함의 메일 id + 받지 못한 사람 — 아래 "받는 사람별 결과")	400 MAIL_002·MAIL_003·MAIL_004·MAIL_006·MAIL_007·MAIL_010(받는 사람 모두 거절 — 없는 주소 등)·VAL_001, 403 AUTH_003(보낼 권한 없음), 409 MAIL_005(같은 키·다른 내용), 413 FILE_002(첨부 합계 초과 포함), 429 REQ_001(엔진 발송 한도·같은 키 처리 중·엔진 장애 직후 30초), 503 MAIL_001 · MAIL_011(받는 사람 모두 지금은 받을 수 없음)
POST /api/mail-attachments	multipart file 1개	201 Attachment	400 FILE_001, 413 FILE_002
GET /api/messages/{id}/attachments/{attachmentId}	—	파일 (표준 래퍼 없음, Content-Disposition: attachment)	404 RES_001
GET /api/messages/{id}/source	—	받은 그대로의 메일 message/rfc822 (표준 래퍼 없음, Content-Disposition: attachment; filename="<제목>.eml") — 4단계	404 RES_001, 503 MAIL_001
GET /api/drafts/{id}	—	200 Draft (아래 "임시 저장")	404 RES_001(없음·초안이 아님), 503 MAIL_001
POST /api/drafts	초안 본문	201 DraftSaved	400 VAL_001·MAIL_002·MAIL_003·MAIL_004·MAIL_006·MAIL_007·FILE_001, 413 FILE_002, 503 MAIL_001
PUT /api/drafts/{id}	초안 본문 (전체 교체)	200 DraftSaved — 새 id	위와 같음 + 404 RES_001(초안이 아닌 id — 지우지 않음) + 409 MAIL_008(다른 곳에서 이미 바뀜 — 저장 안 함)
GET /api/mail-signature	—	200 MailSignature (아래 "서명")	—
PUT /api/mail-signature	{ bodyHtml, body, isForNew, isForReply }	200 MailSignature	400 VAL_001
POST /api/mail-signature/images	multipart file 1개	201 SignatureImage	400 FILE_001·VAL_001(올려 둔 그림 10장 초과), 413 FILE_002(300KB 초과)
GET /api/mail-signature/images/{id}	—	그림 파일 (표준 래퍼 없음, 본인 그림만)	404 RES_001
GET /api/recipient-suggestions	q(선택, 1~100자) · limit(기본 20, 최대 100) · cursor	200 { items: RecipientSuggestion[], pageInfo } (아래 "받는 사람 추천")	400 VAL_001, 503 MAIL_001

표에 없는 실패 (구현에서 확정):

상황	응답
없는 mailboxId, 엔진이 해석하지 못하는 mailboxId	404 RES_001
엔진이 해석하지 못하는 id — 여러 통 처리의 ids(PATCH /api/messages · POST /api/message-deletions), 메일함 없이 하는 검색	400 VAL_001 (본문에서 온 값이라서 — 메일함 하나의 목록은 위처럼 404 RES_001)
형식이 틀린 경로 id	404 RES_001
받는 사람 합계 100명 초과 (배열 하나가 100을 넘으면 VAL_001)	400 MAIL_002
엔진에서 찾을 수 없는 첨부 id — 올려 두고 오래 지나 만료된 업로드, 그사이 지워진 원본 메일의 첨부 등	400 MAIL_004 — 클라이언트는 해당 첨부를 실패로 표시한다. 올린 파일은 다시 올리게, 전달하는 원본 첨부는 빼게 한다 (원본은 다시 올릴 수 없다)
첨부 20개 초과	400 MAIL_006 — 클라이언트는 첨부를 추가할 때 미리 막는다
본문이 너무 김 — 텍스트 100,000자·서식 본문 500,000자 초과(JS 문자열 길이, UTF-16 단위), 서식 본문이 정화 전 비용 한도·정화 뒤 2,000,000바이트 초과	400 MAIL_007 — 메일은 나가지 않는다. 클라이언트는 보내기 전에 같은 한도로 막고 본문 아래에 알린다 (아래 "서식 본문"의 한도)
JSON 본문 1MB 초과 (발송 POST /api/messages 와 임시 저장 POST /api/drafts·PUT /api/drafts/{id} 만 4MB — 서식 본문과 긴 인용 때문)	413 FILE_002
JSON 본문의 모양이 한도를 넘음 — 배열 하나 1,000개 · 값(객체 · 배열 · 원시 값) 10,000개 · 깊이 32단	400 VAL_001
JSON 본문이 UTF-8 이 아님 — charset 이 utf-16 · utf-32 · utf-7 등 (charset 을 붙이지 않거나 utf-8 이면 된다)	400 VAL_001

JSON 본문 모양 한도 (2026-10-28 — 6단계 리뷰에서, 전부터 있던 경로도 같은 원인): 본문 크기 한도 안에서도 작은 객체 수만~수십만 개면 DTO 변환 · 검사가 몇 초씩 서버를 멈추고 수백 MB 를 썼다 (리뷰 측정 — 1MB 에 필터 규칙 8만 개 7.8초, 조건 15만 개는 500). 그래서 모든 JSON 본문을 DTO 에 닿기 전에 본다 — 읽기 전에 글자를 한 번 훑고, 읽은 뒤 한 번 더. 한도는 지금 계약의 어떤 본문보다 넉넉하다(가장 긴 배열 100 · 가장 깊은 본문 5단 · 값이 가장 많은 필터 50개 저장이 약 1,600개). 이 검사와 UTF-8 검사는 본문 크기 한도처럼 인증보다 앞이라, 로그인하지 않은 요청도 401 이 아니라 400 이다. JSON 은 UTF-8 만 받는다(RFC 8259 8.1 — 웹 · 앱 모두 UTF-8 로 보낸다).

메일함 정렬(확정 디자인 기준): 받은편지함 → 보낸편지함 → 임시보관함 → 스팸메일함 → 휴지통 → 보관함 → 그 외(sortOrder, 이름 순).

// GET /api/mail-quota — 메일함 패널 하단 사용량 표시와 첨부 사전 검사에 쓴다
interface MailQuota {
  usedBytes: number
  limitBytes: number | null    // 한도가 없으면 null → "사용량 0.9GB" 처럼 사용량만 표시
  attachmentMaxBytes: number   // 서버의 MAIL_ATTACHMENT_MAX_SIZE_MB — 클라이언트는 상수 대신 이 값으로 사전 검사·안내한다
  attachmentTotalMaxBytes: number // 메일 한 통의 첨부 합계 한도 — MAIL_ATTACHMENT_TOTAL_MAX_SIZE_MB 와 엔진 한도 중 작은 값 (발송 때 검사하는 값과 같다)
}

cursor 는 불투명 문자열이다. 클라이언트는 해석하지 말고 pageInfo.nextCursor 를 그대로 다시 보낸다.

발송 본문 (POST /api/messages)

중복 발송 방지 — Idempotency-Key 요청 헤더: 클라이언트는 쓰기 화면마다 무작위 키(UUID) 하나를 만들어 보내고, 같은 메일을 다시 보낼 때(타임아웃 뒤 재시도 등)에도 같은 키를 보낸다. 서버는 같은 사용자·같은 키로 이미 발송된 메일이 있으면 다시 보내지 않고 그 결과(201 SentMessage — 아래 "받는 사람별 결과")를 돌려준다. 응답이 늦어 MAIL_001 을 받았어도 실제로는 나갔을 수 있으므로, 재시도는 반드시 같은 키로 한다. (키 형식이 틀리면 400 VAL_001. 키가 없으면 중복 방지 없이 보낸다.) 서버는 발송 요청에 55초 안에 답한다 — 앞 단계(첨부 확인 · 서명 그림 올리기)가 늦어 보낼 시간이 10초도 남지 않으면 메일을 만들지 않고 503 MAIL_001 (아무것도 나가지 않았으니 같은 키로 다시 보내면 된다). 보낸 뒤 이어 쓴 저장본 지우기는 5초까지만 기다리고, 넘으면 먼저 답한 뒤 마저 지운다.

• 같은 키의 요청이 아직 처리 중이면 기다리지 않고 429 REQ_001 — 같은 메일이 동시에 두 번 나가지 않게 한다. 엔진 장애(MAIL_001)로 끝난 키도 30초 동안은 처리 중으로 본다 (시간 초과라면 엔진이 아직 보내는 중일 수 있다). 클라이언트는 이 429 에 같은 키로 즉시 자동 재시도하지 않고, 잠시 뒤 사용자가 다시 보내게 한다(키는 그대로).
• 같은 키인데 내용이 다르면(실패 뒤 받는 사람·제목·본문·첨부를 고친 경우) 보내지 않고 409 MAIL_005. 첫 메일이 실제로 나갔을 수 있으므로, 클라이언트는 사용자에게 보낸편지함을 확인하게 하고 새 키로 다시 보낼 수 있게 한다. 서버는 첫 발송 때 내용 지문(Idempotency-Key 를 키로 한 HMAC — 받는 사람은 키를 모른다)을 함께 남겨 비교한다.
  • 지문에 들어가는 것: 받는 사람·참조·숨은참조의 주소(대소문자·순서 무시), 제목, 본문(줄바꿈 정규화), 서식 본문(서버가 정화한 HTML), 첨부 id(순서 무시), inReplyTo.
  • 들어가지 않는 것: 표시 이름, 첨부 이름 — 이것만 바꾼 재시도는 "같은 내용"으로 보고 처음 결과를 돌려준다.
• 알려진 한계 (1단계는 발송 기록을 따로 저장하지 않고 보낸편지함에서 찾는다):
  • 첫 발송 뒤 보낸 사본을 다른 메일함으로 옮기거나 지웠으면, 또는 그사이 보낸편지함·임시보관함에 200통 넘게 쌓였으면 같은 키의 재시도가 다시 나갈 수 있다.
  • "처리 중" 표시는 서버 메모리에 있어 서버가 재시작되면 사라진다. 엔진 장애 직후의 드문 경합에서도 두 번 나갈 수 있다.
  • 서식 본문의 지문은 정화한 결과로 만든다 — 첫 발송과 재시도 사이에 서버의 정화 규칙이 바뀌면(배포) 같은 키의 재시도가 MAIL_005 로 막힐 수 있다. 그때도 위 409 처리(보낸편지함 확인 → 새 키)를 따른다.
  • 이 한계를 없애려면 (사용자, 키) → (지문, 메일 id) 를 서버 DB 에 저장한다 — 서버를 여러 대로 늘릴 때 함께 검토한다.

{
  "to":  [{ "name": "이도윤", "email": "doyun.lee@arasystem.it.kr" }],  // 1개 이상
  "cc":  [],                                                              // 선택
  "bcc": [],                                                              // 선택 (받는 사람 합계 100 이하)
  "subject": "Re: 메일 서버 이전 일정 공유",                               // 255자 이하
  "body": "도윤님, 확인했습니다.\n…",                                       // 일반 텍스트(서식 본문의 대체 본문), 100,000자 이하
  "bodyHtml": "<div style=\"font-family:…\"><p>도윤님, 확인했습니다.</p>…</div>", // 선택 — 서식 편집기 본문, 500,000자 이하 (아래 "서식 본문")
  "attachments": [{ "id": "<업로드 응답 id>", "name": "체크리스트.xlsx" }], // 선택, 20개 이하 (넘으면 MAIL_006)
  "inReplyTo": "<답장할 메일의 id>",                                       // 선택 — 스레드 헤더를 서버가 채운다
  "draftId": "<이어 쓴 임시 저장본 id>"                                      // 선택 — 보낸 뒤 서버가 그 초안을 지운다 (아래 "임시 저장")
}

받는 사람별 결과 (발송 응답) — 6단계 앞 수정

interface SentMessage {
  id: string                                  // 보낸편지함의 메일 id
  rejectedRecipients: RejectedRecipient[]     // 엔진이 받지 않은 사람 — 없으면 빈 배열
}
interface RejectedRecipient {
  email: string                               // 요청에 쓴 주소 그대로 (받는 사람 · 참조 · 숨은참조 모두 — 같은 주소는 한 번)
  reason: 'not-found' | 'refused' | 'temporary'  // 없는 주소 · 받는 쪽이 거절 · 지금은 받을 수 없음(한도 등)
}

• 엔진은 제출(EmailSubmission/set)을 만들면서 받는 사람마다 그 자리에서 SMTP 로 묻는다. 거절된 사람은 제출 기록의 deliveryStatus 에 delivered: "no" 와 SMTP 응답(550 5.1.2 Mailbox does not exist · 452 4.4.5 Rate limit exceeded 등)으로만 남고 다시 보내지도 반송하지도 않는다 (Stalwart 0.16.27 — 2026-10-28 확인. 전에는 서버가 이것을 보지 않아, 없는 사내 주소로 보낸 메일도 "보냈습니다"로 끝났다). 그래서 서버가 제출한 뒤 결과를 읽어 알린다.
  • 결과는 제출 다음 따로 읽는다(EmailSubmission/get) — 제출 응답(created)에는 없고, 같은 요청 안의 참조(#ids)는 onSuccessUpdateEmail 이 덧붙이는 응답 때문에 엔진이 풀지 못한다(같은 날 확인).
  • 분류 — SMTP 응답 맨 앞의 기본 코드(550)와 확장 상태(5.1.2)만 읽는다(응답 글 안의 숫자는 보지 않는다). 4xx 면 temporary, 5xx 이고 확장 상태가 5.1.x(받는 사람 주소 문제)면 not-found, 그 밖의 5xx 와 읽을 수 없는 응답은 refused — 두 값이 어긋나면 기본 코드를 따른다(450 5.1.1 은 temporary). 5.1.7 · 5.1.8(보낸 사람 주소 문제)도 not-found 로 보이는데, 엔진의 제출 때 거절에는 나오지 않고 같은 키 재시도가 바깥 반송까지 읽을 때만 생길 수 있다. delivered 가 "no" 가 아니거나 결과가 없는 사람은 받은 것으로 본다 — 바깥 주소는 대기열에 들어가 250 Queued 이고, 나중에 실패하면 지금처럼 반송 메일이 온다.
  • 결과를 읽지 못하면(엔진 오류 · 시간) 보낸 것으로 보고 rejectedRecipients: [] 로 답한다(warn 로그) — 제출은 이미 되었다. 결과 읽기는 발송 전체 55초 안에서 최대 5초(모두 거절일 때 사본을 지울 3초를 남긴다), 쓸 시간이 1초도 안 남으면 묻지 않는다.
  • 같은 주소(대소문자 무시)는 한 번만 싣는다 — 받는 사람 → 참조 → 숨은참조 순서이고 처음 쓴 모양 그대로.
• 모두 거절(받은 사람이 아무도 없음) — 보내지 않은 것으로 다룬다. 이 요청이 만든 보낸 사본은 지우고(아무에게도 가지 않았다 — 그 요청이 방금 만든 메일이라 조건 없이 지운다), 이어 쓴 저장본(draftId)은 지우지 않는다. 거절 가운데 5xx 가 하나라도 있으면 400 MAIL_010, 모두 4xx 면 503 MAIL_011. 같은 키로 다시 보내면 새로 보낸다(지운 사본은 중복 방지에 걸리지 않는다). 사본을 지우지 못해도(엔진 오류 — warn) 코드는 그대로다. 알려진 한계: 그때 보낸편지함에 사본 한 통이 남고, 같은 키 · 같은 내용의 재시도는 그 사본을 찾아 201 + 받는 사람 전원의 rejectedRecipients 로 답한다(이어 쓴 저장본도 지운다), 내용을 고친 재시도는 409 MAIL_005 다 — 지금 남은 결과만으로는 "제출 때 거절"과 "보낸 뒤 바깥에서 반송"을 가를 수 없어 다시 보내지 않는다. 제출 응답을 받지 못해 503 MAIL_001 로 끝났는데 엔진에서는 제출되어 모두 거절된 경우도 같다(사본을 지우는 데까지 가지 못했다) — 30초 잠금이 풀린 뒤 같은 키의 재시도가 그 사본을 찾는다.
• 일부 거절 — 보낸 것이다. 201 에 rejectedRecipients 를 싣고, 보낸 사본은 보낸편지함에 남고, draftId 는 지운다.
• 같은 키의 재시도가 처음 메일을 찾아 그대로 돌려줄 때도 그 메일의 제출 기록으로 rejectedRecipients 를 다시 만든다(찾지 못하면 빈 배열).
• 로그 — 모두 거절은 warn([MAIL_010] · [MAIL_011]), 일부 거절은 log. 주소는 가리고(maskEmail) SMTP 상태 코드(550 5.1.2 등)만 남긴다. MAIL_011 은 503 이라 전역 예외 필터가 5xx 규칙대로 error(스택 포함)로 한 줄 더 남긴다(MAIL_001 과 같다) — 웹메일 발송은 엔진 한도에 걸리지 않게 했으므로 드물다.
• 엔진 기본 한도 중 받는 사람 단위의 것("보낸 도메인 → 한 받는 사람" 시간당 25통)은 로그인한 직원의 발송에는 걸지 않는다 — 사내 메일은 보낸 도메인이 모두 같아, 동료 모두 합쳐 한 사람에게 시간당 25통을 넘으면 그 뒤가 거절되던 문제(같은 날 확인). mail setup 이 맞춘다(mail/README.md "엔진 한도"). 바깥에서 들어오는 메일(인증 없는 SMTP)에는 그대로 건다. 다른 기본 한도 "보낸 IP 마다 초당 연결 5개"는 연결할 때 세는 것이라 웹메일 발송에는 원래 걸리지 않고, 그대로 둔다 (조건을 붙이면 엔진이 그 한도를 연결이 아닌 MAIL FROM 단계로 옮겨 바깥 접속을 더는 세지 않는다 — Stalwart 0.16.27 소스로 확인).
• 클라이언트
  • 일부 거절 — 보낸 것으로 처리한다(쓰기 화면을 닫고 떠난다). 보냈다는 알림 대신 실패 알림(「보낸편지함 보기」 링크 — 보냈다는 알림과 같은 글, 단추 있는 알림과 같은 10초)으로 "보냈지만 N명은 받지 못했습니다 — nobody@arasystem.it.kr (없는 주소)" — 두 명까지 주소와 까닭을 적고 더 있으면 " 외 N명". 까닭 문구는 not-found "없는 주소" · refused "받는 쪽이 거절" · temporary "지금은 받을 수 없음".
  • MAIL_010 — 받는 사람 칸의 안내 띠(MAIL_002 와 같은 자리 · 같은 초점)로만 알린다(토스트 없음). 쓰던 메일 · 키는 그대로.
  • MAIL_011 — 인터셉터 알림(사전 문구). 쓰던 메일 · 키는 그대로 — 잠시 뒤 다시 누르면 같은 키로 간다.

전달: 원본 메일 attachments[].id 를 발송 본문의 attachments 에 그대로 넣으면 원본 첨부가 다시 붙는다 (같은 계정 안의 파일이라 다시 올릴 필요가 없다). 제목 Fwd: 와 인용 본문은 클라이언트가 만들고, inReplyTo 는 보내지 않는다. 발송 본문의 첨부 이름(attachments[].name)은 업로드한 파일과 같은 규칙으로 확장자를 허용 목록에서 검사한다(밖이면 400 FILE_001) — 원본 첨부를 그대로 전달할 때도 같다.

답장·전달 초안의 길이: 클라이언트가 초안을 만들 때 한도에 맞춘다 — 제목은 255자, 본문은 텍스트 100,000자·서식 본문 500,000자. 넘으면 인용을 줄이고 끝에 생략 표시를 둔다 (본문을 넘긴 채 보내면 400 MAIL_007, 제목은 VAL_001). 처음 맞출 때는 쓸 글 몫으로 한도의 5%를 남기고(텍스트 95,000자·서식 475,000자), 보내기 직전에 실제로 보낼 본문을 다시 재서 넘으면 인용을 더 줄인다. 인용 없이 쓴 글만으로 넘으면 보내지 않고 쓰기 화면의 본문 아래에 MAIL_007 문구로 알린다 (서버가 MAIL_007 을 돌려줘도 같다).

서식 본문 (bodyHtml): 쓰기 화면의 서식 편집기가 만든 HTML 이다.

• 클라이언트는 같은 내용의 일반 텍스트를 body 로 함께 보낸다 (받는 쪽 프로그램이 텍스트만 볼 때 쓰는 대체 본문 — 목록은 - /1. , 인용은 > 를 붙인다). 서버는 둘을 multipart/alternative 로 보낸다. bodyHtml 이 없으면 텍스트 메일이다.
• 서버는 보내기 전에 허용 목록으로 정화한다 — 편집기가 만드는 것만 남긴다: 문단·줄바꿈, 굵게·기울임·밑줄·취소선, 글자 색·배경 색·글꼴·글자 크기(span 의 style), 정렬·들여쓰기·줄 간격, 목록, 인용, 가로줄, 표(칸 폭을 적는 colgroup·col 포함), 링크(http·https·mailto). 그 밖의 태그·속성·스타일·스크립트는 지운다. 지문에는 정화한 결과가 들어간다.
  • 남는 속성: style(a 를 뺀 모든 태그), a 의 href(링크에는 이것만 남는다 — 링크 글자 색은 안쪽 span 의 style 로), ol 의 start, td·th 의 colspan·rowspan(숫자만).
  • 남는 style: color·background-color·font-family·font-size·font-weight·line-height·text-align·margin·padding(각 변 포함)· border(각 변·border-color·border-style·border-width·border-collapse)·width·min-width·vertical-align·white-space.
  • style 은 값의 형식까지 맞아야 남는다 — 형식이 틀린 선언은 그 선언만 지운다: 글자 크기는 px 만 899.99px, 색은 #rgb·#rrggbb·rgb()·rgba()(색 이름·hsl() 은 지운다) — 글자 색(color)의 투명도(알파)는 0.3 이상, 여백은 0 또는 px(음수 없음), 줄 간격은 단위 없는 숫자 13(소수 둘째 자리까지), 글꼴은 쓰기 화면의 글꼴 목록과 흔한 대체 이름(Helvetica·Times·Courier· AppleGothic·AppleMyungjo)·일반 이름(sans-serif·serif·monospace)으로만 이뤄진 목록.
  • 형광 표시는 mark 가 아니라 span 의 background-color 로 보낸다 (mark·h1 같은 모르는 태그는 태그만 지우고 글자는 남긴다).
  • 정화하고 남는 것이 없으면 body 만으로 텍스트 메일을 보낸다.
  • 그림은 보내는 사람 자신의 서명 그림만 남는다 — <img src="/api/mail-signature/images/{id}"> 이고 그 id 가 보내는 사람의 그림일 때. 속성은 src·width(1~600, 숫자만)·alt(200자 이하)만 남는다. 서버가 그 그림을 메일 안에 함께 실어(multipart/related, cid:) 보내므로 받는 쪽에서 외부 이미지처럼 막히지 않는다. 그 밖의 img·찾지 못한 서명 그림(지운 그림)은 태그째 지운다. 클라이언트 편집기도 이 그림만 받는다.
  • 보이지 않을 만큼 작은 글자(8px 미만)·거의 투명한 글자 색(알파 0.3 미만)은 그 선언을 지운다 — 붙여 넣거나 인용한 글에 그렇게 숨긴 글이 그대로 실려 나가지 않게. 바탕과 같은 색(흰 바탕 위 흰 글자 등)은 바탕을 알 수 없어 막지 않는다 (받은 메일을 읽을 때의 정화는 이 제한을 두지 않는다).
  • 한도 — 넘으면 400 MAIL_007. 엔진·첨부 조회 전이라 메일은 나가지 않으므로, 고친 뒤 같은 키로 다시 보내면 된다. 정화 전에는 받은 메일과 같은 파서 비용 한도(위 "읽기 한도")를, 정화 뒤에는 결과가 UTF-8 2,000,000바이트 이하인지 본다 (우리 웹메일이 다시 읽을 때 잘리지 않게). 500,000자 안이어도 넘을 수 있다 — 정화가 & 를 &(5바이트)로 바꾸고, 한글은 글자당 3바이트·이모지는 4바이트다.
• 기본 글꼴은 맑은 고딕 이다 — 클라이언트가 본문 전체를 font-family·font-size:14px·line-height:1.75 를 가진 div 하나로 감싸 보낸다. 편집기 화면의 CSS 는 메일에 따라가지 않으므로 문단 여백(0)·인용 막대·표 테두리도 각 요소의 인라인 style 로 보낸다.
• 클라이언트도 같은 값 형식만 읽는다 — 붙여 넣은 글과 원문 인용을 편집기로 옮길 때 위 형식 밖의 서식(색 이름·font-size:0·목록에 없는 글꼴 등)은 버린다 (글자 크기의 pt 는 px 로 바꾼다). 서버만 지우면 편집기에서 숨은 글이 받는 사람에게 보이는 식으로 화면과 보낸 메일이 달라진다.
• 여러 칸 띄어쓰기와 줄 앞 공백은 받는 쪽이 합치거나 지우므로 nbsp 로 바꿔 보낸다 (보통 공백과 번갈아 — 긴 공백에서도 줄은 바뀐다). 탭은 다음 8칸 자리까지의 공백으로 바꾼다. 텍스트 대체 본문(body)은 그대로 둔다.
• 우리 웹메일이 다시 읽을 때(보낸편지함·받은 사람)도 이 서식이 남아야 한다 — 받은 메일 정화(htmlBody)의 허용 목록이 위 서식을 포함한다.
• 답장·전달의 원문 인용은 두 경우 모두 "원본 메일" 머리(보낸 사람·날짜·제목, 전달은 받는 사람·참조도)와 회색 인용 막대로 만든다. 원문은 htmlBody(없으면 textBody)를 편집기로 옮기며, 편집기가 모르는 요소(이미지 등)는 빠진다.
• 본문 안 이미지는 이번 단계에서 넣지 않는다 — 붙여 넣거나 끌어다 놓은 이미지는 첨부 파일로 올린다 (첨부 한도 규칙 그대로). 서명 그림만 예외다 (아래 "서명").

첨부 업로드 한도

• 파일당 MAIL_ATTACHMENT_MAX_SIZE_MB (기본 20MB) — 넘으면 413 FILE_002
• 메일 한 통의 첨부 합계(전달하는 원본 첨부 포함, 같은 첨부를 두 번 붙이면 두 번 센다) attachmentTotalMaxBytes (MAIL_ATTACHMENT_TOTAL_MAX_SIZE_MB, 기본 25MB) — 넘으면 발송이 413 FILE_002. 클라이언트는 첨부를 추가할 때 이 값으로 미리 막고 안내한다 (다 쓰고 보낼 때 알게 하지 않는다).
• 허용 형식(확장자 + MIME 둘 다 검사): pdf · doc/docx · xls/xlsx · ppt/pptx · hwp/hwpx · txt · csv · png · jpg/jpeg · gif · webp · zip
• 다운로드는 <a href> 이동으로 받는다 — 같은 출처라 쿠키가 함께 간다. 이동은 axios 를 거치지 않아 401 재시도 규칙이 적용되지 않으므로, 이동하기 전에 세션을 확인한다 (/auth/me 가 AUTH_001 이면 /auth/refresh 한 번 → 실패하면 세션 만료 처리).

임시 저장 (/api/drafts)

interface Draft {
  id: string                 // 저장할 때마다 바뀐다 — 응답의 id 로 바꿔 쓴다
  to: Address[]
  cc: Address[]
  bcc: Address[]
  subject: string
  body: string               // 텍스트 대체 본문
  bodyHtml: string | null    // 서식 본문 — 보내는 정화를 거친 값 (없거나 비면 null). 다른 메일 프로그램이 만든 초안도 같은 정화를 거친다
  attachments: Attachment[]  // 이 판의 첨부 — id 가 저장할 때마다 바뀐다
  inReplyTo: string | null   // 답장할 메일 id (없거나 원 메일이 사라졌으면 null)
  updatedAt: string          // 마지막으로 저장한 시각 (ISO 8601 UTC)
}

interface DraftSaved { id: string; attachments: Attachment[]; updatedAt: string }

• 초안 본문은 발송 본문과 같은 필드·한도다(본문 길이 MAIL_007, 첨부 20개 MAIL_006, 첨부 합계 FILE_002, JSON 본문 4MB …). 다만 받는 사람은 0명이어도 되고 (합계 100명 이하), draftId 는 없다.
• 저장: 처음은 POST, 그다음은 PUT /api/drafts/{직전 id}. 메일은 고칠 수 없어 서버가 새 초안을 만들고, 다시 읽어 확인한 뒤 옛것을 지운다 — 클라이언트는 응답의 id·attachments 로 바꿔 쓴다. 서버는 초안에 발송 중복 방지용 Message-ID·지문 헤더를 넣지 않는다. 만들기와 지우기를 한 요청에 넣지 않는다 — 엔진은 같은 요청에서 만들기가 실패해도 지우기를 그대로 해서, 저장에 실패한 순간 저장본이 사라진다.
  • "임시보관함의 초안" = 임시보관함에만 있고 $draft 이며 보내기 중에 생긴 내부 초안이 아닌 메일. PUT 의 id 가 그렇지 않으면(휴지통·보낸 메일 등) 아무것도 만들거나 지우지 않고 404 RES_001.
  • 옛 초안이 이미 없으면(다른 창·기기에서 먼저 고쳤거나 지웠음) 409 MAIL_008 — 처음 확인에서 없으면 아무것도 만들지 않고, 만든 뒤 지우는 사이에 없어졌으면 방금 만든 것을 지운다.
  • 클라이언트는 MAIL_008 과 PUT 의 404 RES_001(다른 창에서 휴지통으로 옮긴 경우 등)을 모두 막지 않고, 지금 내용을 POST 로 새로 남긴다.
  • 옛것은 확인한 뒤로 메일함이 바뀌지 않았을 때만 지운다(JMAP ifInState, 엇갈리면 다시 확인 — 모두 세 번까지). 지우기는 되돌릴 수 없어서다. 그사이 다른 곳에서 옮겼으면 지우지 않고, 계속 엇갈리면 옛것이 한 통 더 남는다 (저장은 성공).
• 목록·버리기·되돌리기는 기존 API 다 — 목록 GET /api/messages?mailboxId=<임시보관함>(보내기 중에 생긴 내부 초안은 나오지 않는다), 버리기는 휴지통으로 옮기기 PATCH /api/messages/{id} { mailboxId: <휴지통> }(웹은 DELETE 를 쓰지 않는다 — 이미 휴지통인 메일은 DELETE 가 영구 삭제한다), 되돌리기 PATCH /api/messages/{id} { mailboxId: <임시보관함> }.
• 보내기: 이어 쓴 초안은 발송 본문에 draftId 를 넣어 보낸다. 서버는 지금의 발송 경로(정화·지문·중복 방지 그대로)로 보내고, 성공한 뒤 (같은 키 재시도로 처음 결과를 돌려줄 때 포함) 그 초안을 지운다 — 초안 자체를 그대로 제출하지 않는다. 지우기는 위 저장과 같은 조건(임시보관함의 초안 · 확인한 뒤 바뀌지 않음)일 때만 하고, 못 지우면 로그만 남긴다(발송은 성공). draftId 는 지문에 넣지 않는다.
• 클라이언트 저장 주기: 바꾼 내용이 있을 때 입력이 3초 멈추면 · 쉬지 않고 쓰는 중에도 30초마다 · 10초에 한 번까지 · 화면을 떠날 때, 한 번에 하나씩. 찾지 못한 첨부(MAIL_004)가 남은 동안과 본문이 한도를 넘는 동안은 저장하지 않는다 (첨부가 빠진 판으로 저장본을 덮지 않게). 다른 메일 프로그램이 만든 저장본에 실을 수 없는 첨부(허용 목록 밖 · 개수 · 합계 초과)가 있으면 첫 저장은 PUT 이 아니라 POST 다 — 원본을 지우지 않는다. 보내기 전에는 진행 중인 저장을 기다린다 (그래야 draftId 가 최신이다).
• 알려진 한계:
  • 저장할 때마다 첨부 내용이 새 초안으로 복사돼 큰 첨부가 있으면 저장이 무겁다. 메일함 용량이 거의 차면 교체하는 순간 두 판이 함께 있어 MAIL_003 이 날 수 있다.
  • 답장 대상은 초안의 사용자 머리 X-Ara-Reply-To-Id(메일 id)에 둔다. 우리 서버는 보낼 때 새 메일을 만들어 이 머리가 나가지 않지만, 다른 메일 프로그램이 그 초안을 그대로 보내면 함께 나갈 수 있다.
  • 보내기에서 제출은 됐지만 보낸편지함으로 옮기지 못한 메일은 임시보관함에 보이지 않는 채로 남는다 (같은 키의 재시도는 그 메일을 찾는다).
  • 저장 응답을 받지 못하면(시간 초과 등) 서버는 이미 새 저장본을 만들었을 수 있다 — 다음 PUT 은 MAIL_008 이 되어 클라이언트가 새로 남기므로 임시보관함에 한 통이 더 남을 수 있다 (잃는 내용은 없다).

서명 (/api/mail-signature)

interface MailSignature {
  bodyHtml: string | null    // 서명 서식 — 서식 본문 규칙 + 서명 그림. 정화 뒤 10,000자 이하
  body: string | null        // 텍스트 서명 (텍스트 대체 본문에 넣는다) — 2,000자 이하
  isForNew: boolean          // 새 메일에 넣는다 (기본 true)
  isForReply: boolean        // 답장·전달에 넣는다 — 인용 위 (기본 true)
  images: SignatureImage[]   // 서명이 쓰는 그림
  updatedAt: string | null   // 저장한 적 없으면 null
}

interface SignatureImage {
  id: string
  type: 'image/png' | 'image/jpeg' | 'image/gif'
  size: number               // 바이트
  width: number              // 원본 픽셀
  height: number
}

• 사용자마다 하나다. 저장한 적 없으면 기본값(bodyHtml: null·body: null·둘 다 true·images: [])을 돌려준다. 서버 DB 에 둔다(메일 엔진에 두지 않는다).
• PUT 의 한도 — 넘으면 400 VAL_001: 텍스트 서명 2,000자, 서식 서명은 정화 전에 서식 본문과 같은 한도(500,000자·파서 비용)와 정화 뒤 10,000자, 서명 그림 3장(서로 다른 그림 기준).
• 서명 그림: POST /api/mail-signature/images (multipart file) — PNG·JPEG·GIF 만(확장자·MIME·파일 앞부분 모두 검사, WebP·SVG 는 받지 않는다), 한 장 300KB 이하(넘으면 413 FILE_002 — 받은 메일의 본문 그림 한도와 같아서, 보낸 메일을 우리 웹메일로 다시 읽어도 그림이 보인다), 가로·세로 각각 4096px 이하(넘으면 400 FILE_001 — 작은 파일 안의 아주 큰 그림이 받는 쪽을 무겁게 하지 않게). 서명에는 3장까지 넣는다(편집기가 먼저 막는다). 발송 본문·임시 저장본도 서로 다른 서명 그림 3장까지다(넘으면 400 VAL_001). 올려 두기만 한 그림을 포함해 한 사람 10장까지 둘 수 있다(넘으면 올리기가 400 VAL_001). 서명 HTML 은 그림을 <img src="/api/mail-signature/images/{id}" width="144" alt=""> 로 가리킨다(width 1~600 — 작게 96 · 보통 144 · 원본은 원래 폭, 600 이하).
• GET /api/mail-signature/images/{id} 는 그 사람의 그림만 내준다(남의 것은 404 RES_001) — 편집기·미리 보기용이고, 받는 사람은 이 주소를 쓰지 않는다. 저장할 때 확인한 형식 그대로, Content-Disposition: inline · X-Content-Type-Options: nosniff · Cache-Control: private, max-age=86400 (그림 id 의 내용은 바뀌지 않는다 — 새로 올리면 새 id).
• PUT 은 서명 HTML 이 더는 가리키지 않는 그림을 지운다 — 다만 한 번도 저장하지 않은 그림 가운데 10분 안에 올린 것은 남긴다 (그림을 넣자마자 저장하면 올리기와 저장이 엇갈릴 수 있다). 올리고 저장하지 않은 그림은 하루 뒤 지운다.
• 보낼 때: 쓰기 화면이 서명을 본문에 보통 글로 넣어 둔 그대로 보낸다 — 서명 그림은 위 "서식 본문"의 그림 예외로 메일 안에 함께 실린다 (multipart/related 의 그림 부분 — Content-Disposition: inline, Content-ID: <sig-{그림 id}@{보내는 사람 도메인}>, 이름 signature-1.png …, 첨부가 있으면 그 묶음을 multipart/mixed 안에 둔다). 우리 웹메일에서는 위 hasAttachment·isInline 규칙으로 첨부로 보이지 않는다. 텍스트 대체 본문에는 그림이 없다. 임시 저장본도 같은 그림 주소를 쓴다.
• 알려진 한계: 서명 그림을 지운 뒤 그 그림을 쓴 임시 저장본을 보내면 그 그림은 빠진다. 답장·전달로 인용한 원문 속 그림(남의 서명 로고 포함)은 인용에서 빠진다.

받는 사람 추천 (/api/recipient-suggestions)

interface RecipientSuggestion {
  name: string | null
  email: string
  source: 'directory' | 'recent'   // directory = 사내(웹메일에 로그인한 적 있는 직원), recent = 최근 주고받은 주소
}

• q 가 있으면 이름·주소에 그 글자가 든 것만 준다(대소문자 무시). 응답은 커서 페이지네이션 규칙 그대로({ items, pageInfo }) — 커서는 받은 그 q 로만 쓴다(다른 q 와 함께 보내면 400 VAL_001).
• 순서: 사내 → 최근 주고받은 주소, 각 묶음 안에서는 주고받은 횟수와 최근성으로. 두 쪽에 다 있는 주소는 사내로 한 번만 나온다.
• 최근 주고받은 주소는 그 사람의 보낸편지함 최근 500통(받는 사람·참조·숨은참조)과 받은편지함 최근 500통(보낸 사람)에서 모은다 — 다른 직원의 메일함은 읽지 않는다. 나·메일 엔진 관리자·게이트웨이·막은 계정·noreply 류는 뺀다.
• 사내 목록은 로그인에 성공한 직원(주소·이름)을 서버가 기록해 만든다 — 메일 엔진의 계정 목록 권한은 쓰지 않는다(일부러 막아 두었다). 한 번도 로그인하지 않은 직원은 그 사람과 메일을 주고받기 전까지 나오지 않는다. 최근 90일 안에 로그인한 직원만 사내로 추천한다 (퇴사자가 계속 맨 앞에 나와 반송되지 않게 — 웹메일 세션은 최대 30일이라 쓰는 사람은 그 안에 다시 로그인한다).
• 알려진 한계: 최근 주고받은 주소의 이름은 받은 메일의 보낸 사람 표시 이름에서 온다 — 바깥 사람이 동료 이름을 표시 이름으로 쓰면 그 이름으로 추천된다. 추천 줄은 늘 주소를 함께 보이고, 사내와 최근 묶음을 나눠 보인다.
• 응답은 Cache-Control: private, no-store. 서버는 사용자마다 10분 캐시하고(서버 메모리, 최대 500명), 그 사람이 메일을 보내면 다시 모은다. 같은 사람의 동시 요청은 한 번만 모은다. 로그에는 개수만 남긴다.
• 클라이언트: 쓰기 화면을 열 때 q 없이 limit=100 으로 한 번 받아 두고 치는 대로 거른다(초성 포함). 맞는 것이 모자랄 때만 q 로 다시 묻는다(250ms 기다린 뒤).

새 메일 확인 (/api/mail-state) — 3단계

// GET /api/mail-state — 새 메일 · 다른 창(메일 프로그램)의 변화를 알아채는 데 쓴다
interface MailState {
  state: string   // 불투명 — 메일함이나 메일이 하나라도 바뀌면 달라진다. 해석하지 말고 지난 값과 같은지만 본다
}

• 서버는 엔진의 메일함 · 메일 상태 문자열을 이어 붙여 돌려준다 (JMAP Mailbox/get · Email/get 에 ids: [] — 메일을 읽지 않는 가벼운 조회). 새 메일이 오거나 다른 창 · 메일 프로그램이 읽음 · 이동 · 삭제를 하면 값이 바뀐다 (2026-10-27 개발 엔진에서 확인). 응답은 Cache-Control: private, no-store.
• 클라이언트: 로그인한 동안, 화면이 보이는 동안(visibilityState === 'visible')만 60초마다 묻는다. 탭이 다시 보이면 마지막으로 물은 지 10초가 지났을 때 바로 한 번. 한 번에 하나씩.
  • 처음 받은 값은 기준으로만 쓴다. 값이 바뀌면 메일함 개수 · 사용량을 다시 받고, 보이는 메일함 목록을 지금까지 불러온 만큼(최대 100통) 다시 받아 맞춘다 — 고른 메일 · 열린 메일 · 스크롤 위치는 그대로. 100통보다 많이 불러왔으면 첫 100통만 맞추고 그 뒤는 둔다. 검색 결과는 다시 찾지 않는다(보던 결과가 저절로 바뀌지 않게).
  • 이 탭이 바꾼 것(읽음 · 이동 등)도 값을 바꾸므로 다음 확인에서 한 번 더 받게 된다 — 해롭지 않다.
  • 실패(MAIL_001 · 네트워크)는 알리지 않고(silent) 다음 주기에 다시 묻는다. 401 은 지금의 세션 흐름(갱신 1회 → 만료 대화상자)을 그대로 탄다.
  • 받은편지함에 안 읽은 메일이 있으면 탭 제목 앞에 (N) 을 붙인다 (디자인 README "3단계").
• 요청 수 한도(THROTTLE_LIMIT, 기본 1분 100회)는 경로마다 · IP 마다 센다 — 사무실 전체가 한 IP 로 나가면 보이는 탭이 100개를 넘을 때 1분 확인이 429 REQ_001 로 조용히 실패한다(다음 주기에 다시). 값이 바뀌었을 때의 맞추기(GET /api/messages · /api/mailboxes · /api/mail-quota)는 평소 사용과 같은 칸을 쓴다 — GET /api/messages 는 대략 "쓰고 있는 탭 수 × 1분에 1번 + 평소 목록 · 더 보기"다(3단계). 5단계부터는 실시간 연결이 살아 있는 동안 1분 확인 대신 "바뀔 때마다(1초 모아서) 보이는 탭 수 × 1번"이다 — 사무실이 바쁠수록 늘 수 있다. 운영 전환 때 직원 수에 맞춰 정한다.
• 5단계부터는 실시간 연결(아래 "실시간 알림")이 살아 있는 동안 1분 확인을 멈추고, 끊기면 1분 확인으로 돌아간다. 이 API 와 규칙은 그대로다.

검색 (GET /api/messages 의 q) — 3단계

• mailboxId 가 있으면 그 메일함에서, 없으면 휴지통 · 스팸메일함을 뺀 모든 메일함에서 찾는다. 둘 다 없으면 400 VAL_001.
• q 는 앞뒤 공백을 뺀 1~200자(JS 문자열 길이 — UTF-16 단위), 낱말(띄어쓰기로 나눈 것) 8개까지(넘으면 400 VAL_001). 보낸 사람 · 받는 사람 · 참조 · 제목 · 본문에서 찾고, 여러 낱말이면 모두 들어간 메일만 찾는다. 큰따옴표로 감싼 부분은 그 구절 그대로 찾는다. 낱말 앞뒤의 문장부호는 떼고 찾는다('회의,' · '(회의)' → '회의' — 엔진도 문장부호에서 낱말을 나눈다, 가운데의 문장부호는 둔다). 글자 · 숫자가 하나도 없는 낱말(- · 따옴표뿐 등)은 찾지 않고, 찾을 낱말이 하나도 남지 않으면 엔진에 묻지 않고 빈 결과(200)다.
• 한국어 — 서버가 보완한다: 엔진(Stalwart 0.16.27)의 전문 검색은 띄어쓰기 · 문장부호로 나눈 낱말이 통째로 같을 때만 맞는다 — '회의'로는 '회의를'을 찾지 못한다 (2026-10-27 개발 엔진에서 확인). 그래서 서버는 한글로 끝나는 낱말마다 흔한 조사를 받침에 맞게 붙인 형태를 함께 찾는다 (회의 → 회의가 · 회의를 · 회의는 · 회의에서 · 회의입니다 … / 일정 → 일정이 · 일정을 · 일정은 …, 낱말 안에서는 OR · 낱말끼리는 AND). 영문 · 숫자로 끝나는 낱말(ERP · 2026)은 받침을 알 수 없어 두 가지를 다 붙인다. 따옴표 구절에는 붙이지 않는다. 조사 목록은 서버 상수 한 곳(jmap/search-terms.ts)에 둔다 — 한글로 끝나는 낱말은 형태 44개, 영문 · 숫자로 끝나면 59개가 되고, 개발 엔진에서 낱말 8개(조건 472개)를 전체 메일함에서 찾는 데 0.16초였다.
• 알려진 한계 (엔진 색인 때문 — 자체 검색 색인을 두기 전까지): 붙여 쓴 말의 일부('회의실'의 '회의', '서버이전'의 '서버'), 앞부분만 친 말('견적' → '견적서'), 끝이 바뀐 말('보냈습니다'의 '보내'), 제목 맨 앞의 말머리('[공지]' · '[긴급]' · 'Re:' · 'Fwd:' — 엔진이 제목을 정규화하며 색인에서 뺀다. 제목 가운데의 '[결재]'는 찾는다). 화면은 결과가 없을 때 이 한계를 한 줄로 알린다.
• 결과는 받은 시각 내림차순, total 포함. 커서는 그 검색어 · 범위로만 쓴다(다르면 400 VAL_001). 발송 중인 내부 초안은 지금처럼 빠진다.
• 검색어는 접근 로그 · 백엔드 로그에 남기지 않는다 — 백엔드는 지금처럼 maskUrlForLog()(q · cursor 는 길이만). 화면 주소에도 검색어가 들어가므로 nginx 는 /api 뿐 아니라 화면 요청의 접근 로그도 쿼리 없이 남기고(Referer 도 ? 앞까지), 화면 응답의 Referrer-Policy 를 strict-origin 으로 둔다 — 검색 화면에서 나가는 요청(1분 확인 등)의 Referer 에 검색어가 실리지 않게. 오류 로그는 장애 원인 줄을 잃지 않게 지금처럼 요청 줄을 쿼리째 남긴다 (docker 스킬 "로그").
• 클라이언트: 상단 검색 칸(메일 화면에서는 "메일 검색")에서 Enter 로 찾는다 — 치는 동안에는 묻지 않는다. 서버와 같은 한도(200자 · 낱말 8개)를 먼저 보고, 낱말이 8개를 넘으면 보내지 않고 VAL_001 사전 문구로 알린다. 검색 화면 안에서 다시 찾거나 범위를 바꾸면 방문 기록을 쌓지 않고 주소를 바꿔 끼운다(메일함에서 시작한 첫 검색만 기록에 쌓인다). 주소는 /mail/search?q=…&in=<메일함 id | all>, 결과에서 연 메일은 /mail/search/<메일 id>?q=…&in=… (뒤로 가기: 메일 → 결과 → 검색 전 메일함). 범위의 기본값은 검색을 시작한 메일함이고 결과 머리에서 "그 메일함 | 전체 메일함"으로 바꾼다(휴지통 · 스팸메일함에서 시작하면 그 안에서 찾는다). ✕ · Esc · "검색 닫기"는 검색 전 메일함으로 돌아간다. 임시보관함의 결과를 누르면 지금처럼 쓰기 화면에서 이어 쓴다.

여러 통 한꺼번에 (PATCH /api/messages · POST /api/message-deletions) — 3단계

// PATCH /api/messages — 읽음 · 중요 표시 · 이동을 여러 통에
interface MessagesPatch {
  ids: string[]          // 1~100, 같은 id 를 두 번 넣지 않는다
  isRead?: boolean
  isFlagged?: boolean
  mailboxId?: string     // 이동 = 그 메일함 하나에만 속하게 (단건 PATCH 와 같다)
}                        // 바꿀 것이 하나 이상
interface MessagesPatched {
  updatedIds: string[]
  failedIds: string[]    // 없음 · 그사이 지워짐 · 엔진이 거절함 — 나머지는 그대로 처리한다
}

// POST /api/message-deletions — 휴지통에서 영구 삭제, 여러 통
interface MessageDeletionRequest { ids: string[] }   // 1~100, 같은 id 를 두 번 넣지 않는다
interface MessageDeletionResult {
  deletedIds: string[]   // 영구 삭제했다(휴지통에만 있었다) · 휴지통에서만 뺐다(다른 메일함에도 있었다)
  skippedIds: string[]   // 휴지통에 없음 · 없음 · 엔진이 거절 — 지우지 않았다
}

• PATCH /api/messages 는 엔진 요청 한 번으로 처리한다. 없는 mailboxId 는 404 RES_001 이고 아무것도 바꾸지 않는다. 503 MAIL_001 이면 일부만 바뀌었을 수 있다 — 같은 요청을 다시 보내도 결과가 같다(멱등).
• POST /api/message-deletions 는 휴지통에 있는 메일만 다룬다 — DELETE /api/messages/{id} 와 달리 휴지통 밖의 메일을 휴지통으로 옮기지 않는다. 대상을 확인한 뒤 확인한 상태 그대로일 때만 한 번에 지운다(ifInState — 그사이 다른 창이 휴지통 밖으로 되돌린 메일을 지우지 않는다). 어긋나면 다시 확인해 합계 CONDITIONAL_DESTROY_ATTEMPTS 번, 계속 어긋나면 아무것도 지우지 않고 503 MAIL_001. 휴지통이 없어도 503 MAIL_001. 지우는 요청이 엔진 시간 초과로 끝난 503 MAIL_001 만은 일부가 지워졌을 수 있다 — 같은 요청을 다시 보내면 이미 지운 메일은 skippedIds 로 온다. 한 번에 지우기(destroy)와 휴지통에서 빼기(update)를 함께 보내고, 옛 상태면 엔진이 둘 다 거절한다 (2026-10-27 개발 엔진에서 확인).
• 한 요청의 ids 는 100개까지다 (엔진의 한 번 처리 한도 500 보다 작게).
• 클라이언트:
  • 고를 수 있는 것은 불러온 메일까지다 (표 머리의 고르기 = 불러온 메일 모두). 100통이 넘으면 100통씩 차례로 보낸다.
  • 휴지통 밖의 「삭제」는 PATCH { mailboxId: 휴지통 } 이다 — 「되돌리기」는 원래 메일함별로 묶어 다시 PATCH. POST /api/message-deletions 는 휴지통에서 「영구 삭제」를 확인한 뒤에만 부른다.
  • 웹 클라이언트는 DELETE /api/messages/{id} 를 쓰지 않는다 — 그사이 다른 창이 휴지통으로 옮긴 메일을 확인 없이 영구 삭제하게 된다. 읽기 화면의 「삭제」도 그 메일의 mailboxIds 를 보고 휴지통 밖이면 휴지통으로 PATCH(+ 되돌리기), 휴지통이면 확인 대화상자 뒤 POST /api/message-deletions 다. 휴지통 목록 밖(검색 결과 등)에서는 휴지통에만 있는 메일만 「영구 삭제」다 — 휴지통과 다른 메일함에 함께 있는 메일은 「삭제」(휴지통으로 옮기기)로 다룬다 (영구 삭제를 확인했는데 서버가 휴지통에서만 빼고 다른 메일함에 남기는 일이 없게). mailboxIds 가 낡았어도 해가 없다 — 이미 휴지통인 메일을 휴지통으로 옮기면 그대로이고, 휴지통 밖으로 돌아간 메일은 서버가 skippedIds 로 건너뛴다.
  • 알려진 한계: 「되돌리기」는 이 화면이 알던 메일함 한 곳으로 되돌린다 — 그사이 다른 창이 옮긴 메일(저절로 바뀌지 않는 검색 결과 등)은 그 전 메일함으로, 여러 메일함에 함께 있던 메일(다른 메일 프로그램의 복사)은 첫 메일함으로만 돌아간다.
  • 「되돌리기」 알림은 만든 세션에서만 움직인다 — 로그아웃 · 세션 만료 · 다른 계정 로그인 뒤에는 아무것도 하지 않는다(메일 id 는 계정마다 따로 매겨져 겹칠 수 있다).
  • 읽음 · 중요 표시는 화면을 먼저 바꾸고 failedIds 만 되돌린다. 이동 · 삭제는 응답을 받은 뒤 updatedIds · deletedIds 만 목록에서 빼고 개수를 다시 맞춘다 (전체 메일함 검색 결과에서 범위 안의 다른 메일함으로 옮긴 메일은 여전히 찾은 메일이라 빼지 않고 메일함 표시만 바꾼다 — 휴지통 · 스팸메일함으로 옮기면 뺀다). 요청이 통째로 실패해 하나도 처리하지 못하면 고른 것을 그대로 둔다(다시 시도할 수 있게).
  • failedIds · skippedIds 가 있으면 알림에 "N통은 그사이 옮겨졌거나 지워져 그대로 두었습니다"를 덧붙인다.
  • 메일함을 바꾸거나 검색하면 선택을 푼다. 새 메일 확인으로 목록을 맞출 때는 남아 있는 메일의 선택을 그대로 둔다.

메일함 관리 (/api/mailboxes) — 4단계

interface MailboxCreate { name: string; parentId?: string | null }   // parentId 없음 = 맨 위
interface MailboxRename { name: string }
interface MailboxDeletion {
  deleted: boolean        // true = 지웠다. false = 아직 옮길 메일이 남았다 — 같은 요청을 다시 보낸다
  processed: number       // 이번 요청에서 이 메일함에서 빠진 메일 수 — 휴지통으로 옮김 + 다른 메일함에도 있어 이 메일함에서만 뺌 (진행 표시용)
  movedToTrash: number    // 그중 휴지통으로 옮긴 수 (끝난 알림의 "안의 메일 N통은 휴지통에 있습니다")
  remaining: number       // 아직 남은 메일 수
}
interface MailboxBulkResult {
  processed: number       // 이번 요청에서 읽음으로 바꾼 · 지운 메일 수
  remaining: number       // 남은 수 — 0 이 될 때까지 같은 요청을 다시 보낸다
}

• 이름: 앞뒤 공백을 뺀 1~64자(JS 문자열 길이), / 는 쓰지 않는다(경로 구분자로 읽는 메일 프로그램이 있다). 제어 문자도 쓰지 않는다 — C0(U+0000–U+001F, 탭 · 줄바꿈 포함) · DEL(U+007F) · C1(U+0080–U+009F). 그 밖의 문자(NBSP · 이모지 등)는 받는다. 같은 상위 안에 같은 이름은 409 MAIL_009 (엔진이 alreadyExists 로 거절한다 — 2026-10-28 확인). 지금 이름으로 바꾸면 엔진에 묻지 않고 그대로 돌려준다. 만든 메일함은 구독 상태(isSubscribed)라 IMAP 메일 프로그램에도 보인다.
• 만들 수 있는 자리: 맨 위, 받은편지함 · 보관함 · 내 메일함(역할 없음) 아래. 보낸편지함 · 임시보관함 · 스팸메일함 · 휴지통 아래는 400 VAL_001. 웹 화면은 받은편지함 · 내 메일함 아래만 메뉴에 둔다(보관함 아래는 다른 메일 프로그램이 만든 것을 그대로 보인다).
• 기본 메일함(역할이 있는 메일함)은 이름을 바꾸거나 지울 수 없다 — 400 VAL_001. 화면은 메뉴에 그 항목을 두지 않는다.
• 지우기: 하위 메일함이 있으면 400 VAL_001(화면이 먼저 막는다). 안의 메일은 휴지통으로 옮긴 뒤(다른 메일함에도 있는 메일은 이 메일함에서만 뺀다) 빈 메일함을 지운다 — 엔진은 메일이 든 메일함을 mailboxHasEmail 로 거절하므로(onDestroyRemoveEmails: false — 메일을 영구 삭제하는 옵션은 쓰지 않는다) 그사이 들어온 메일도 남지 않는다. 메일이 많으면 한 요청에 다 옮기지 못한다 — deleted: false 면 클라이언트가 같은 요청을 다시 보낸다.
• 전체 읽음(PATCH /api/mailboxes/{id}/messages {isRead:true}): 안 읽은 메일을 500통씩 읽음으로 바꾼다. 비우기(DELETE /api/mailboxes/{id}/messages): 휴지통 · 스팸메일함만, 500통씩 확인한 상태 그대로일 때만(ifInState) 영구 삭제한다 — 그 메일함에만 있는 메일은 지우고, 다른 메일함에도 있는 메일은 그 메일함에서만 뺀다(POST /api/message-deletions 와 같은 규칙).
• 오래 걸리는 처리(전체 읽음 · 비우기 · 메일함 지우기)는 한 요청을 25초 안에 끝내고(엔진 호출마다 남은 시간만큼만 기다린다) remaining 을 돌려준다. 클라이언트는 0(또는 deleted: true)이 될 때까지 다시 보내며 진행을 알림으로 보인다("…하는 중 · 600 / 1,234통"). 도중에 실패하면 거기까지 처리한 수를 알리고, 다시 하면 남은 것만 처리한다.
  • 같은 직원 · 같은 메일함의 처리는 한 번에 하나다 — 진행 중이면 엔진에 묻지 않고 429 REQ_001(다른 탭에서 같은 메일함을 처리할 때). 다른 메일함끼리는 함께 된다.
  • 한 요청의 상한 25초는 메일함 목록을 읽기 전부터 잰다(엔진의 세션 조회 포함). 다음 500통은 남은 시간이 5초보다 많을 때만 시작한다.
  • 멈추는 경우 — 진행한 것이 있으면 거기까지 200(remaining > 0 · deleted: false), 하나도 처리하지 못했으면 503 MAIL_001(클라이언트가 끝없이 다시 보내지 않게): 아무것도 바뀌지 않는 차례(확인하는 사이 계속 바뀜 · 바뀐 것도 거절도 없음 · 비운 메일함을 지우는 사이 메일이 들어옴)가 이어서 3번, 남은 시간 때문에 엔진 호출이 끊김. 엔진이 한 차례를 모두 거절하면 진행한 것이 없을 때 그 거절의 코드(권한 없음 403 AUTH_003 등)다.
  • 비우기는 차례마다 그 시점의 메일함을 다시 읽는다 — 비우는 동안 들어온 메일(새 스팸, 다른 탭에서 휴지통으로 옮긴 메일)도 지운다(흔한 메일 프로그램과 같다). 그래서 화면은 휴지통 비우기와 메일함 지우기(안의 메일이 휴지통으로 간다)를 함께 돌리지 않는다.
• 클라이언트: 메일함 패널의 각 메일함 ⋯ 메뉴 — 모두 읽음으로 표시(안 읽은 메일이 있을 때) · 하위 메일함 만들기 · 이름 바꾸기 · 지우기(내 메일함만) · 휴지통 / 스팸메일함 비우기. 휴지통 · 스팸메일함 목록 머리에도 「비우기」. 비우기 · 지우기는 확인 대화상자(처음 초점 「취소」) 뒤에만 하고, 확인한 그 메일함만 처리한다. 다른 탭에서 먼저 끝냈으면 실패로 보이지 않는다 — 모두 읽음 · 비우기의 0통은 "…에 안 읽은 메일이 없습니다" · "…이 이미 비어 있습니다", 지우기의 404 RES_001 은 지운 것으로 본다. 메일함 지우기의 진행은 processed 로 센다(movedToTrash 는 휴지통으로 간 것만이라 다른 메일함에도 든 메일만 남으면 늘지 않는다).

부재중 자동 응답 (/api/mail-vacation) — 4단계

interface MailVacation {
  isEnabled: boolean
  fromDate: string | null   // ISO 8601 UTC — null 이면 켠 때부터
  toDate: string | null     // null 이면 끌 때까지
  subject: string           // 켤 때 150자까지(꺼 둔 채로는 200자까지 — 아래 "길이 한도의 근거") — 켤 때(isEnabled true)는 공백이 아닌 글자 1자 이상. 제어 문자(메일함 이름과 같은 범위 — 탭 · 줄바꿈 포함)는 쓰지 않는다(한 줄짜리 머리글)
  textBody: string          // 켤 때 600자까지(꺼 둔 채로는 4,000자까지) — 켤 때는 공백이 아닌 글자 1자 이상. 글자만(서식 없음) — 제어 문자는 탭 · LF · CR 만. 서명은 붙지 않는다
}

• 길이 한도의 근거 (6단계 앞 수정): 엔진이 UTF-8 바이트로 막는다 — 제목 511바이트(한글 170자 · 영문 511자), 본문 2,047바이트(한글 682자 · 영문 2,047자) (Stalwart 0.16.27, 2026-10-28 확인 — 넘으면 엔진이 invalidProperties 로 거절해 400 VAL_001 이었다. 4단계 계약의 200자 · 4,000자는 한글로는 맞지 않았다). 글자마다 바이트가 달라(한글 3 · 이모지 4바이트/2자) 어떤 글이어도 넘지 않는 150자 · 600자로 둔다(JS 문자열 길이). 이 한도는 켤 때만 본다 — 꺼 둔 채로는 4단계 한도(200자 · 4,000자)까지 받는다. 4단계에 엔진 한도 안으로 저장해 둔 긴 글(영문 내용 1,000자 등)이 켜져 있으면 화면은 꺼 둘 때 칸이 흐려 고칠 수 없는데, 끄기는 늘 저장되어야 하기 때문이다. 다시 켤 때 150 · 600 에 걸리면 줄인 뒤 켠다.

• 한 번도 설정하지 않은 계정은 { isEnabled: false, fromDate: null, toDate: null, subject: "", textBody: "" } 로 온다(엔진의 null 은 빈 문자열로). 끈 채로는 빈 제목 · 내용도 저장된다. 제목 · 내용은 쓴 그대로 저장한다 — "공백이 아닌 글자" 검사만 앞뒤 공백을 뺀 값(JS trim() — NBSP · U+3000 포함)으로 한다. 제어 문자 검사는 꺼 둔 채로도 한다.

• 저장 자리 — 6단계부터 메일 필터와 같은 엔진 규칙(Sieve 스크립트 arasystem)에 둔다(아래 "메일 필터"의 "저장 자리"). 4단계에는 엔진의 JMAP VacationResponse(singleton)였다. 서식 본문은 없다(글자만). 저장은 전체 교체이고 응답은 저장한 값이다. 꺼도 쓴 제목 · 내용은 남겨 둔다. 필터와 한 스크립트라서 부재중을 저장해도 스크립트를 다시 켠다(필터가 꺼져 있었으면 함께 다시 동작한다). 필터 규칙은 건드리지 않는다.

  • 6단계부터 바뀐 동작: 엔진이 스팸으로 분류한 메일에는 답하지 않는다(필터와 같은 스팸 막기 — "메일 필터"의 "만드는 Sieve").
  • 우리 스크립트가 엔진에서 꺼져 있으면(필터의 isActive: false) 부재중도 동작하지 않는다. 이 API 의 isEnabled 는 저장한 값이라 그때도 true 로 온다 (알려진 한계 — 드묾. 화면은 필터 화면의 줄로만 알린다).
  • 저장해 둔 원본이 깨진 계정은 꺼짐(isEnabled: false, 빈 제목 · 내용)으로 온다. 원본이 이 서버보다 새 판이면 저장은 503 MAIL_001 이다("메일 필터"의 "저장 자리").

• fromDate · toDate 는 Z 로 끝나는 UTC 시각이고, 두 키는 늘 보낸다(값은 null 가능). 엔진에는 초 단위로 저장한다(소수 초는 버린다). 둘 다 있으면 버린 값으로 fromDate < toDate(아니면 400 VAL_001). 화면은 날짜만 고르고, 브라우저 시간대의 시작일 0시 · 끝나는 날 다음 날 0시를 UTC 로 보낸다.

• 같은 사람에게 매번 답하지는 않는다 — JMAP 규격(RFC 8621 8절)이 "보낸 사람마다 적당한 기간에 한 번" 을 요구하고 엔진이 따른다. 6단계부터는 Sieve vacation(RFC 5230)이 같은 일을 한다 — 간격은 엔진 기본값이다.

• 클라이언트: 설정 › 메일 › 부재중 자동 응답. 켜져 있으면 메일 화면의 메일함 패널 아래(사용량 위)에 "부재중 자동 응답 켜짐 · 11월 3일까지"(누르면 설정)를 보인다 — 메일 화면에 들어올 때 한 번 받고, 시간이 지나면 다시 계산한다(끝나는 시각이 지나면 숨기고, 시작 전이면 "10월 30일 ~ 11월 3일 · 설정").

스팸 · 원문 — 4단계

• 스팸 신고 · 스팸 아님: PATCH /api/messages/{id} · PATCH /api/messages 의 isJunk — true 면 키워드 $junk 를 붙이고 $notjunk 를 뗀다, false 면 반대(RFC 8621 4.1.1). 화면은 이동과 함께 보낸다 — 스팸 신고 { mailboxId: <스팸메일함>, isJunk: true }, 스팸 아님 { mailboxId: <받은편지함>, isJunk: false }. 엔진의 스팸 학습에 쓰이는지는 엔진 몫이다. 「되돌리기」는 원래 메일함으로 옮기며 보낸 값의 반대를 보낸다 — 표시를 지우는 값은 두지 않아서, 원래 아무 표시도 없던 메일도 되돌린 뒤에는 $notjunk(스팸 아님)가 남는다.
• 원문 내려받기: GET /api/messages/{id}/source — 엔진의 원본(blob)을 그대로 흘려보낸다(message/rfc822, Cache-Control: private, no-store). 파일 이름은 제목(없으면 "메일")에 .eml — 다운로드 헤더는 첨부와 같은 규칙(shared/utils/content-disposition.ts). 화면은 첨부 내려받기처럼 이동 전에 세션을 확인한다(confirmSession()).

실시간 알림 (GET /api/mail-events) — 5단계

서버가 메일 엔진(Stalwart)의 JMAP EventSource(RFC 8620 7.3)를 직원마다 하나 열고, 그 소식을 브라우저에 SSE(text/event-stream)로 흘려보낸다. 표준 응답 래퍼는 없다.

event: state
data: {"state":"<GET /api/mail-state 의 state 와 같은 값>","inboxUnread":3}

event: new-mail
data: {"count":2,"messages":[{"id":"…","from":{"name":"박서준","email":"seojun.park@arasystem.it.kr"},"subject":"…","receivedAt":"2026-10-28T05:42:00.000Z"}]}

event: ping
data: {"upstream":true}

event: end
data: {"reason":"token-expiring"}

이벤트	언제 · 뜻
state	연결 직후 한 번, 그 뒤 메일함 · 메일이 바뀔 때마다(엔진 신호를 0.3초 모아서). state 는 GET /api/mail-state 와 같은 값, inboxUnread 는 받은편지함의 안 읽은 수
new-mail	받은편지함에 새로 배달된 메일이 있을 때 — $draft 아님 · $seen 아님 · 보낸 사람이 나 아님. 새것부터 최대 5통(count 는 전체 수). 같은 변화의 state 다음에 온다
ping	25초마다(직원마다 한 간격 — 새 연결의 첫 ping 은 더 빨리 올 수 있다), 그리고 upstream 이 바뀌면 그때 바로. upstream: false 면 서버와 엔진 사이가 끊겨 다시 잇는 중이다 — 그동안 클라이언트는 1분 확인으로 돌아간다. 다시 잇는 중에 새로 연결하면 마지막으로 알던 state 와 ping {upstream:false} 가 바로 온다
end	서버가 곧 닫는다 — token-expiring(액세스 토큰이 끝나기 30초 전 — 남은 시간이 30초 이하인 토큰(세션이 끝나기 30초 안에 갱신한 토큰)이면 토큰이 실제로 끝날 때) · server-shutdown(서버 종료 · 재시작)

연결 전 실패 (표준 실패 형식 JSON)	코드
로그인 안 됨 · 토큰 만료	401 AUTH_001
한 직원의 연결이 5개를 넘음(브라우저마다 하나라 기기 · 브라우저 5개) · 요청 수 한도(경로마다 IP 당) · 엔진 한도	429 REQ_001
엔진에 연결할 수 없음(처음 연결 10초 상한) · 기다리는 사이 엔진 연결이 끝남 · 서버 종료 중	503 MAIL_001

스트림이 열린 뒤 계정을 더 쓸 수 없게 되면(엔진이 대리 접근을 거절) end 없이 닫는다 — 클라이언트는 끊김으로 보고 다시 이어 401 → 갱신 실패 → 세션 만료로 간다.

• 서버: 직원마다 엔진 연결 하나를 그 직원의 모든 연결에 나눠 쓴다(마지막 연결이 닫히고 30초 뒤 닫는다 — 새로 고침에 다시 열지 않게). 엔진 연결은 대리 접근 자격 · types=Mailbox,Email · ping=30 이다 — 엔진은 30초보다 짧게 주지 않는다(10초를 달라고 해도 30초, 2026-10-28 확인). 75초 동안 아무것도 오지 않으면 끊긴 것으로 보고 다시 잇는다(1 · 2 · 5 · 10 · 30초 간격에 ±20% — 엔진이 다시 뜰 때 모든 직원이 같은 순간에 붙지 않게). 그동안 클라이언트에는 ping 의 upstream: false 로 알린다. 같은 기준으로 이어서 3번 묻지 못하면 기준을 버리고 처음 상태로 다시 잡는다(그 차례는 new-mail 없이 — 엔진 한도 · 엔진이 내려간 동안은 세지 않는다). 엔진이 묻기를 한도(429)로 막으면 엔진 연결은 두고 5초(±20%) 뒤 다시 묻는다(upstream 은 true 그대로 — 다시 잇는 중이면 다시 잇기 간격대로). 5분 안전판: 엔진 신호가 없어도 마지막으로 물은 지 5분이 지나면 한 번 묻고, 달라졌으면 state(와 new-mail)를 보낸다 — 연결이 살아 있는 동안 클라이언트는 1분 확인을 멈추므로, 엔진이 신호를 빠뜨려도 낡은 값이 5분 넘게 남지 않게.
• 새 메일 판단: 엔진의 Email/changes(지난 state 부터 생긴 메일) → Email/get 으로 한다. 엔진의 EmailDelivery 신호는 초안을 만들어도 바뀌므로 쓰지 않는다(2026-10-28 확인). 배달에서 신호까지 0.5초 남짓이다(같은 날 개발 엔진). 다음 경우에는 new-mail 없이 state 만 보내고 기준을 다시 잡는다: 바뀐 것을 셀 수 없음(cannotCalculateChanges), 엔진이 옛 기준을 거부함(Stalwart 0.16.27 은 해석하지 못하는 sinceState 에 HTTP 400 notRequest 로 요청 전체를 거부한다 — 2026-10-28 확인), 한 번에 2,000건(500 × 4) 넘게 바뀜. Email/changes 의 생성은 "배달"이 아니라 "만들어짐"이다 — 받은 시각(receivedAt)이 변화를 본 때보다 10분 넘게 앞선 메일은 알리지 않는다 (메일 프로그램의 올리기 · mailcow 에서 옮길 때의 IMAP 가져오기(imapsync)가 옛 메일을 넣어도 알림이 쏟아지지 않게). 받은 시각을 읽지 못한 메일도 빼고, 엔진 시계가 앞서 미래 시각인 메일은 넣는다. 그래서 서버와 엔진 사이가 10분 넘게 끊겼다 다시 이으면, 그동안 온 메일은 state 로만 알린다(목록에는 나타나고 바탕화면 알림은 없다). "보낸 사람이 나"는 토큰의 주소와 발신 ID(별칭) 주소로 본다(대소문자 무시).
• 오래 열린 엔진 연결은 엔진의 동시 요청 한도(4)를 잡아먹지 않는다 — 한 직원의 스트림 8개를 연 채 그 직원 · 다른 직원의 보통 요청과 동시 요청 6개가 모두 됐다(2026-10-28 확인).
• 연결은 액세스 토큰이 끝날 때 닫는다(최대 1시간 — 그 전에 end). 로그아웃 · 비밀번호 변경으로 세션을 끊어도 다른 API 처럼 액세스 토큰이 끝날 때까지는 이어진다(1절 세션 규칙). 서버가 종료될 때는 열린 연결을 end 로 먼저 닫는다 — 오래 열린 연결이 종료를 붙잡지 않게. 알려진 한계: 잠자기 · VPN 재연결 · 망 바꿈으로 반쯤 열린 연결은 서버가 ping 을 쓰다 실패할 때(OS 기본 15분 안팎)까지 자리를 잡는다 — 그사이 그 직원의 연결이 5개에 닿으면 새 연결은 429 이고 화면은 1분 확인으로 이어진다.
• 응답 머리글: Content-Type: text/event-stream, Cache-Control: no-cache, no-transform, X-Accel-Buffering: no. 서버는 스트림을 열기로 정하면 머리글을 바로 보낸다. 앞단 nginx 는 이 경로만 버퍼링 · 캐시 · 압축을 끄고, 읽기 사이 시간 제한을 90초로 둔다(응답 전체가 아니라 두 번 읽는 사이 — ping 25초 · 클라이언트 감시 75초보다 길게, 머리글이 오지 않으면 90초에 504). 외부 리버스 프록시도 버퍼링을 끄고, 응답 전체 시간에 상한이 있으면 1시간 넘게 둔다(운영 확인 항목 — docker 스킬). 앱 로그에는 열고 닫는 것을 남기지 않는다(반복되는 정상 흐름) — 엔진 연결이 이어서 실패하면 warn. nginx 접근 로그에는 연결이 끝날 때 한 줄이 남는다(rt= 가 이어진 시간).
• 클라이언트
  • 브라우저마다 연결 하나 — 탭이 여러 개면 한 탭만 연결하고(Web Locks) 다른 탭에 소식을 나눈다(BroadcastChannel). 탭마다 열면 HTTP/1.1 의 주소당 연결 6개를 금방 다 쓴다. 연결한 탭을 닫으면 다른 탭이 이어받는다. Web Locks 가 없는 브라우저는 실시간 없이 1분 확인만 한다. 연결은 로그인한 동안 앱 전체에서 유지한다(설정 등 메일 밖 화면에서도 바탕화면 알림 · 연결 상태가 이어지게). 목록 맞추기 · 1분 확인 멈춤은 메일 화면이 있을 때만 한다.
  • fetch 로 읽는다 — 브라우저의 EventSource 는 401 을 알 수 없어 세션을 갱신할 수 없다. 401 이면 세션을 한 번 갱신하고 다시 잇는다(갱신도 실패하면 지금의 세션 만료 흐름).
  • 연결이 살아 있는 동안(75초 안에 ping · state 가 오고 upstream: true)은 1분 확인을 멈춘다. 75초는 요청을 시작한 때부터 센다(머리글이 오지 않는 연결도 끊게). 끊기면(읽기 오류 포함 — 서버의 end 가 아닌 끝) 1분 확인으로 돌아가고 2 · 5 · 15 · 30 · 60초 간격으로 다시 잇는다. 연결이 자리 잡으면(첫 state 뒤 upstream: true 인 ping 이 오거나 20초가 지나면) 처음 간격부터 다시 센다. 자리 잡은 연결의 end 는 바로 다시 잇는다 (token-expiring 은 세션을 갱신한 뒤, server-shutdown 은 0~3초 흔들어 — 배포 때 모든 브라우저가 같은 순간에 붙지 않게). 그동안은 끊김으로 보지 않는다. 자리 잡기 전에 온 end 는 까닭과 상관없이 실패처럼 간격을 둔다 — 열리자마자 끝나는 연결(세션 끝 직전의 짧은 토큰 · 응답을 짧게 끊는 프록시)에서 갱신 · 다시 잇기를 왕복 시간 속도로 되풀이하지 않게(갱신 한도는 IP 마다라 같은 사무실 직원까지 막는다). 다시 잇는 간격의 흔들림은 ±20%.
  • 세션을 갱신한 바로 뒤의 다시 잇기가 또 401 이면 세션 만료로 본다(axios 의 401 재시도와 같다 — 그 시도가 다른 까닭으로 끝나면 이 표시는 지운다). 갱신이 장애(5xx · 네트워크)로 실패하면 위 간격으로 기다렸다 다시 갱신해 본다. 한 이벤트가 1MB 를 넘으면 실패로 끊는다.
  • 연결한 탭이 그만둘 때(닫힘 · 로그아웃 · pagehide)와 잠금을 이어받은 탭이 연결하기 전에 다른 탭에 끊김을 알린다 — 이어받은 탭의 연결이 열릴 때까지 모든 탭이 1분 확인으로 돌아간다 (탭 닫기 · 탭 폐기처럼 그만두는 탭이 알리지 못한 경우도 덮는다). 살아 있던 연결이 끊기면 1분 확인이 바로 한 번 묻고, 그 뒤 60초마다 묻는다.
  • state 가 바뀌면 보이는 탭은 지금의 1분 확인이 하는 일(개수 · 보이는 목록 맞추기)을 그대로 하고, 숨은 탭은 inboxUnread 로 탭 제목만 맞춘 뒤 다시 보일 때 맞춘다. 실시간이 부른 맞추기는 1초 모아서 한 번 한다(한 통을 읽어도 state 가 바뀐다 — 연달은 바뀜에 목록을 여러 번 받지 않게).
  • 바탕화면 알림(설정 › 메일 › 알림 — 브라우저 · 사용자마다 localStorage): 켜져 있고 브라우저가 허락했을 때, new-mail 을 받았는데 웹메일을 보고 있는 탭(보이고 초점이 있는 탭 — visibilityState === 'visible' && document.hasFocus())이 하나도 없으면 알린다. 두 번째 모니터에 웹메일을 띄워 두고 다른 창에서 일할 때도 알린다("다른 창을 보는 동안에도"). 한 통이면 제목 = 보낸 사람(이름, 없으면 주소) · 내용 = 메일 제목(「메일 제목도 보이기」를 끄면 "새 메일이 왔습니다"), 여러 통이면 "새 메일 N통" · "박서준 · 이도윤 외 1명". 같은 tag 로 앞 알림을 바꿔 쓴다(쌓이지 않는다). 누르면 그 탭으로 와서 메일을 연다(여러 통이면 받은편지함). 사용자가 웹메일로 돌아오면(어느 탭이든 보이고 초점이 생기면) 띄운 알림을 닫는다. 허락은 사용자가 누른 뒤에만 묻는다(목록 위 한 번 권하기 · 설정의 켜기 칸). new Notification() 을 막는 브라우저(휴대폰 Chrome)는 처음 실패할 때 "지원하지 않음"으로 바꾼다.

메일 필터 (/api/mail-filters) — 6단계

interface MailFilterSet {
  rules: MailFilterRule[]     // 위에서부터 차례로 적용한다 — 50개까지
  version: string             // 지금 규칙의 지문 — 해석하지 말고 PUT 에 그대로 돌려보낸다(그사이 다른 곳에서 규칙이 바뀌었으면 409 MAIL_012). 영문 · 숫자 · - · _ 128자까지. 규칙만 본다(부재중이 바뀌어도 그대로)
  isActive: boolean           // false = 우리 규칙이 엔진에서 꺼져 있거나(다른 규칙이 켜짐) 저장해 둔 원본을 읽을 수 없어 지금은 필터 · 부재중 응답이 동작하지 않는다(드묾) — 저장하면 다시 켜진다
                              // (아래 "저장 자리"의 새 판 원본은 예외). 한 번도 저장하지 않은 계정은 true(막힌 것이 없다)
}
interface MailFilterRule {
  id: string                  // 클라이언트가 만든다(UUID — 영문 · 숫자 · - · _ 64자까지) — 목록 안에서 겹치지 않게
  name: string                // 0~50자(앞뒤 공백은 지워 저장한다), 제어 문자는 안 된다 — 비면 화면이 조건으로 이름을 보인다
  isEnabled: boolean
  match: 'all' | 'any' | 'always'     // 조건이 모두 맞음 · 하나라도 맞음 · 모든 메일(조건 없음)
  conditions: MailFilterCondition[]   // all · any 는 1~5개, always 는 빈 배열
  actions: MailFilterActions          // 하나 이상
}
interface MailFilterCondition {
  field: 'from' | 'to' | 'subject' | 'body'  // 보낸 사람(이름 · 주소) · 받는 사람(받는 사람 · 참조의 이름 · 주소) · 제목 · 본문(글자 부분)
  operator: 'contains' | 'notContains'
  value: string               // 1~200자(앞뒤 공백을 지운 값 — 그 값으로 저장한다), 제어 문자 · `${` 는 안 된다
}
interface MailFilterActions {
  moveToMailboxId: string | null  // 받은편지함 · 내 메일함 · 보관함 · 스팸메일함 · 휴지통 (보낸편지함 · 임시보관함은 400 VAL_001). 없는 id 도 받는다 — 지운 메일함을 가리키는 규칙이 남아 있을 수 있다
  markAsRead: boolean
  flag: boolean
  forwardTo: string | null        // 사내 주소(도메인이 `MAIL_DOMAIN` 과 똑같은 주소 — 하위 도메인은 안 된다)만, 자기 주소는 안 된다(대소문자 무시).
                                  // 앞뒤 공백은 지워 저장한다. `${` 는 안 된다
}

• PUT 본문은 { rules, version } 뿐이다 — isActive 같은 다른 키를 보내면 400 VAL_001(모르는 필드). 응답은 저장한 규칙(앞뒤 공백을 지운 값)과 새 version 이다.

• 적용 순서 — 새로 온 메일을 위의 규칙부터 차례로 견주고, 맞는 규칙의 할 일을 모두 한다(읽음 · 중요는 겹쳐 붙는다). 메일함으로 옮기는 규칙에 맞으면 거기서 멈춘다 — 아래 규칙은 보지 않는다. 받은편지함으로 옮기는 규칙을 위에 두면 "늘 받은편지함에"가 된다. 전달은 한 통에 한 곳 — 엔진 한도(사용자 스크립트의 리다이렉트 1)라 두 번째 전달은 엔진이 조용히 버린다(2026-10-28 확인). 사본은 늘 남긴다(redirect :copy). 스팸으로 판정된 메일에는 아무 규칙도 적용하지 않는다(부재중 응답도 하지 않는다) — 엔진은 규칙의 옮기기가 스팸메일함 분류를 이기므로(같은 날 확인) 막는다. 판정은 엔진의 분류 그대로다(지금 엔진 설정은 5점부터 스팸 — 아래 "만드는 Sieve"의 스팸 막기). 꺼 둔 규칙은 목록에만 있고 적용하지 않는다. 이미 받은 메일에는 적용하지 않는다.

• 저장 자리 — 엔진의 Sieve 스크립트 하나(arasystem)에 필터와 부재중 자동 응답을 함께 둔다. Stalwart 0.16.27 은 계정마다 켜진 스크립트가 하나뿐이고 엔진의 VacationResponse 도 스크립트(vacation)라서, 부재중을 켜면 필터가 꺼지고 필터를 켜면 부재중이 꺼진다(같은 날 확인).

  • 4단계 /api/mail-vacation 은 계약 그대로 두고 저장 자리만 이 스크립트로 옮긴다 — 엔진의 VacationResponse 는 더 쓰지 않는다. 스크립트가 아직 없는 계정은 처음 읽을 때 VacationResponse 의 값을 가져온다(개발 데이터 이어받기). 엔진의 vacation 스크립트는 고칠 수 없다(엔진이 forbidden).
  • 스크립트 머리의 주석에 규칙 · 부재중 원본(JSON — 판 번호 v 를 함께 둔다)을 두고, 읽을 때는 그것만 믿는다(엔진의 Sieve 를 다시 해석하지 않는다).
    • 스크립트가 아직 없으면 빈 규칙 + isActive: true, 부재중은 엔진의 VacationResponse 값(위 이어받기).
    • 스크립트는 있는데 원본이 없거나 깨졌으면 빈 규칙 + isActive: false, 부재중은 꺼짐 — 저장하면(필터든 부재중이든) 덮어쓴다.
    • 원본의 판이 이 서버가 아는 것보다 새로우면(새 서버를 배포했다 되돌린 경우) 읽기는 위와 같지만 쓰기는 거절한다(503 MAIL_001) — 옛 서버가 새 판의 규칙을 지우지 않게.
  • 쓸 때는 읽은 상태 그대로일 때만(ifInState) 쓰고 켠다(onSuccessActivateScript). 그사이 바뀌면 다시 읽어 확인한다 (쓰기 3번까지 — 시도마다 읽는 사이 글이 사라지면 그 읽기도 3번까지 다시 한다. 그래도 어긋나면 503 MAIL_001). 필터 저장은 다시 읽은 규칙의 지문이 version 과 다르면 409 MAIL_012(부재중 응답만 바뀐 것은 걸리지 않는다). 부재중 저장은 규칙을 그대로 두고 부재중 부분만 바꾼다. 다만 저장해 둔 규칙이 보내는 규칙과 이미 같으면 지문이 달라도 200 으로 저장한다 — 결과를 모르는 실패 뒤에 같은 요청을 다시 보낸 경우가 409 로 끝나지 않게 (꺼져 있었으면 이때 다시 켜진다).

• 만드는 Sieve (엔진 확인 사실 — 2026-10-28):

  • 조건: from → header :contains "from", to → header :contains ["to", "cc"], subject → header :contains "subject", body → body :text :contains. 한국어 제목(인코딩된 머리글) · 본문 · 표시 이름 모두 맞는다. 대소문자는 ASCII 만 무시한다(엔진 기본 비교 — i;unicode-casemap 은 없다).
  • 한 규칙은 if 하나: 표시(addflag — 옮기기보다 먼저, 엔진은 옮기는 순간의 표시만 붙인다) → 전달 → 옮기기(fileinto :mailboxid "<id>" "INBOX" + stop). 옮길 메일함이 없으면 대체 이름 "INBOX" 로 받은편지함에 들어온다.
  • 스팸 막기는 엔진의 분류 표시로 한다 — X-Spam-Score 머리글(spam, score=9.70 · ham, score=2.20)이 spam 으로 시작하면 아무 규칙도 · 부재중도 하지 않는다 (header :matches "X-Spam-Score" "spam*"). 엔진이 우리 스크립트를 돌리기 전에 붙인다. X-Spam-Status: Yes|No 는 스크립트가 끝난 뒤 실제로 들어간 곳에 따라 붙어 쓸 수 없다 (우리 규칙이 옮긴 스팸은 "No" 였다). 엔진 설정의 기준 점수(scoreSpam — 지금 5)를 바꿔도 이 표시가 따라간다.
    • spamtest 는 쓰지 않는다 — 엔진의 값은 "스팸이면 10"이 아니라 점수를 정수로 내린 값(10에서 멈춤)이라, 10 으로 막으면 5~10점 스팸을 놓친다 (2026-10-28 실엔진: 2.20점 → 2, 9.70점 → 10 미만, 11.2점 → 10. 처음 구현은 10 으로 막아 9.70점 스팸을 규칙대로 옮기고 부재중 응답까지 보냈다).
    • 바깥에서 같은 이름의 머리글을 넣어 와도 엔진의 머리글이 함께 남는다(하나라도 맞으면 참). 그래서 위조로 스팸을 숨길 수는 없고, 자기 메일에 규칙이 적용되지 않게만 할 수 있다 (그 메일은 엔진 판정대로 들어간다). 엔진의 스팸 필터는 바깥에서 오는(인증 없는) 메일에만 돌아 사내 메일에는 이 머리글이 없다 — 규칙이 그대로 적용된다.
  • 부재중: 엔진이 하던 대로 vacation :mime(본문 base64) — 제목은 RFC 2047 로 인코딩해 넣는다. Stalwart 는 require 와 상관없이 문자열의 ${…} 를 늘 변수로 펼쳐서 그대로 넣으면 지워진다(같은 날 확인). 기간은 currentdate :zone "+0000"(엔진 시간대에 기대지 않게 — 같은 날 확인). 같은 사람에게 다시 답하는 간격은 엔진 기본값(지금과 같다).
  • 규칙 값에 ${ 는 받지 않는다(400 VAL_001) — 펼쳐져 빈 값이 되면 :contains 가 모든 메일에 맞는다. 문자열은 " · \ 를 이스케이프한다. %{…}(Stalwart 의 식 모양)는 펼치지 않아 막지 않는다 — %{"a"} · %{} · %{1+1} · %{subject} 모두 글자 그대로 견주었다(같은 날 확인).
  • 크기: 엔진 한도는 스크립트 102,400바이트 · 문자열 4,096바이트다. 만든 스크립트가 90,000바이트를 넘으면 저장하지 않고 400 MAIL_013.

• 로그 — 규칙의 글(조건 값 · 전달 주소)은 남기지 않는다(검색어처럼 직원의 내용이다). 규칙 수 · 크기 · 결과만. 엔진이 스크립트를 거절하면(invalidScript → 500 SYS_001) 엔진 설명의 줄 · 칸만 남긴다 — 설명 문장에는 만난 문자열(규칙의 글)이 그대로 들어갈 수 있다.

• 클라이언트: 설정 › 메일 › 필터(/settings/mail/filters, 탭 제목 "메일 필터") — 메뉴는 서명 · 부재중 자동 응답 · 필터 · 알림.

  • 켜기 · 끄기 · 순서 바꾸기 · 지우기 · 고치기 모두 PUT 전체 교체(받은 version 으로). 켜기 · 순서는 화면을 먼저 바꾸고 실패하면 되돌린다(오류 알림). 지우기는 확인 없이 하고 알림의 되돌리기로 지운 필터를 지운 자리에 다시 넣어 저장한다 — 그사이 바꾼 다른 필터(켜기 · 순서 등)는 그대로 둔다. 저장은 한 번에 하나다 — 앞 저장이 도는 동안 누른 [되돌리기]는 차례로 보낸다. 고치기 창의 [저장]이 끝나면 "필터를 저장했습니다."
  • MAIL_012 — 목록 위 줄 "다른 곳에서 필터가 바뀌어 저장하지 않았습니다. 다시 불러온 뒤 고쳐 주세요." + [다시 불러오기]. 고치던 창은 닫지 않는다 — 창 안에도 같은 안내와 [다시 불러오기]를 둔다(모달이라 뒤의 줄을 누를 수 없다). 창에서 다시 불러오면 쓴 내용은 그대로이고, 다음 [저장]은 다시 받은 목록에 그 필터를 넣는다(같은 id 자리 — 그사이 다른 곳에서 지워졌으면 맨 아래).
  • isActive: false — 목록 위 줄 "지금은 필터와 부재중 자동 응답이 동작하지 않습니다…" + [다시 켜기](지금 목록 그대로 저장).
  • 읽기 화면 ⋯ 「이런 메일로 필터 만들기」 → /settings/mail/filters?from=<보낸 사람 주소> — 새 필터 창이 "보낸 사람 · 포함 · 그 주소"로 채워져 열린다(초점은 할 일의 첫 칸). 50개를 다 만들었는지 알려고 ⋯ 메뉴를 열 때 GET 을 한다(받아 둔 목록이 없거나 50개일 때만 — 알림 없이).
  • 검사는 서버와 같은 규칙(이름 50 · 값 200 · 조건 5 · 규칙 50 · ${ · 제어 문자 · 할 일 하나 이상 · 전달은 사내 주소이고 자기 주소 아님) — 칸 아래에만 알린다. 전달 주소의 앞부분은 서버(IsEmail)보다 좁게 본다(RFC 5322 dot-atom · 64자) — 화면이 통과시킨 주소를 서버가 거절하지 않게. 규칙이 50개면 [새 필터] · 「이런 메일로 필터 만들기」를 끄고 까닭을 보인다. 지운 메일함을 가리키는 규칙은 목록에 빨간 안내.

• 이 단계에서 하지 않는 것: 이미 받은 메일에 적용, 바깥 주소로 전달(엔진에 SRS 가 없어 Gmail 등이 DMARC 로 거절할 수 있고, 회사 메일이 개인 메일로 빠지는 통로다 — 필요해지면 정책과 함께), 크기 · 첨부 · 날짜 조건, 정규식, 맞는 메일 미리 보기, mailcow(SOGo)의 필터 옮겨 오기(운영 전환 때 — imapsync 로는 옮겨지지 않는다).

이 단계에서 하지 않는 것

탭을 모두 닫아도 오는 알림(웹 푸시 — 엔진은 webpush-vapid 를 지원한다), 알림 소리(운영체제 설정을 따른다), 휴대폰 푸시, 본문 안 이미지(인라인 cid — 붙여 넣은 이미지는 첨부로, 서명 그림만 예외), 외부 이미지 보기(이미지 중계), 여러 개의 서명, 엔진 계정 목록 기반의 사내 주소록, 자체 검색 색인(붙여 쓴 말 · 앞부분 · 제목 말머리로 찾기), 조건 검색(보낸 사람 · 기간 · 첨부 있음), 검색어 강조, 끌어다 놓아 옮기기, 메일함 옮기기(다른 상위로) · 하위 메일함까지 한꺼번에 지우기, 앱 비밀번호 · 2단계 인증(엔진은 지원한다), 부재중 응답의 서식 본문 · 사내/외부 구분, 인쇄.