일회용 받은편지함

호출자는 이 설치본이 소유한 도메인의 주소를 요청해 몇 분간 지켜보고, 도착한 것을 읽고, 버립니다. 확인 코드, "이 폼이 실제로 무엇을 보내는가"라는 질문, 그리고 5년 뒤에도 쓸 주소에 엮고 싶지 않은 가입을 위해 존재합니다.

• —받기만 하고 그 외에는 아무것도 하지 않습니다. 발송은 없습니다. 받은편지함에는 보낼 신원이 없고, 이 아홉 개 호출 중 어느 것도 메시지를 내보내지 않습니다.
• —기본 임대 시간은 60분이며, 한 시간씩 24시간까지 늘릴 수 있습니다.
• —메시지 50개를 담으며 도착할 때마다 셉니다. 가득 찬 받은편지함에 도착한 메일은 큐에 쌓이지 않고 버려지며, 하나를 삭제해도 자리가 생기지 않습니다.
• —임대가 끝나면 메일은 삭제됩니다. 숨기는 것도 보관하는 것도 아닙니다. 행은 일주일 더 남는데, 느린 발신자가 아직 재시도하는 동안 주소가 다시 발급되지 않게 하기 위해서입니다.
• —이 중 어느 것도 메일함에 닿지 않습니다. 일회용 메시지는 자체 테이블에 있고, 이 경로의 어떤 쿼리도 실제 메일함에 닿을 수 없습니다.

일회용 주소는 발급되는 순간 가입 폼에 입력됩니다. 거기서부터 To: 헤더를 타고, 발신자의 로그를 거쳐, 반대편에 있는 CRM으로 들어갑니다. 주소를 아는 것만으로 메일을 읽을 수 있다면 이 도구는 설계상 발급한 모든 받은편지함을 유출하게 되고, 그것도 호출자가 거리를 두려던 바로 그 상대에게 유출하게 됩니다.

그래서 받은편지함을 만들면 두 번째 값이 함께 돌아옵니다. token이며, 32바이트 난수를 oe_inbox_에 base64url 43자를 붙인 형태로 표현한 것입니다. 그 한 번의 응답에만 나타나고 다른 어디에도 나타나지 않습니다. 행에는 키가 적용된 해시만 남으므로, 지원 요청으로도 데이터베이스 덤프로도 복구할 수 없습니다. 토큰을 잃으면 받은편지함을 잃은 것이며, 남의 메일을 읽는 자격 증명에는 그것이 올바른 결과입니다.

# 1. Mint one. This is the only response that carries a token.curl -s -X POST "$OE/temp-mail/inboxes" -H "Content-Type: application/json" -d '{}' # 2. Keep it, and read with it.export INBOX="Authorization: Bearer oe_inbox_kQ8v…"curl -s "$OE/temp-mail/inboxes/tinb_9c2f…/messages" -H "$INBOX"

이 장르의 이름이 된 10분이 아니라 한 시간입니다. 10분은 확인 코드에는 충분하지만, 이것들이 쓰이는 나머지 절반에는 모자랍니다. 다음 날 아침에 다시 메일을 보내는 체험판이나, 첫 시도가 타임아웃돼 두 번 작성한 폼 같은 경우입니다. 생성 시 ttlMinutes로 1부터 1440까지 다른 값을 요청할 수 있습니다. 범위를 벗어난 숫자는 조용히 조정되지 않고 422로 거부됩니다. 요청하지 않은 만료 시각은 이미 계획에 반영해 버린 시각이기 때문입니다.

POST /temp-mail/inboxes/{id}/extend는 지금이 아니라 만료 시각에 한 시간을 더하므로, 일찍 연장해도 남은 시간을 낭비하지 않습니다. 23번까지 동작하며, 두 상한 중에서는 받은편지함이 생성된 순간부터의 하루가 더 빡빡합니다. 이미 거기까지 도달한 임대는 연장을 아무리 적게 썼더라도 더 살 시간이 없습니다. 모든 받은편지함 응답의 extensionsLeft가 둘 다 반영해 세므로 클라이언트가 버튼을 비활성화할 수 있고, 0이면 호출은 409 extension_limit으로 답합니다.

