이메일 주소 심층 분석

• 이메일 주소는 단순한 사용자명과 도메인의 조합이 아니라, RFC 표준에 정의된 복잡한 구조와 규칙, 보안 함정을 포함하는 체계
• 로컬 파트(@ 앞)에는 따옴표 형식, 주석, 유니코드 등 일반적으로 알려지지 않은 다양한 유효 형식이 존재하며, 대부분의 실무 환경에서는 지원되지 않음
• 모든 이메일에는 Envelope Sender와 From 헤더라는 두 개의 발신자 주소가 존재하며, 이 차이가 스푸핑과 피싱의 근본 원인
• Gmail의 점(dot) 무시 정책, 플러스 주소 지정, 도메인 별칭 등 제공자별 고유 동작이 보안 및 유효성 검사에 직접적 영향
• 이메일 주소를 수집하거나 검증하는 시스템을 구축할 때, RFC 표준과 실제 동작 간의 간극을 정확히 이해하는 것이 필수적

---

기본 구조

• 이메일 주소는 로컬 파트(@ 앞), @ 구분자, 도메인(@ 뒤)의 세 부분으로 구성
• 겉보기에 단순하지만, 각 부분에는 보안·프라이버시·유효성 검사에 영향을 미치는 규칙과 엣지 케이스가 존재

로컬 파트 (Local Part)

• 허용 문자

  • 표준 비따옴표 형식(dot-atom)에서 허용되는 문자: 영문자 a-z, A-Z, 숫자 0-9, 특수문자 . _ - + ! # $ % & ' * / = ? ^ { | } ~
  • 최대 길이는 64 옥텟(octet)이며, 표준 ASCII에서는 64자와 동일하지만 유니코드 로컬 파트에서는 차이 발생
    • 옥텟은 정확히 8비트 그룹을 의미하며, 네트워킹(IPv4)에서 0~255 범위를 표현하는 데 사용
    • 64 옥텟은 512비트 길이의 데이터 블록에 해당

• 대소문자 구분

  • RFC 5321에 따르면 로컬 파트는 기술적으로 대소문자를 구분하며, [e-mail]과 [e-mail]은 별도의 메일박스가 될 수 있음
  • 실제로는 모든 주요 이메일 제공자가 대소문자를 구분하지 않으므로, 저장·비교 전 소문자로 정규화하는 것이 안전한 기본값
  • 도메인 파트는 항상 대소문자를 구분하지 않음

• 점(Dot) 주소 지정

  • 점은 로컬 파트에 허용되지만 세 가지 제한 존재: 점으로 시작 불가, 점으로 끝 불가, 연속 점 불가
  • Gmail의 점 정규화: Gmail은 로컬 파트에서 점을 완전히 무시하므로, [e-mail], [e-mail], [e-mail]이 모두 동일 수신함으로 전달
    • RFC 표준이 아닌 Gmail 고유 동작
    • 공격자가 점 변형 주소로 별도 계정을 생성해 단일 계정 제한 우회나 무료 체험 중복 획득에 악용 가능한 실제 공격 벡터

• 서브어드레싱 (플러스 주소 지정)

  • 구분자를 사용해 로컬 파트에 태그를 추가할 수 있으며, 메일 서버는 기본 주소로 전달하면서 태그를 유지 (RFC 5233 표준)
  • 가장 일반적인 구분자는 +이며, Gmail, Outlook, ProtonMail, Fastmail 등에서 지원
    • Yahoo 일부 구성과 특정 Postfix 설정에서는 - 사용
    • qmail에서는 =이 기본 구분자이며, 이것이 VERP에서 @를 =로 인코딩하는 이유
  • 주요 활용 사례:
    • 유출 추적: 서비스별 고유 태그(예: [e-mail])로 가입해 스팸 수신 시 유출 출처 파악
    • 수신함 필터링: 메일 규칙으로 특정 태그 주소의 메일을 자동 분류
    • 다중 계정: 플러스를 정규화하지 않는 서비스에서 하나의 이메일로 별도 계정 생성 가능
  • 많은 웹사이트의 이메일 유효성 검사기가 +를 거부하지만, 이는 검증 코드의 버그이지 이메일의 제한이 아님

