이메일 유효성 검사, 지금까지 어떻게 하셨나요?
spring boot를 사용하신다면 jakarta validation의 @Email 어노테이션을 사용하셨을 수도 있고, 인터넷이나 gpt로 간단한 Email 정규식을 찾아 사용하셨을 수도 있습니다. ex)^[a-zA-Z0-9._-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,4}$
이러한 이메일 정규식들은 대부분의 상황에서 큰 문제를 일으키지 않습니다.
하지만 이메일 표준을 정확하게 이해하지 못하면 의도하지 않은 동작을 일으킬 수 있습니다.
이메일 형식 이해하기
이메일 형식은
local-part@domain이렇게 구분되어 있습니다. '@' 기호를 중심으로 왼쪽 부분이 local-part, 오른쪽 부분이 domain입니다.
addr-spec = local-part "@" domain local-part = dot-atom / quoted-string / obs-local-part domain = dot-atom / domain-literal / obs-domain
local-part와 domain은 각각 위와 같은 요소로 구성될 수 있습니다.
dot-atom
dot-atom은 하나 이상의 atext문자들이 "."으로 구분되어 있는 문자열 입니다.
ex) my.email, example.com
atext = ALPHA / DIGIT / "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "/" / "=" / "?" / "^" / "_" / "`" / "{" / "|" / "}" / "~"
atext는 RFC5322에서 위와 같이 정의되어있고, 주석을 통해비허용된 특수문자를 제외한 Printable US-ASCII로 나타내져 있습니다.
qouted-string
qouted-string은 이름처럼 따옴표로 구분된 문자열입니다. dot-atom과 달리 특수문자들이 허용됩니다.
ex) "helo@#$[aaa01@}"
domain-literal
domain-literal은 대괄호로 감싼 domain 표현 방식입니다.
domain-literal = [CFWS] "[" *([FWS] dtext) [FWS] "]" [CFWS] dtext = %d33-90 / ; Printable US-ASCII %d94-126 / ; characters not including obs-dtext ; "[", "]", or "\"(CFWS, FWS는 주석)
이렇게 정의되어 있고, 주로 [192.168.1.1], [IPv6:2001:db8::1]처럼 IP 주소를 직접 입력할 때 사용합니다.
obs-local-part / obs-domain
값은 허용되지만, 이전에 표준에서 사용되었고 더 이상 권장되지 않는 표준 방식입니다.
local-part
SMTP를 정의한 RFC5321에서는 local-part를 domain(host)에서 local-part에 대한 해석을 담당하도록 하고있습니다.
STMP 스펙 상으로는 local-part에서 대소문자를 구분하지 않지만, 그것과 상관없이 해당 이메일을 운영하는 host에서 대소문자를 구분할지, 특정 문자를 무시할지등 여러 제약과 규칙을 넣을 수 있습니다.
Gmail Issue
제 서비스와 제 학교에 있는 주변 서비스들에서는 주로 gmail을 사용하여 email 인증을 하는 방식을 사용했습니다. 이메일에 관심을 가지고 찾아보면서 발생 가능한 문제 몇가지를 찾아보았습니다.
-
Gmail 에서는 대소문자를 구분하지 않아서 문제가 발생할 가능성이 있습니다.
예를들어 "example@gmail.com"이라는 이메일로 이미 가입을 한사람이 "Example@gmail.com"으로 다시 인증 메일을 보내고 새로 가입할 수 있었습니다. -
Gmail에서는 local-part중간에 "."기호가 포함되더라도 같은 이메일로 간주함을 명시하고 있습니다. 따라서 "example@gmail.com"으로 가입을 했더라도 "exam.ple@gmail.com"으로 다시 가입할 수 있었습니다.
-
RFC5233에서는 Subaddress Extension이라는 기능을 정의하고 있습니다. Subaddress Extension은 "+" 기호를 통해 같은 이메일 local-part내에서 추가적인 기능을 수행할 수 있도록 합니다.
Gmail 문서에서도 "+" 기호를 통한 alias 기능을 제공합니다. 따라서 "example@gmail.com"으로 가입했더라도 "example+second@gmail.com"로 다시 가입할 수 있었습니다.
domain
domain은 위에서 설명한 표준말고도 RFC1034, RFC1035, RFC1123같은 domain name에 관한 표준을 준수하도록 되어있습니다. 여기서 나오는 개념들은 Http를 공부하며 배운 domain, host과 같은 개념입니다.
Http에 대해 공부했다면 알 수 있듯이, email에서 domain은 대소문자를 구분하지 않습니다. 따라서 "example@example.com"과 "example@Example.com"은 이메일 시스템에서 똑같이 처리됩니다.
마무리
이처럼 email인증을 통해 본인확인 및 중복가입을 해결하려고 개발한 서비스의 경우 이메일 표준에 주의할 필요가 있습니다.
이메일 인증 보다 쉽고 간편한oauth를 사용합시다!