이 모두는 레이트 리미터가 아니라 카운트된 행입니다. 이 코드베이스에는 쓸 수 있는 리미터가 없고, 있지도 않은 방어를 암시하는 것보다 그렇게 말하는 편이 쓸모 있습니다. 상한은 피해가 생길 자리, 즉 발급과 저장에 놓여 있습니다.

해 보고 알게 되는 것보다 미리 듣는 편이 낫습니다:

• —어떤 형태로도 발송은 없습니다. 일회용 받은편지함에는 보낼 연결이 없고, 하나를 붙이면 익명의 인증되지 않은 엔드포인트가 오픈 릴레이가 됩니다.
• —이름 변경은 없습니다. 주소를 바꾸려면 두 번째 받은편지함을 만들어야 합니다. 제자리에서 이름을 바꾸면 누른 즉시 예전 로컬 파트가 풀리고, 이미 전송 중이던 확인 메일이 다음에 그것을 발급받은 사람에게 전달될 것입니다.
• —규칙, 필터, 전달, 웹훅, AI는 없습니다. spam은 메시지에 붙은 플래그일 뿐 아무것도 그에 따라 행동하지 않았습니다. 아무것도 정리해 넣지 않았고, 여기서 요약되거나 임베딩되는 것도 없습니다.
• —반송은 없습니다. 풀 도메인으로 온 메일 중 살아 있는 일회용 받은편지함도, 운영자가 만든 주소도 가리키지 않는 것은 일부러 조용히 버립니다. 공개된 주소 생성기는 사전 공격을 끌어들이는데, 공격이 주장하는 반환 경로로 전달 보고서를 쓰면 이 설치본이 백스캐터 발신원이 됩니다.
• —도메인이 설정되어 있지 않으면 서비스도 없습니다. TEMP_MAIL_DOMAINS가 비어 있으면 GET /temp-mail/domains는 빈 목록으로 답하고 받은편지함 생성은 503 temp_mail_unavailable로 답합니다. 풀 도메인으로의 수신 전달은 실제 도메인에서 처음부터 끝까지 확인된 적이 없습니다.

목록은 설정입니다. TEMP_MAIL_DOMAINS가 지정한 것이 곧 나눠주는 것입니다. DNS를 자동화하는 것은 없으므로, 다섯 단계 중 넷은 사람이 등록기관에서 해야 합니다.

1. 1이 용도의 도메인을 등록하십시오. 낯선 사람들에게 나눠줘도 되는 도메인을 쓰십시오. 그 도메인의 모든 주소가 평판을 공유하며, 그래서 선택기는 첫 도메인을 채우는 대신 새 받은편지함을 풀 전체에 무작위로 퍼뜨립니다.
2. 2앱의 설정 → 도메인에서 추가하십시오. 그러면 발송 신원이 생성되고 게시할 DNS 레코드가 표시됩니다.
3. 3MX, SPF, DKIM, _openemail-challenge TXT 레코드를 등록기관에 게시하십시오. 검증은 실시간 DNS를 읽고 크론에서 다시 확인하며, 검증된 도메인만 제공됩니다.
4. 4검증된 도메인을 서버의 TEMP_MAIL_DOMAINS에 쉼표로 구분해 추가하십시오. 목록에 오르기 전까지는 워크스페이스의 평범한 도메인일 뿐입니다.
5. 5catch-all을 켜 두십시오. 일회용 주소를 만들지 않고도 존재하게 하는 것이 바로 이것입니다. 어떤 로컬 파트로 온 메일이든 일반적인 수신자 조회보다 먼저 받아들여 되읽기 때문에, 풀 도메인에는 주소 행이 전혀 쓰이지 않습니다. catch-all을 켜 두면 일회용 메일이 실제 메일함에 분류되기 시작합니다.