• 따옴표 문자열 형식 (Quoted String Form)

  • 로컬 파트를 큰따옴표로 감싸면 대부분의 문자 제한이 완화되어, 공백, @, 연속 점, 선행·후행 점 등이 허용
  • 예: "john doe"@example.com, "user@name"@example.com, " "@example.com
  • 실제로 거의 모든 이메일 제공자가 따옴표 로컬 파트를 수락하지 않으므로, RFC상 유효하지만 실무에서는 무용

• 주석 (Comments)

  • 괄호 안의 주석이 로컬 파트 시작이나 끝에 올 수 있으며, 메일 서버가 제거하고 전달에 영향 없음
  • RFC 5322에 따라 기술적으로 유효하지만 현대에서는 사용되지 않음
  • 괄호를 거부하는 유효성 검사기는 RFC보다 더 엄격한 것

• 유니코드 로컬 파트 (EAI)

  • RFC 6530, 6531, 6532에서 정의한 이메일 주소 국제화(EAI)로 로컬 파트에 UTF-8 문자 허용
  • SMTP 세션에서 SMTPUTF8 확장을 사용해야 하며, 송·수신 서버 모두 지원 필요
  • 2026년 기준 채택이 제한적이며, 유니코드 문자는 2~4 옥텟을 사용하므로 시각적 글자 수보다 적게도 64 옥텟 제한에 도달 가능

• 역사적 형식

  • Bang path (UUCP): DNS 이전에 모뎀으로 연결된 Unix 머신 네트워크에서 !로 구분된 호스트명 경로(machine1!machine2!user)를 사용한 라우팅 방식으로, 허용 문자 목록에 !가 포함된 이유. 현재 완전히 사용 중단
  • 퍼센트 핵(Percent hack): [e-mail] 형태의 릴레이 라우팅 트릭으로, % 문자는 라우팅 메커니즘이 RFC 5321에서 폐기된 후에도 로컬 파트에서 여전히 유효
  • 소스 라우팅(Source routing): SMTP RCPT TO 명령에서 명시적 릴레이 홉 목록(@relay1,@relay2:user@domain). RFC 5321에서 폐기

• VERP (Variable Envelope Return Path)

  • 대량 메일 시스템에서 바운스를 발생시킨 정확한 수신자를 추적하기 위한 기술
  • 수신자 주소를 봉투 발신자(MAIL FROM)에 인코딩하며, 수신자 주소의 @를 =로 대체
    • 예: bounces+alice=[e-mail]
  • Mailchimp, SendGrid, Amazon SES 등이 대규모 바운스 처리에 VERP 또는 변형 사용

• SRS (Sender Rewriting Scheme)

  • 서버가 메일을 전달하면서 SPF 검사를 통과시키기 위해 봉투 발신자를 재작성할 때 나타나는 주소 형식
  • SRS0=HASH=TT=originaldomain.com=[e-mail] 형태
  • 다중 홉 전달 시 SRS1=HASH=[e-mail] 형태
  • 구조적으로 유효한 이메일 주소이지만 인프라 산출물이며 사람이 사용하는 주소가 아님
  • HASH 구성 요소는 타임스탬프와 원본 주소에 대한 HMAC으로, 위조 방지 및 토큰 유효 기간 제한 역할

도메인 파트 (Domain Part)

• 레이블 규칙

  • 도메인은 점으로 구분된 레이블로 구성되며, 각 레이블에는 영문자 a-z, 숫자 0-9, 하이픈 - 허용
  • 하이픈으로 시작하거나 끝날 수 없으며, 3~4번째 위치에 연속 하이픈 불가(단, xn--로 시작하는 Punycode 레이블은 예외)
  • 레이블 최대 63자, 도메인 전체 최대 253자, 전체 이메일 주소(addr-spec) 최대 254자

• 서브도메인

  • 도메인은 여러 레벨을 가질 수 있으며, 253자 총 도메인 길이 외에 서브도메인 깊이에 대한 하드 제한 없음
  • 일반적 사용: 메일 인프라(mail., smtp., mx.), 조직 분리(sales.company.com), ESP 발송(email.company.com)

• IP 주소 리터럴

  • 도메인명 대신 대괄호 안의 IP 주소 사용 가능: user@[192.168.1.1], user@[IPv6:2001:db8::1]
  • RFC 5321에 따라 유효하지만 공개 메일 서버에서는 거의 수락되지 않으며, 내부 메일 시스템과 SMTP 테스트에 사용

