
read receipts
플러스 기호 트릭이 보여주는 것과 보여주지 못하는 것—주소 유출 추적
태그가 붙은 주소는 스팸이 어느 가입에서 나왔는지 알려준다. 하지만 누가 유출했는지, 또는 누군가 판매했는지는 알려주지 않는다.
you+homedepot@example.com로 한 상점에 가입하고 you+ticketmaster@example.com으로 티켓 사이트에 가입하면, 태그를 제거하지 않는 한 도착하는 모든 메일에는 주소가 어느 양식에 입력되었는지를 알려주는 라벨이 붙는다. 그 태그 중 하나로 스팸이 들어오기 시작하면, 주소가 어디서 유출되었는지 추측하는 게 아니다. 봉투에서 직접 읽는 것이다.
이 메커니즘은 오래되었고 문서화되어 있다. 서브어드레싱(subaddressing)—보통 + 같은 구분자를 사용해 주소의 로컬 파트 뒤에 "상세정보"를 붙이는 것—은 2008년 1월 발표된 RFC 5233에서 설명되며, ken+sieve@example.org로 보낸 메일이 사용자 ken의 사서함에 도착하는 예시를 제시한다. Gmail은 자체 도움말에서 이 동작을 문서화하고 있다: "Gmail 별칭을 사용하여 필터링"이라는 항목 아래, "다음 별칭으로 전송된 메시지는 모두 janedoe@gmail.com으로 이동합니다"라고 명시한 후 janedoe+school@gmail.com, janedoe+notes@gmail.com, janedoe+important.emails@gmail.com을 나열한다. 하나의 사서함, 필요한 만큼 많은 태그가 붙은 변형, 별도의 설정 없음.
여기서부터는 이 글의 초판을 포함해 종종 과장되는 부분이다. 태그는 진입점을 식별한다. 범인을 식별하지 않는다. 정확히 한 상점에만 제공한 주소가 암호화폐 스팸을 받기 시작했다면, 확인된 것은 그 주소가 그 가입을 통해 광범위한 시장에 도달했다는 것이고, 이는 정말로 유용한 정보다. 하지만 어떻게 유출되었는지는 확인되지 않았다. 그 상점이 목록을 판매했을 수도, 자신의 개인정보보호정책이 허용하는 방식으로 공유했을 수도 있다. 처리자, 이행 파트너, 마케팅 플랫폼에 넘겼을 수도 있고, 그것이 침해당했을 수도 있다. 침해는 상점에서 발생했거나 그보다 세 단계 아래의 공급업체에서 발생했을 수 있다. 주소가 가입자 자신의 기기나 사서함에서 유출되었을 수 있다. 누군가 패턴을 추론했을 수도 있다—공격자가 you+petco@를 본 후 you+anything-else@ 형태를 추측하기는 어렵지 않으며, 태그는 전달된 메시지에서 직접 복사되기도 한다. "이 가입을 통해 유출되었다"는 결론은 타당하다. "이 회사가 나를 팔아넘겼다"는 다른 주장이며, 태그는 이에 대한 증거가 아니다.
이 트릭에는 두 가지 실질적인 제한이 있다. 첫 번째는 표준 자체에 있다: 상세정보가 인코딩되는 방식은 RFC 5233의 표현으로 "사이트 및/또는 구현에 따라 다르다." 주어진 제공자가 +를 지원한다거나 이를 구분자로 취급한다거나 주어진 가입 양식이 해당 문자를 받아들인다는 보장이 없다. 좁게 검증하는 주소 양식은 이를 거부하며, 나중에 주소를 처리하는 모든 것이 이를 제거할 수 있다. 두 번째는 태그가 문제가 된 후 할 수 있는 것이다. to: you+petco@…에 대한 필터는 그 메일이 받은편지함에 도착하는 것을 막는다. 하지만 누군가의 데이터베이스에서 주소를 제거하지 않으며, 주소가 더 거래되는 것을 막지도 않는다. 수신 측에서의 격리일 뿐, 그 이상 아니다.
수신거부는 그 오해의 다른 절반이다. 원클릭 수신거부는 호의가 아니다. 대량 발송자에게는 요구사항이다. Google의 발신자 지침은 하루에 5,000건 이상의 메시지를 Gmail 계정으로 보내는 발신자에게 "마케팅 메시지와 구독 메시지는 원클릭 수신거부를 지원해야 하며" "메시지 본문에 명확하게 보이는 수신거부 링크를 포함해야 하고," 스팸 비율을 "0.10% 미만"으로 유지하며 "0.30% 이상에 도달하지 말아야 한다"고 명시한다. Yahoo의 Sender Hub는 작동하는 List-Unsubscribe 헤더와 보이는 링크를 요구하며, 수신거부 요청은 이틀 내에 처리되어야 한다. 이는 메커니즘이 도달하는 범위를 정확히 보여준다: Gmail과 Yahoo에 메일을 전달하려는 발신자에 대해 시행된다. 애초에 준수할 의도가 없었던 발신자는 그 시스템 밖에 있으며, 정중하게 멈춰달라고 요청하는 것은 당신이 통제할 수 있는 수단이 아니다.
신뢰하지 않는 가입에 대해 Apple은 종종 혼동되는 두 가지를 제공한다. 첫 번째는 iCloud+ Hide My Email로, iCloud+ 구독이 필요하다: "iCloud+를 구독하면," "고유한 임의 이메일 주소를 생성할 수 있고," "무작위 주소로 전송된 메일은 개인 이메일 계정으로 전달되며," "필요한 만큼 많은 주소를 만들 수 있고," "더 이상 사용하지 않는 주소를 비활성화하거나 삭제할 수도 있다." 비활성화는 되돌릴 수 있지만 삭제는 Apple의 설명에 따르면 되돌릴 수 없다. 두 번째는 Sign in with Apple로, Apple Account로 앱에 로그인하면 자신의 주소를 넘겨주지 않고 privaterelay.appleid.com 도메인의 릴레이 주소를 발급할 수 있다. 해당 릴레이가 전달하는 주소를 변경하는 것 자체가 iCloud+ 기능이다. 둘 다 발신자에게 제거하거나 스크래핑할 수 있는 것을 넘겨주지 않는다. 왜냐하면 실제 주소에 붙은 보이는 태그가 없기 때문이다—하지만 이들은 서로 다른 기능이며 요구사항이 다르고, 이름으로 요청할 가치가 있다.
이 모든 것 뒤의 규모는 확인하기 쉽고 기억에서 인용하는 것보다는 확인하는 것이 가치 있다. Have I Been Pwned의 프론트페이지는 2026년 10월 20일에 읽었을 때 1,047개의 침해 사이트에 걸쳐 17,846,550,965개의 침해된 주소를 보여주었다. 이는 프로젝트가 로드한 침해에 나타나는 주소이며, 침해당한 계정도 아니고, 지금까지 발생한 모든 침해의 개수도 아니다. 태그 지정이 다음 침해에서 주소를 보호하지는 않는다. 그것이 하는 일은 무명의 홍수를 태그가 붙은 메일로 바꾸는 것이므로, 무언가 잘못되었을 때 어느 문으로 들어왔는지 알 수 있고—그리고 그것이 무엇을 증명하고 증명하지 않는지에 대해 솔직해질 수 있다.
정정, 2026년 10월 20일. 이 글의 이전 버전은 일인칭으로 작성되었으며 데이터 브로커 덤프에 나타나는 태그된 주소에 대한 개인적 관찰을 설명했다. 이 글은 식별된 개별 저자가 없으며—xmail이 조직으로 발행했으며—그 설명을 실증할 수 없었기 때문에 중립적이고 재현 가능한 시나리오로 다시 작성되었다. 태그된 주소가 "정확히 한 명의 용의자"를 남기고 주소를 판매한 회사의 이름을 밝힌다는 주장은 수정되었다: 태그는 진입점을 식별하지, 범인이나 거래를 식별하지 않는다. Gmail이 2008년 이후 플러스 주소 지정을 지원해 왔다는 진술은 제거되었다. Google의 문서는 시작 날짜를 제시하지 않기 때문이다. 2008년 날짜는 이제 관례가 지정된 RFC 5233을 가리킨다. Have I Been Pwned 수치는 이전에 수천 개의 침해에 걸쳐 14억 개 이상의 침해된 계정으로 제시되었으나, 2026년 10월 20일에 읽은 사이트 자체 카운터로 대체되었다. Apple의 릴레이 주소 설명은 iCloud+ Hide My Email과 Sign in with Apple로 나뉘었으며, 이는 요구사항이 다른 별도의 기능이고, Gmail의 동작에 대한 인용은 이제 실제로 이를 문서화하는 도움말 페이지를 가리킨다. 수신거부 링크가 종종 피싱 미끼라는 주장은 출처 부족으로 제거되었다.
출처
- Google — Send emails from a different address or alias — Gmail Help. "Filter using your Gmail alias": mail to [email protected] and similar aliases all goes to [email protected] (checked 20 October 2026)
- RFC 5233 — Sieve Email Filtering: Subaddress Extension — K. Murchison, January 2008. Defines subaddressing and the "+" separator, and notes that the encoding is site- and implementation-specific
- Apple — Create unique, random email addresses with Hide My Email and iCloud+ — Requires an iCloud+ subscription; random addresses forward to your personal account and can be deactivated or deleted
- Apple — Stop using, reactivate, or delete a Hide My Email address — Deactivated addresses can be reactivated; deleting an address is permanent
- Apple — How to use Hide My Email with Sign in with Apple — A separate feature: relay addresses in the privaterelay.appleid.com domain; changing the forwarding address requires iCloud+
- Google — Email sender guidelines — One-click unsubscribe and spam-rate requirements for senders of 5,000+ messages a day, in force from 1 February 2024 (checked 20 October 2026)
- Yahoo Sender Hub — Best practices — Working List-Unsubscribe header plus a visible link, with unsubscribe requests honoured within two days (checked 20 October 2026)
- Have I Been Pwned — Front-page counters: 1,047 pwned websites and 17,846,550,965 pwned addresses, read 20 October 2026