먼저 대조할 수 있는 한 줄입니다. 메일 화면의 자물쇠는 이 구간이 TLS를 썼다는 뜻뿐입니다. 서버를 떠난 뒤에도 본문이 암호문으로 남는다고는 적혀 있지 않습니다. 보낸 뒤, 버릴 수 있는 카나리아를 보낸편지함과 상대 받은편지함에서 검색하십시오. 원문이 맞으면 그 통은 아직 읽을 수 있는 보관입니다. 운영 키로는 시험하지 마십시오.
보내기는 「한 줄 알림」이 아닙니다. 평문을 보관 시스템에 넘기는 일입니다
업무 메일은 이 기기의 대화창처럼 보입니다. 글자는 아직 화면에 있고, 상대는 「보기만」 한다고 생각하기 쉽습니다. 보내기를 누르면 그 문단은 이미 이 탭을 떠났습니다. 이제 사업자가 배달하고, 색인을 만들고, 남겨야 하는 메시지입니다. 데이터베이스 비밀번호, 클라우드 액세스 키, GitHub 개인 액세스 토큰, 공유 Wi-Fi, 계정 복구 코드는 OWASP 로깅 치트시트가 공유 평문 기록에 두지 말라고 한 칸과 같습니다. 보낸편지함, 받은편지함, 임시보관함, 휴대폰 IMAP 사본은 회사 안에서 「비공식 키 저장소」가 되기 쉽습니다. 검색은 쉽고, 비밀번호 관리기보다 권한이 느슨하며, 보관은 더 깁니다.
HTTPS나 「이 메일은 암호화되었습니다」가 지키는 것은 전송 중의 도청입니다. 상대 사서함이 본문을 며칠 둘지, 관리자에게 검색을 줄지, 백업 디스크에 한 통이 더 있는지는 정하지 않습니다. 앞 글에서 모델 대화에 키를 붙이면 원문이 기록과 학습 쪽 사본에 들어갈 수 있다고 썼습니다. 메일로 비밀을 보내는 일은 같은 종류의 노출입니다. 받는 쪽만 「모델 사업자」에서 「적어도 두 곳의 메일 보관과 중간의 중계」로 바뀝니다. 보내기 전에 물을 것은 「이 클라이언트가 똑똑한가」가 아닙니다. 「이 문단에, 검색되는 메일 본문으로 두면 안 되는 비밀이 있는가」입니다.
이 글은 Gmail, Exchange Online, Google Vault, Microsoft Purview를 주로 봅니다. 보관 일수와 관리자 검색 범위가 공개 도움말에 숫자로 적혀 있기 때문입니다. 직접 돌리는 Postfix나, 네이버 메일, 회사 호스팅 메일도 저장 후 전달입니다. 제품을 바꾸면 그 삭제와 보관 페이지를 다시 걷십시오. 아래의 휴지통 약 30일과 복구 가능 항목 기본 14일을 다른 서비스에 그대로 옮기지 마십시오.
KISA 암호이용 FAQ는 개인정보보호법을 들어, 비밀번호는 저장되거나 정보통신망으로 주고받을 때 반드시 암호화해야 한다고 적습니다. 메일 작성창에 평문 비밀번호를 넣는 습관은 그 선과 맞지 않습니다. 「자물쇠가 켜져 있으니 암호화했다」로 이 의무를 덮을 수는 없습니다. 전송 구간의 TLS와, 본문 자체의 암호화는 다른 층입니다.
자물쇠와 STARTTLS가 지키는 것은 한 구간이지, 종단 간이 아닙니다
브라우저나 메일 화면의 자물쇠는 「상대까지 처음부터 끝까지 암호화되었다」로 읽히기 쉽습니다. SMTP의 전송 암호화는 그렇게 움직이지 않습니다. RFC 3207 제6절은 단정합니다. SMTP는 종단 간 구조가 아닙니다. 한 쌍의 SMTP 클라이언트와 서버가 TLS를 쓰기로 해도, 보내는 사람의 메일 프로그램부터 받는 사람까지 지킨 것은 아닙니다. 한 통은 SMTP 서버 두 대 이상을 지날 수 있습니다. 한 쌍의 TLS는 배달 길 전체를 비밀로 만들지 않습니다.
그래서 겉보기와 어긋난 현장이 나옵니다. 이 기기에서 회사 출구 게이트까지는 TLS, 게이트에서 상대 MX까지도 STARTTLS. 그런데 각 구간이 끝나면 중계는 봉투를 읽고, 스팸을 가르고, 다음으로 넘기기 위해 메시지를 엽니다. 그 디스크의 본문은 기본으로 읽을 수 있습니다. 「중간에 아무도 못 읽는다」가 필요하면 S/MIME이나 OpenPGP 같은 내용 암호화이며, 전송 자물쇠가 아닙니다. 업무 작성창에 적는 비밀번호가 이 층을 타는 일은 거의 없습니다.
IMAP과 휴대폰 클라이언트는 한 장을 더 복제합니다. 메일은 웹 탭에서 흘려보는 통로가 아닙니다. 서버 위의 객체 보관입니다. 받은편지함, 보낸편지함, 임시보관함, 휴지통은 각각 객체입니다. 이미 로그인한 다른 PC, 지급받은 휴대폰, 데스크톱의 오프라인 캐시는 같은 평문을 읽을 수 있습니다. 전송 암호화가 막는 것은 선로의 옆사람입니다. 이미 보관에 들어간 사본은 막지 않습니다.
보낸편지함과 받은편지함: 보내는 순간에 읽을 수 있는 사본은 적어도 두 장
보낸 뒤, 삭제 이야기 전에 장수를 세십시오. 첫 장은 이쪽입니다. Gmail의 「보낸편지함」, Outlook의 「보낸 편지함」, 많은 IMAP의 Sent입니다. 브라우저의 실행 취소 버퍼가 아닙니다. 보관에 쓴 정식 객체입니다. 두 달 뒤에도 그 비밀번호를 검색할 수 있습니다. 그 사서함을 검색할 수 있는 관리자도 할 수 있습니다. 둘째 장은 상대쪽입니다. 받은편지함과, 「모든 메일」이나 보관함으로 치운 한 통입니다. 둘 다 본문입니다. 「제목만」이 아닙니다.
참조와 숨은참조는 장수를 늘립니다. 프로젝트 전원에게 참조를 넣으면 각자의 받은편지함에 한 장씩 남습니다. 숨은참조가 가리는 것은 다른 수신자에게 보이는 주소이지, 보관 장수가 아닙니다. 자동 전달, 저널링, 「카카오톡이나 협업 도구에도 보내기」 게이트웨이는 메일 제품 밖으로 한 장을 더 떨어뜨릴 수 있습니다. 이 사본들은 삭제 버튼을 공유하지 않습니다. 내 보낸편지함을 비워도 상대 받은편지함은 움직이지 않습니다. 게이트웨이가 이미 쓴 한 장도 움직이지 않습니다.
국내 현장에서는 암호 걸린 ZIP을 한 통, 푸는 비밀번호를 다른 통으로 보내는 습관이 아직 있습니다. 같은 잘못된 주소로 두 통이 가면 분리는 의미가 없습니다. 이 글이 더하는 것은 그 다음입니다. 두 번째 비밀번호 메일 자체가 본문에 평문을 남깁니다. 보낸편지함과 받은편지함에, 푸는 문자열이 검색되는 객체로 남습니다. ZIP 쪽에 남는 것은 암호 걸린 ZIP의 기본 암호화·파일명·암호화하지 않은 항목입니다. 여기서는 둘째 통의 본문이 메일 보관에 들어갔다는 사실만 셉니다.
검색창이 증거입니다. Gmail, Outlook, 네이버 메일 같은 웹메일은 본문을 색인합니다. 카나리아를 검색에 넣으십시오. 맞으면 그 사서함을 가진 사람에게는 읽을 수 있습니다. 클라우드의 중복 제거 해시나 클립보드 기록과 같은 종류의 잔여입니다. 제품이 평문을 남기는 이유는 검색이 편해서이지, 비밀을 잊게 하기 위해서가 아닙니다.
| 위치 | 보통 아직 남는 것 | 아직 읽을 수 있는 사람 |
|---|---|---|
| 보내는 사람의 보낸편지함 | 본문과 첨부 전체 | 보내는 사람. 그 사서함 권한을 가진 사람 |
| 받는 사람의 받은편지함 / 모든 메일 | 같은 본문 전체 | 받는 사람. 동기화된 기기 |
| 중계 SMTP 서버 | 배달 중의 읽을 수 있는 메시지 | 그 구간의 운영과 필터 |
| 휴지통 / 복구 가능 항목 | 삭제 뒤에도 되돌릴 수 있는 본문 | 본인. 기한이 끝나기 전의 복원 화면 |
| 기업 보관 / Vault / 전자증거개시 | 정책으로 남기는, 검색되는 사본 | 보관 또는 규정 준수 관리자 |
양쪽이 지워도, 유예는 대개 아직 남아 있습니다
「나도 지웠고, 상대도 지웠다」는 비밀이 돌아왔다고 들리기 쉽습니다. 각사가 쓰는 삭제 길은 더 깁니다. Gmail 삭제 도움말은, 삭제한 메일은 휴지통으로 들어가고, 이후 최대 약 30일은 휴지통에서 찾아 받은편지함으로 되돌리거나 완전히 삭제할 수 있다고 적습니다. 30일이 지나면 계정에서 완전히 삭제되며 휴지통에서는 되돌릴 수 없습니다. 보관함으로 치우기는 삭제가 아닙니다. 받은편지함에서 빼는 것뿐입니다. 「모든 메일」 검색은 아직 맞습니다.
Google Workspace는 이용자 쪽 기한 뒤에 관리자 유예를 더합니다. Workspace 복원 도움말은, 휴지통 30일이 끝난 뒤 관리자는 관리 콘솔에서 메일을 약 25일 더 복원할 수 있다고 적습니다. 이 약 25일은 삭제로부터 30일 뒤에 시작합니다. 보낸 날이나 받은 날이 아닙니다. 끝나면 Workspace 계정에서 완전히 삭제되며 관리자도 Google도 되돌릴 수 없다고 적혀 있습니다. Vault의 보관과 보존 조치는 이 복원 버튼 밖입니다. 다른 사본입니다.
Exchange Online은 「사라졌다」 뒤에 숨은 폴더를 둡니다. Microsoft의 영구 삭제 항목 설명은, 지운 편지함에서 한 번 더 지우거나, 지운 편지함을 비우거나, Shift+Delete로 영구 삭제하면 객체가 복구 가능 항목의 「삭제」로 옮겨지고 기본 14일 남는다고 적습니다. 관리자는 최장 30일까지 늘릴 수 있습니다. 이용자는 Outlook의 「삭제된 항목 복구」로 되돌릴 수 있습니다. 사서함에 소송 보존이 걸려 있으면 이 보관 기한은 무시되고, 14일로 청소되지 않습니다.
보내기 취소는 이미 나간 비밀을 회수하지 않습니다. Gmail의 보내기 취소가 주는 것은 5, 10, 20, 또는 30초의 취소 창입니다. 진짜 배달을 늦춥니다. 상대 서버에서 본문을 파내 오지 않습니다. 창이 지나면 평범한 보낸편지함입니다. Outlook의 메시지 회수는 특정 Exchange 조직 안에서, 상대가 아직 읽지 않았을 때에만 될 수 있습니다. 만능 회수 버튼이 아닙니다.
회사 보관과 관리자 검색은 다른 사본이며, 이용자는 지우지 못합니다
개인 휴지통의 시계와 회사 규정 준수 보관은 같은 스위치가 아닙니다. Google Workspace의 Vault Gmail 검색은 본문과 첨부의 키워드 검색으로 만들어져 있습니다. Google은 메시지 본문과 첨부를 합쳐 처음 약 1MB를 색인한다고 적습니다. 관리자는 미리보기, 인쇄, 첨부 다운로드를 할 수 있습니다. 임시보관함과 자동 저장된 초안도 범위입니다. 기본 보관 규칙이 있으면 이용자가 휴지통을 비운 뒤에도 검색할 수 있습니다. 제품의 일은 「직원이 지운 뒤에도 찾는 것」입니다.
Microsoft Purview의 전자증거개시도 사서함을 같은 방향으로 다룹니다. 사서함 콘텐츠 검색은 키워드를 쓸 때 제목, 본문, 참여자에 관한 많은 속성을 넣는다고 적습니다. 색인되는 속성에는 주고받은 날짜, 보낸 사람과 받는 사람, 첨부 파일명, 본문 텍스트가 있습니다. 설계 목표는 「이용자가 삭제를 누른 뒤에도 찾는다」이지, 「보낸 사람의 후회를 존중한다」가 아닙니다.
그래서 「우리 둘만 안다」는 회사 메일에서 대개 성립하지 않습니다. Vault를 여는 사람, 전자증거개시를 돌리는 사람, 사서함을 내보내는 사람은 직무로 그 비밀번호를 읽을 수 있습니다. 어떤 사업자가 취미로 엿본다는 주장이 아닙니다. 도움말이 적는 권한입니다. 개인 Gmail에는 Workspace 관리자가 없습니다. 그래도 이미 로그인한 PC 앞에 앉은 사람에게는 보낸편지함의 평문을 읽을 수 있습니다. 네이버웍스나 다른 회사 메일을 쓰면, 그 제품의 보관·감사 페이지를 따로 걷으십시오. 아래 숫자를 옮기지 마십시오.
비밀 모드가 막는 것은 잘못 전달이지, 보관과 스크린샷이 아닙니다
Gmail 비밀 모드는 「한 번 읽으면 사라지는 메일」로 쓰이기 쉽습니다. 공식 범위는 더 좁습니다. Gmail 비밀 모드는 만료일을 넣고, 나중에 액세스를 취소하고, 전달·복사·인쇄·다운로드를 끄고, SMS 코드를 요구할 수 있다고 적습니다. 같은 페이지는 받는 사람이 스크린샷이나 사진을 찍을 수 있고, 악성 프로그램이 있는 받는 사람은 복사나 다운로드를 할 수 있다고 적습니다. Workspace 쪽 구현도 분명합니다. 받는 사람 한 통에서 본문과 첨부를 빼고, 내용으로 가는 링크로 바꿉니다. SMTP로 나가는 것은 주로 제목과 그 링크입니다.
만료나 취소는 받는 사람에게 본문을 닫을 수 있습니다. 보내는 쪽 조직 안의 사본은 지우지 않습니다. Vault가 지원하는 데이터는, 조직이 이 기능을 켜 두면 2018년 11월 30일 이후 조직 이용자가 보낸 비밀 모드 메일을 Vault가 보존 조치, 보관, 검색, 내보낼 수 있다고 적습니다. 발신자가 만료일을 넣거나 받는 사람의 액세스를 취소해도 Vault는 그 메일을 다룰 수 있습니다. 검색은 label:confidentialmode입니다. 미리보기에서는 내용이 기본으로 숨고, 조작자가 표시를 고를 수 있습니다. 태운 것이 아닙니다. 받는 사람에게는 문을 닫고, 규정 준수 입구에는 문을 열어 둔 것입니다.
따라서 비밀 모드는 잘못 전달을 줄이는 제어입니다. 한 번만 쓰는 키의 통로가 아닙니다. 본문을 맡는 곳은 같은 메일 사업자입니다. 제목은 평범한 SMTP를 탑니다. 스크린샷은 Google 자신의 페이지가 대상 밖입니다. 목표가 「서버는 암호문만 가지고, 정한 횟수로 지우고, 키는 HTTP에 들어가지 않는다」라면 그것은 다른 분할입니다. 같은 한 통에 비밀 표시를 붙인 일이 아닙니다.
운영 비밀번호, 운영 API 키, 가리지 않은 연결 문자열로는 시험하지 마십시오. 버릴 수 있는 카나리아, 예를 들어 canary-mail-2026-do-not-reuse를 쓰십시오. 확인할 것은 보낸편지함과 검색 적중이지, 진짜 비밀을 한 번 더 퍼뜨리는 일이 아닙니다. 이미 메일로 보낸 실제 키는 먼저 발급처에서 폐기한 뒤, 다음 전달 방법을 바꾸십시오.
바로 확인하기: 카나리아는 시험 계정에만 넣고, 보낸편지함을 검색하십시오
「이 메일은 암호화되었습니다」라는 문구는 스스로 증명하지 못합니다. 그 자리에서 보이는 것은 넷입니다. 보낸편지함에 원문이 있는가, 받는 쪽 시험함에 원문이 있는가, 삭제 뒤 휴지통이나 복구 가능 항목에 아직 있는가, 자물쇠를 「서버도 못 읽는다」로 오해하지 않았는가. 이 절차가 증명하는 것은 이 시험 메일이 남긴 읽을 수 있는 사본입니다. 어떤 사업자의 보관 방침은 증명하지 않습니다. 그쪽은 공식 도움말과의 대조뿐입니다. Network가 그 자리를 대신하지 않습니다.
직접 다루는 시험용 사서함 두 개를 준비하십시오. 운영 주소록은 쓰지 마십시오. 실제 비밀번호와 겹치지 않고, 한눈에 알아보는 카나리아를 쓰십시오. 예는 canary-mail-2026-do-not-reuse입니다. 제목은 평범한 알림으로 두십시오. 본문에는 카나리아만. 주민등록번호나 실제 호스트 이름은 넣지 마십시오. 보낸 직후 보내는 계정에서 그 문자열을 검색합니다. 보낸편지함이 맞아야 합니다. 받는 쪽 시험 계정에 들어가 다시 검색합니다. 받은편지함도 맞아야 합니다. 두 곳이 맞으면 적어도 두 장의 평문입니다. 보내는 쪽 한 통을 휴지통에 넣으십시오. 30일 안에 휴지통을 엽니다. Gmail이라면 아직 있어야 합니다. 삭제가 회수가 아니라는 증거입니다.
키가 HTTP에 들어갔는지를 볼 때는 키를 메일에 쓰지 마십시오. 일회용 링크로 바꾸십시오. 만든 뒤 주소창은 s.html?id=와 # 뒤의 키입니다. 개발자 도구의 Network를 엽니다. 요청 줄에 나오는 것은 번호뿐입니다. 해시 뒤는 나오지 않아야 합니다. 이 대조가 증명하는 것은 링크 형태입니다. 메일 본문에 대해서는 아무것도 증명하지 않습니다. 본문이 나간 뒤 Network는 이미 들어간 보관을 되돌리지 못합니다.
- 시험용 두 함에서 본문에 카나리아만 넣어 보냅니다. 예는
canary-mail-2026-do-not-reuse. 실제 키는 쓰지 않습니다. - 보내는 쪽 보낸편지함과 받는 쪽 받은편지함에서 그 문자열을 검색합니다. 양쪽이 맞아야 합니다.
- 보내는 쪽을 지우고, 휴지통 또는 「삭제된 항목 복구」를 열어 기한 안에 아직 있는지 확인합니다.
- 실제 키를 사람에게 줄 때는 일회용 링크로 바꿉니다. 메일은 키가 없는 알림이나, 이미 암호화한 첨부만 씁니다.
증명 범위는 좁습니다. 이번 한 번에 평문이 메일 본문으로 적어도 두 보관에 들어갔고, 삭제는 보내는 쪽 사본을 바로 지우지 않았습니다. 확장 프로그램이 셋째 장을 남기지 않았다는 것은 증명하지 않습니다. 상대 회사가 Vault를 켰는지도 증명하지 않습니다. 메일 제품을 바꾸면 그 삭제와 보관 페이지를 향해 카나리아를 한 번 더 돌리십시오.
열자마자 쓰는 일회용 링크로, 알림과 키를 나누십시오
「본문을 메일 보관에 넣지 않기」를 반복할 수 있는 동작으로 만들려면 MakePwd의 일회용 링크부터 넣으십시오. 열자마자 쓰며 가입과 로그인이 필요 없습니다. 평문은 만드는 쪽 탭에만 나옵니다. 브라우저는 Web Crypto로 AES-256-GCM을 씁니다. 밖으로 나가는 칸은 암호문, 기한, 읽기 횟수입니다. 서버는 암호문만 잠시 두고 번호를 돌려줍니다. 페이지는 키를 프래그먼트에 붙입니다. s.html?id={번호}#{키}입니다. RFC 9110에서 대상 URI에는 프래그먼트가 들어가지 않습니다. 요청 줄에 해시 뒤는 나오지 않아야 합니다.
연습은 카나리아만 쓰십시오. 버릴 수 있는 문구를 만들고, 전체 링크를 시험 상대에게 보내며, 메일 본문에는 「링크를 여십시오. 해시를 포함한 문자열은 전달하지 마십시오」만 쓰십시오. 상대가 확인하고 가져간 뒤, 같은 번호를 열면 다시 읽을 수 있는 본문이 아니라 이미 소각된 상태가 되어야 합니다. 채팅이나 메일에 파란 링크는 남습니다. 그것은 위치를 가리키는 표입니다. 암호문이 정한 횟수로 지워진 뒤 그 문자열은 아무것도 열지 못합니다. 자세한 내용은 일회용 링크를 한 번 읽은 뒤, 서버에 남는 것은 무엇인가와 URL의 # 뒤에 키를 두기 좋은 이유, 그리고 이 보호가 깨지는 순간입니다.
키가 들어 있는 파일 묶음을 「암호 걸린 ZIP을 첨부」로 되돌리지 마십시오. 파일 암호화는 지금 탭에서 AES-256-GCM으로 .lock / .enc를 만듭니다. 단일 파일은 5GB까지입니다. 암호문은 메일이나 드라이브를 탈 수 있습니다. 암호 문구는 다른 길입니다. 이미 메일로 보낸 로그인 비밀번호는 먼저 발급처에서 폐기하고, 비밀번호 생성기로 이 기기에서 6–128자의 새 열을 뽑으십시오. 기본은 16입니다. 8 미만은 약하다고 나옵니다. 이 절차에는 로그인이 필요 없습니다.
자주 묻는 질문
메일이 HTTPS면 비밀번호는 받는 사람만 봅니까?
아닙니다. RFC 3207은 SMTP가 종단 간 구조가 아니라고 적습니다. 한 쌍의 서버가 TLS를 켜도, 보내는 클라이언트부터 받는 사람까지 지킨 것은 아닙니다. 각 구간은 풀어 보고 다음으로 넘길 수 있습니다. 보낸편지함, 받은편지함, 서버 디스크의 보관은 기본으로 읽을 수 있는 본문입니다.
양쪽이 이 메일을 지우면 비밀번호는 사라집니까?
남을 수 있습니다. Gmail은 삭제를 휴지통으로 옮기고 약 30일은 되돌릴 수 있습니다. Exchange Online은 영구 삭제 뒤 복구 가능 항목에 기본 14일, 최장 30일을 둡니다. Workspace 관리자는 휴지통 30일 뒤에 관리 콘솔에서 약 25일을 더 복원할 수 있습니다. 소송 보존은 이 시계를 무시합니다. 조직이 보관을 켜 두면 관리자는 본문을 검색하고 내보낼 수 있습니다.
Gmail 비밀 모드가 끝나면 본문은 시스템에서 사라집니까?
받는 사람은 만료나 액세스 취소 뒤에 본문을 열지 못합니다. 보내는 쪽 조직의 Vault에 대해 Google 한국어 도움말은, 사용자가 만료일을 넣거나 받는 사람의 액세스를 취소해도 Vault는 조직 안에서 보낸 그 메일을 보존·검색·내보낼 수 있다고 적습니다. 스크린샷과 촬영은 같은 제품 설명의 밖입니다.
동료에게 비밀번호를 줘야 할 때 메일은 아직 쓸 수 있습니까?
메일은 키가 없는 알림이나, 이미 암호문이 된 첨부용입니다. 실제 비밀번호는 일회용 링크로 한 번 보내고, 키는 URL의 # 프래그먼트에 두십시오. 만들기와 읽기 모두 열자마자 쓰며, 서버가 잠시 두는 것은 암호문뿐입니다. 같은 평문을 메일 본문에 다시 쓰지 마십시오.
다음 메일을 쓰기 전에 기억할 세 가지
첫째, 보내기는 디스크에 쓰는 일입니다. 보낸편지함, 받은편지함, 동기화된 기기, 중계는 각각 읽을 수 있는 본문을 가질 수 있습니다. 지금 페이지를 고쳐도 이미 들어간 사본은 돌아오지 않습니다. 둘째, 삭제는 유예를 시작할 뿐입니다. Gmail 휴지통은 약 30일, Exchange 복구 가능 항목은 기본 14일, Workspace 관리자는 휴지통 뒤에 약 25일을 가질 수 있습니다. 회사 보관과 Vault는 다른 세트이며 이용자는 지우지 못합니다. 셋째, 비밀 모드와 보내기 취소가 막는 것은 실수입니다. 종단 간이 아닙니다. 전해져야 하는 실제 키는 일회용 링크로. 새어 나간 비밀번호는 먼저 폐기한 뒤 바꿉니다.
한 번 읽은 뒤 서버에 남는 것을 이어서 보려면 일회용 링크를 한 번 읽은 뒤, 서버에 남는 것은 무엇인가를 읽으십시오. 해시 뒤의 키가 HTTP에 들어가는지를 대조하려면 URL의 # 뒤에 키를 두기 좋은 이유, 그리고 이 보호가 깨지는 순간을 읽으십시오. 본문이 다루는 것은 「비밀번호를 메일 본문에 쓴 뒤, 보낸편지함·백업·관리자 쪽에 아직 무엇이 남는가」를 결론에 적을 수 있는 선으로 내리는 일뿐입니다.