• 단일 레이블 도메인

  • 점이 없는 도메인(예: user@localhost)은 일부 컨텍스트에서 기술적으로 유효하지만, 공개 메일 서버는 거부
  • postmaster@localhost는 Unix 계열 시스템에서 로컬 시스템 메일의 관례적 특수 케이스

• 국제화 도메인명 (IDN)과 Punycode

  • DNS는 ASCII 전용이므로, 비ASCII 문자는 Punycode(RFC 3492)로 인코딩되며 모든 인코딩 레이블은 xn-- 접두사로 시작
  • 이메일 클라이언트는 네이티브 스크립트로 표시하고 SMTP는 Punycode 형태로 전송
  • 호모그래프 공격: 다른 유니코드 스크립트의 시각적으로 동일한 문자로 잘 알려진 도메인과 유사한 도메인 등록 가능. 브라우저는 의심스러운 IDN에 대해 Punycode를 표시하는 방어 기능이 있지만, 이메일 클라이언트에는 대부분 이런 방어가 없어 이메일에서 더 효과적인 공격

• 후행 점 (Trailing Dot)

  • DNS에서 모든 도메인은 기술적으로 루트 존을 나타내는 후행 점으로 끝나지만, 이메일에서는 항상 암시적이며 생략
  • 대부분의 유효성 검사기가 [e-mail]. 형태를 거부

• MX 레코드

  • 이메일 주소의 도메인이 반드시 메일 서버가 있는 곳은 아니며, 발신 서버는 MX(Mail Exchanger) DNS 레코드를 조회해 실제 메일 서버 호스트명 확인
  • 낮은 우선순위 번호가 높은 우선순위를 의미하며, MX 레코드가 전혀 없으면 도메인의 A 레코드로 폴백
  • 도메인이 절대 이메일을 수신해서는 안 되는 경우, null MX 레코드(MX 0 .)를 게시해 발신 서버에 전달을 시도하지 말 것을 명시적으로 알림 (RFC 7505)

최상위 도메인 (TLD)

• 원래의 일반 TLD

  • 초기 인터넷의 7개 gTLD: .com(상업, 현재 비제한, Verisign 운영), .net(네트워크, 비제한), .org(조직, 비제한), .edu(미국 공인 교육기관, 제한), .gov(미국 정부, 제한), .mil(미군, 제한), .int(조약 기반 국제기구, 매우 제한적)
  • .arpa는 IANA가 관리하는 인프라 TLD로, 역방향 DNS 조회에서 사용

• 국가 코드 TLD (ccTLD)

  • ISO 3166-1 alpha-2 국가 코드 기반 2글자 코드로, 약 250개 존재
  • 일부 ccTLD는 다른 산업에 의해 용도가 전환:
    • .io(영국령 인도양 지역 → 테크 기업), .tv(투발루 → 미디어·스트리밍), .ai(앵귈라 → AI 기업), .co(콜롬비아 → .com 대안), .me(몬테네그로 → 개인 사이트), .ly(리비아 → URL 단축), .sh(세인트헬레나 → 소프트웨어 프로젝트)
  • 용도 전환된 ccTLD를 사용하면 기술적으로 해당 국가의 레지스트리 관할 하에 있게 되며, ICANN이 아닌 원래 국가의 레지스트리가 도메인을 통제

• 후원 TLD (sTLD)

  • 후원 조직과 자격 요건이 있는 TLD: .aero(항공운송, SITA 후원), .coop(협동조합), .museum(박물관), .jobs(고용), .xxx(성인), .post(우편), .cat(카탈로니아어·문화)

• 신규 일반 TLD (2012년 이후)

  • 2012년 ICANN이 신규 gTLD 신청을 개방해 1,200개 이상의 새 TLD가 위임
  • 이메일 유효성 검사에 중요한 영향: TLD 길이를 4~6자로 제한하는 유효성 검사기는 깨짐 (.photography, .international, .construction 등)
  • 개발자 관련: .app, .dev, .web, .code / 상업: .shop, .store, .online / 콘텐츠: .blog, .news, .media / 비즈니스: .tech, .agency, .cloud
  • 신규 gTLD는 낮은 등록 비용과 일부 레지스트리의 약한 악용 정책으로 인해 스팸과 피싱에 과도하게 대표됨

• 브랜드 TLD

  • 2012년 ICANN 확장 시 대기업들이 자체 TLD 신청: .google, .youtube, .gmail, .apple, .microsoft, .amazon, .chase, .barclays, .bmw
  • 대부분 공개 이메일 주소로 사용되지 않으며, 주로 내부 목적이거나 아예 미사용

• 지리·도시 TLD

  • 도시와 지역 자체 TLD: .nyc, .london, .paris, .berlin, .tokyo, .sydney, .wales, .scot
  • 등록 시 보통 해당 지역과의 연관성 입증 필요

• 국제화 TLD

  • 비ASCII 스크립트의 TLD가 다수 국가에 존재하며, DNS에서는 Punycode로 인코딩
    • .xn--p1ai(러시아, 키릴 문자), .xn--fiqz9s(중국, 간체자), .xn--mgberp4a5d4ar(사우디아라비아, 아랍 문자), .xn--h2brj9c(인도, 데바나가리 문자)

• 예약·문서화 TLD

  • RFC 2606, RFC 6761에서 테스트 및 문서화를 위해 예약한 TLD:
    • .test(공개 DNS에 절대 존재하지 않아 소프트웨어 테스트에 안전), .example(문서 예시용), .invalid(확실히 해석되지 않는 도메인 필요 시), .localhost(루프백용)
  • IANA가 문서와 예시용으로 example.com, example.net, example.org 을 등록해 두어, 실제 메일박스에 도달할 걱정 없이 코드 예시에 자유롭게 사용 가능

• 폐기된 TLD

  • 국가 소멸로 제거된 ccTLD: .yu(유고슬라비아, 2010년 삭제), .cs(체코슬로바키아, 1995년 삭제), .dd(동독, 1990년 삭제), .tp(동티모르, .tl로 대체 후 2015년 완전 삭제)
  • 예외: .su(소련) 는 1991년 해체에도 불구하고 여전히 활성 도메인이 존재하며, IANA가 수년간 전환 논의 중이지만 활성 상태 유지

ccTLD의 2차 도메인

• 많은 ccTLD가 등록 가능한 이름과 TLD 사이에 기능적 2차 레벨 카테고리를 추가
  • 영국: .co.uk, .org.uk, .gov.uk / 호주: .com.au, .edu.au / 일본: .co.jp, .ac.jp / 인도: .co.in, .gov.in / 브라질: .com.br, .gov.br
• 이메일 인증 시스템에서 조직 도메인을 찾아야 하는 경우 유효성 검사와 조직 도메인 감지에 영향

• Public Suffix List (PSL)

  • publicsuffix.org에서 커뮤니티가 관리하는 목록으로, 인터넷 사용자가 직접 이름을 등록할 수 있는 모든 도메인 접미사를 수록
  • 공식 위임(.co.uk, .com.au)과 사설 레지스트리(github.io, wordpress.com, herokuapp.com) 모두 포함
  • 와일드카드 표기법 사용(예: *.ck), 예외는 !로 표시(예: !www.ck)
  • 이메일 유효성 검사기와 스팸 필터가 전체 도메인 문자열에서 조직 도메인을 식별하는 데 사용
  • IETF 표준은 아니지만 이 문제에 대한 사실상의 표준(de facto standard)

이메일 주소 포맷 형식

• 기본 주소 (Bare Address)

  • local@domain 형태의 addr-spec으로, SMTP 명령과 단순 컨텍스트에서 사용

• 앵글 브래킷 형식

  • SMTP에서 MAIL FROM과 RCPT TO 명령에 꺾쇠괄호로 주소를 감쌈: MAIL FROM:<[e-mail]>
  • 꺾쇠괄호는 SMTP 명령 구문의 일부이지 주소 자체의 일부가 아님

• 표시 이름 형식 (Display Name Format)

  • 메시지 헤더(From, To, Cc)에서 사람이 읽을 수 있는 이름이 꺾쇠괄호 주소 앞에 올 수 있음: "John Doe" <[e-mail]>
  • 표시 이름에 특수문자가 포함되면 따옴표 필수
  • 표시 이름 스푸핑: 발신자가 표시 이름을 원하는 대로 설정할 수 있어, "PayPal Security <[e-mail]>" <[e-mail]> 형태의 공격이 가능
    • 많은 이메일 클라이언트가 수신함 목록에서 표시 이름만 보여주므로 가장 일반적인 피싱 기법 중 하나

• 그룹 구문 (Group Syntax)

  • RFC 5322에서 정의한 복수 수신자를 위한 명명된 그룹 형식: Marketing Team: [e-mail], "Bob Smith" <[e-mail]>;
  • 비공개 수신자 패턴: To: undisclosed-recipients:; — 빈 그룹 구문으로, 실제 수신자는 SMTP 봉투(RCPT TO)에 있고 메시지 헤더에는 보이지 않음

• 인코딩된 표시 이름

  • 이전 이메일 시스템에서 표시 이름의 비ASCII 문자를 RFC 2047 인코딩 단어로 처리: =?charset?encoding?encoded_text?=
  • 인코딩은 B(base64) 또는 Q(quoted-printable)
  • 현대 SMTPUTF8 지원 시 이 인코딩 래퍼 없이 헤더에서 직접 UTF-8 사용 가능

모든 이메일의 두 발신자

• 봉투 발신자 (Envelope Sender / MAIL FROM)

  • SMTP MAIL FROM: 명령에서 설정되며, 메시지 내용 자체의 일부가 아님
  • 바운스 라우팅에 사용되고, SPF 검사 시 검증 대상이며, 최종 수신 서버가 Return-Path: 헤더로 저장
  • 봉투 발신자(envelope from), 역경로(reverse path), RFC5321.MailFrom으로도 불림

• From 헤더

  • 메시지의 From: 헤더에 있는 주소로, 이메일 클라이언트가 발신자로 표시하는 것
  • DMARC이 SPF 또는 DKIM 정렬과 함께 보호하는 대상
  • 발신자가 자유롭게 설정할 수 있으며 대부분의 메일 서버에서 고유한 검증 없음
  • 이 두 주소는 완전히 다를 수 있으며, 이는 정상적이고 예상되는 시나리오:
    • ESP 대량 발송 시 MAIL FROM은 [e-mail], From 헤더는 [e-mail]
    • 메일링 리스트에서 MAIL FROM은 목록의 바운스 주소, From 헤더는 원래 게시자
    • 이메일 전달 시 전달 서버가 SRS로 MAIL FROM을 재작성하되 From 헤더는 원래 발신자 유지
  • 도메인에 DMARC 적용이 없으면, 누구든 완전히 관련 없는 MAIL FROM을 사용하면서 해당 도메인을 From 헤더에 넣어 발송 가능

• Sender 헤더

  • 메시지의 실제 제출자가 From 주소와 다를 때 실제 발송자를 식별: Sender: [e-mail]

• Reply-To 헤더

  • 답장이 가야 할 곳을 지정하며 From 주소와 다를 수 있음
  • 피싱 벡터로도 악용: 공격자가 From을 합법적으로 보이게 설정하고 Reply-To를 자신의 주소로 설정

• Null Sender

  • MAIL FROM:<>는 유효하고 중요한 SMTP 구조로, 빈 봉투 발신자는 바운스 메시지, 자동 응답, 자체적으로 바운스를 생성해서는 안 되는 메시지에 사용
  • 두 시스템이 실패 알림을 계속 교환하는 무한 바운스 루프 방지

역할 기반 주소 (Role-Based Addresses)

• RFC 5321 필수

  • postmaster@domain: RFC 5321에 따라 메일을 수락하는 모든 도메인에서 이 주소의 메일 수락이 의무, 예외 없음

• RFC 2142 권장

  • abuse@domain(스팸·악용 신고), hostmaster@domain(DNS 존 관리), security@domain(취약점 공개·보안 보고), webmaster@domain(웹 서버 문제), noc@domain(네트워크 운영)

• 관례적 역할 주소

  • info@, support@, sales@, billing@, legal@, privacy@, careers@, contact@, hello@, help@, feedback@, admin@ 등 공식 표준은 아니지만 널리 사용
  • 역할 주소는 보통 여러 사람이 공유하므로, 민감 정보 전송 시 다수의 팀원이 열람 가능
  • abuse@와 postmaster@는 불만 메일을 수신하므로 소셜 엔지니어링의 대상

• 캐치올 주소 (Catch-All Addresses)

  • 특정 이메일 주소 형식이 아닌 메일 서버 구성으로, 특정 메일박스가 없는 로컬 파트에 대해서도 전달을 수락
  • 활용 사례: 오타 포착, 개발자 테스트, 정식 별칭 시스템 없이 서비스별 고유 주소 생성
  • 단점: 어떤 로컬 파트든 전달되므로 대량 스팸 유입, SMTP 프로빙을 통한 주소 유효성 검사가 불가능(모든 프로브에 성공 응답 반환)

제공자별 고유 동작

• Gmail

  • 점 정규화: 로컬 파트의 모든 점 무시
  • 플러스 주소 지정: + 구분자 지원
  • @googlemail.com: 독일·영국에서의 상표 분쟁으로 인한 @gmail.com의 역사적 별칭으로, 두 도메인 모두 동일 수신함 전달
  • 문자 제한: 로컬 파트에 영문자, 숫자, 점만 허용(플러스 주소 지정용 + 포함). 전체 RFC 문자 세트 미지원
  • 로컬 파트 길이 제한: RFC 최대 64자보다 훨씬 낮은 30자

• Microsoft (Outlook, Hotmail, Live)

  • 점 정규화 없음: [e-mail]과 [e-mail]은 별도의 메일박스
  • 도메인 별칭: @hotmail.com, @live.com, @outlook.com이 별칭 구성 시 동일 계정 참조 가능
  • 플러스 주소 지정 지원

• Apple (iCloud)

  • 도메인 별칭: @icloud.com, @me.com, @mac.com이 동일 수신함 (.mac → .me → .icloud로 서비스명 변경 이력)
  • 플러스 주소 지정 지원
  • Hide My Email: [e-mail] 형태의 무작위 별칭 생성, 각 서비스나 앱별 고유 별칭으로 실제 주소 비공개 유지

• ProtonMail / Proton

  • 도메인 별칭: @proton.me, @protonmail.com, @pm.me가 동일 수신함
  • 플러스 주소 지정 지원

• 이메일 별칭 서비스

  • 일회용 이메일과 별개로, 영구적이고 제어 가능한 전달 주소를 생성하는 서비스:
    • SimpleLogin(Proton 소속): 커스텀·랜덤 별칭으로 모든 수신함에 전달
    • Addy.io(구 AnonAddy): SimpleLogin과 유사, 셀프 호스팅 가능
    • Firefox Relay(Mozilla): 무료 플랜에서 제한된 랜덤 별칭
    • DuckDuckGo Email Protection: @duck.com 별칭
  • 발신자에게는 실제 수신함과 구조적으로 구별 불가능한 주소 생성
  • 일회용 이메일과의 핵심 차이: 별칭은 영구적이며 제어 가능, 특정 별칭 비활성화·서비스별 발송 확인·원하는 수신함으로 전달 가능

일회용·임시 이메일

• 가입 불필요하고 보통 짧은 기간 후 만료되는 수신함을 제공하며, Mailinator, Guerrilla Mail, 10 Minute Mail, TempMail 등이 대표적
• 대부분 캐치올 라우팅을 사용하므로 해당 도메인의 어떤 로컬 파트든 수신함에 전달
• 많은 수신함이 공개적이어서 주소를 아는 누구든 메시지 열람 가능
• 알려진 일회용 도메인의 차단 목록(disposable-email-domains GitHub 저장소가 가장 많이 참조됨)이 존재하지만 항상 불완전하며, 차단을 회피하기 위해 지속적으로 새 도메인으로 교체

유효성 검사 (Validation)

• 기술적 유효성 vs 실무적 유효성

  • RFC상 유효하지만 실제 서버에서 거의 수락되지 않는 것: 따옴표 안의 공백(" "@example.com), 따옴표 안의 @("user@name"@example.com), IP 리터럴 도메인(user@[192.168.1.1]), 단일 문자/단일 레이블(a@b)
  • RFC상 유효하고 실무에서도 수락되는 것: [e-mail], [e-mail], [e-mail], [e-mail]
  • 대부분의 애플리케이션에서 실용적 유효성 검사기가 완전한 RFC 준수 검사기보다 우수: 기본 구조 확인, 합리적 문자 세트 검증, 선택적으로 도메인의 DNS MX 조회 수행

• 일반적 유효성 검사기 버그

  • 로컬 파트에서 + 거부: [e-mail]은 완전히 유효하며, 매우 흔한 버그
  • 로컬 파트에서 _ 거부: 역시 유효
  • 로컬 파트에서 % 거부: 유효한 문자이며, 폐기된 것은 퍼센트 핵 라우팅 사용뿐
  • TLD 길이를 4~6자로 제한: .photography, .international, .construction 등 수백 개의 신규 gTLD를 차단
  • 하드코딩된 TLD 목록으로 검증: 목록이 지속적으로 변경되므로 검사기가 노후화
  • 잘못된 총 길이 제한: 254 대신 255 또는 256 사용. RFC 3696 정오표 번호 1690에서 널리 인용되던 잘못된 값 320을 254로 수정
  • 로컬 파트에서 대문자 거부: RFC상 유효
  • [e-mail] 거부: 유효하며, 2차 ccTLD 패턴의 다중 점 도메인은 정상
  • .dev, .app, .io를 TLD로 거부: 모두 유효한 위임된 TLD

• 길이 제한

  파트	제한
  로컬 파트	64 옥텟
  도메인 레이블	63 옥텟
  도메인 전체	253 옥텟
  전체 주소(addr-spec)	254 옥텟

• 로컬 파트 제한은 문자가 아닌 옥텟 단위이므로, 멀티바이트 유니코드 문자를 가진 EAI 주소는 시각적으로 64자 미만이면서도 옥텟 제한에 도달 가능

• DNS 기반 유효성 검사

  • MX 레코드 확인: 도메인에 MX 레코드가 있는지 검증하며, 빠르고 저위험. A 레코드 폴백을 사용하는 도메인(MX 미구성)은 이 검사 실패 가능
  • Null MX 확인: 도메인에 MX 0 .이 있으면 메일을 명시적으로 수신하지 않음
  • SMTP RCPT TO 프로빙: 메일 서버에 연결해 RCPT TO 명령을 발행하여 주소 수락 여부 확인하지만, 많은 서버가 주소 수확을 방지하기 위해 모든 주소에 250 응답을 반환하므로 신뢰할 수 없음. 캐치올 도메인은 항상 긍정적 응답. 프로브 IP가 블랙리스트에 추가될 위험도 존재
  • 이메일 주소를 완전히 신뢰성 있게 검증하는 유일한 방법은 실제 메시지를 보내 도착 여부를 확인하는 것이며, 나머지는 모두 휴리스틱

보안 함의

• 표시 이름 스푸핑

  • 누구든 이메일의 표시 이름을 원하는 대로 설정 가능하며, 표시 이름만 보여주는 수신함 뷰에서 사용자는 실제 주소를 명시적으로 확인하지 않으면 합법적 발신자와 사칭을 구별 불가

• Punycode를 통한 호모그래프 공격

  • 다른 유니코드 스크립트의 문자를 사용해 실제 잘 알려진 도메인과 시각적으로 동일한 도메인 등록 가능
  • 이메일 클라이언트는 브라우저와 달리 일반적으로 이에 대한 경고를 표시하지 않음

• Gmail 점 트릭을 통한 계정 우회

  • Gmail이 점을 무시하므로, 공격자가 기존 Gmail 주소의 점 변형으로 서비스에 가입해 단일 계정 제한 우회, 무료 체험 중복 획득, 원래 계정 소유자에게 의도된 이메일 수신 가능

• 이메일 주소 재사용

  • 이메일 제공자가 버려진 주소를 새 사용자에게 재할당할 수 있으며, 새 계정 소유자가 이전 소유자가 등록했던 서비스의 계정 복구 이메일을 수신해 비밀번호 재설정을 통한 계정 탈취 가능
  • Gmail은 주소를 재할당하지 않는다고 밝혔지만, 일부 다른 제공자는 역사적으로 재할당한 사례 존재

• 서브어드레스 태그 노출

  • [e-mail]으로 가입하면 수신 서비스가 태그를 포함한 전체 주소를 확인 가능
  • 플러스 태그를 제거하고 저장하는 서비스는 기본 주소를 노출시키며, 전체 주소를 그대로 저장하는 서비스는 계정 설정이나 데이터 내보내기에서 추적 전략이 드러남