메일이 왜 자꾸 스팸으로 가요?

Why

요즘 메일 보내는게 까다로워 졌습니다.
그냥 보내면 어김없이 스팸함으로 가버립니다.

조금 찾아보면,
SPF, DMARC, DKIM 등등 왠 사람 이름 같은 기술 제시하며 뭘 하라고 합니다.

아니 뭐 이렇게 많아요? 이거 다 해야돼요?
사실 별거 아닙니다.

오늘 위 3가지 기술의 배경과 스팸으로 가는 이유를 알아봐요~

함 파봐요 메일 발송 과정

우선, 상식적으로 생각해보세요.

우리가 편지를 상대방에게 주려면, 물리적으로 만나야 합니다. (우체부를 통한 전달도 만남의 일종)
이메일도 마찬가지 인데요.

메일을 보내려면, 당연히 메일 서버에 접속해서 데이터(메일)를 전달 해야 합니다.

그러니까 중요한건, 메일을 보낼 때, 직접 내 메일을 수신자의 메일 서버로 갖다 주는 방식 이라는 것입니다.
수신자의 메일 서버가 어딘가에서 가져오는게 아니라요.

누가 메일을 갖다주냐구요?

메일 발신 서버가요.

• gmail 이면 구글 서버가요.
• aws면 AWS가요.
• 내 PC라면 내 PC가요! (근데 스팸으로 갈겁니다.)

우리가 인터넷에서 게시판에 글을 올리는 것과 하등 차이가 없습니다.
원인 제공자가 찾아가는 서비스 인것이죠.

대충 이렇게 합니다.

a@sender.com 가 b@receiver.com 에게 메일을 보낸다고 가정 할께요.

• a 는 sender.com 의 웹메일에 들어가서 메일을 작성 합니다. (웹메일이 있다고 가정)
• 제목, 수신자, 참조, 본문 을 작성 했어요.
• 보내기를 누릅니다.

이때, 내부적으로 어떤 일이 일어나는지, 하나씩 따라가볼께요.
메일을 보낼때는 TCP/IP 위에서 SMTP 라는 프로토콜을 씁니다.

• sender.com 의 메일 처리 서버는, 수신자의 도메인을 확인 합니다.
• 여기서는 receiver.com 겠죠?
• 이 도메인의 정보를 가져오기 위해서 DNS 서버에 질의를 하는데요.
  • 우리가 일반적으로 IP 물어볼때 사용하는 그 DNS 가 맞아요. 근데 MX 레코드 (Mail-eXchange)를 요청 합니다.
• 즉, receiver.com 도메인 소유자가 등록해 놓은 메일 (받을) 서버 IP를 알려 달라고 하는 것입니다.
  • sender.com 서버는 거기로 가서 메일을 던지고 와야 하니까요.
  • IP가 아니라 다른 도메인 주소일 수 도 있어요. 어쨋든 IP를 알아낼 때 까지 DNS에 조회 합니다.
• 이제 그 서버로 접속 하는데요, 보통 25번 포트로 접속 합니다. (일단, SSL/TLS는 빼고 얘기할께요.)
• 들어가면?
• 메일을 받으라고 있는 서버니까요. 누구한테 오던지 다 받고요. (서버가 서버에게 메일 보낼때는 인증도 필요없어요)
• 이제 들어가서 제목, 받는사람, 본문 남기고 나가면 , 메일주소의 @앞부분 b 라는 유저의 메일함에 넣게 됩니다.

굉장히 상식적이죠?
그런데 문제가 있어요.

위 과정에서 문제점

일단 원래도 프로토콜이 빈약 했는데, 인터넷이 발전하면서 더 문제가 많아졌어요.

• 일단 MX 서버는 누구든지 다 접속을 허용 해야 합니다.
  • 누구든지 나에게 메일을 보낼 수 있으니까요.
• 메일 프로토콜이 참으로 단순해서, 보내는 사람 이름과 이메일 주소를 그냥 준대로 받아버립니다.
  • 즉 어떤 서버에서 보내든지 간에, 누구든 맘대로 써서 위조 할 수 있어요.
  • 제가 빌게이츠 인것 마냥 보낼 수 있다는 거죠.
• 기본 프로토콜은 SSL이 없어 통신 내용을 가로채면… 다 털립니다.
• 메일을 보내러 MX 서버에 접속 하려고 하는데, 그 서버가 다운되어 있어 접속이 안되면 그걸로 끝입니다.

얼핏 봐도 많은 문제가 있죠.
대부분은 요즘 기술적으로 해결을 했습니다.

SSL을 사용하고, MX 서버도 큐잉을 하는 등 많은 발전이 있었지만…
위조 문제는 프로토콜 자체를 뜯어고치지 않는 한 어쩔수 없었어요.

스팸 메일을 근본적으로 해결하지 못한 이유죠.

스팸 메일이 끊이지 않는 이유

무료로 불특정 다수에게 뭔가를 심기에 최고이기 때문 입니다.
그리고 메일 프로토콜 특성상, 스팸에 대응하기가 까다롭죠. (위조 가능 문제+누구나 발신 문제)

그래서 나왔습니다. 세가지 사람 이름 같은 기술이…

SPF, DKIM, DMARC 말이에요.
하나씩 알아보죠.

SPF

이것은 위 문제중, 발신자가 진짜인지 확인하는 기술 입니다.
v=spf1 ip4:192.0.2.0/24 include:_spf.google.com -all 이렇게 생겼는데요.
간단해요

• 처음부터 발신자도 자신의 도메인에 TXT 레코드로 SPF 정보를 넣어둡니다.
  • 예시에서는 sender.com 도메인 소유자가 자신의 DNS에 TXT 로 SPF 관련 정보를 넣어두는 거죠.
• 이제, 수신자는 메일을 받았는데, 발신자가 a@sender.com 라고 하면, DNS에게 sender.com의 SPF 정보를 물어보는거죠.
• receiver.com) 지금 메일을 보내러 들어온 니 IP는 1.1.1.1 인데 말야.
• receiver.com) 내가 sender.com 의 SPF의 IP를 보니깐, 2.4.6.8 이네? 넌 뭐야???
• 공격자) 딱 걸렸내~

그래서 딱 걸리면 SPF 검증에 실패했다고 태그를 달아서 메일을 받아요.
그럼 그런 메일은 안보여주면 되겠죠.

DKIM

SPF랑 비슷한데요, 좀더 모던 하게 처리 합니다.
v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC3... 요렇게 생겼고,
RSA 암호화를 이용하고, 공개키/개인키 쌍을 이용 해요. 위에 p 어쩌고가 공개키 입니다.

IP 를 한정하기 어려운 상황도 있기 때문에, 키를 사용 합니다.
예를 들어 발신자가 abc.com 인데 나는 구글웍스 를 쓴다면 내가 메일 발신 IP를 알기도 어렵잖아요?
그래서 좀 더 똑똑하게 서명 방식을 쓰는데요.

인터넷으로 똑똑하게 서명하려면 뭐다? RSA 죠 뭐.

• 마찬가지로 sender.com 가 미리 자신의 공개키를 DNS에 넣어둡니다.
• 수신자가 sender.com 한테 메일을 받으면, DNS에서 공개키를 갖고오고요.
• 메일에 포함된 서명 내용을 풀어서 검증을 해봅니다. (자세한 깊은 매커니즘은 따로 알아 보시면 재밌습니다. 저도 RSA 암호화 관련 글을 쓰기도 했죠.)
• receiver.com) 내가 sender.com 의 키로 서명 풀어봤는데 안풀리는데? 넌 뭐야???
• 공격자) 딱 걸렸내~

이후는 SPF와 똑같겠죠?

DMARC

이거는 가장 마지막 기술인데요.
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-failures@example.com; pct=100 이렇게 생겼는데, 셋중 제일 뭔가 복잡 합니다.
SPF, DKIM 으로 발신자를 잘 체크 하기는 했는데 말입니다.

막는 방법이 2개나 있다보니 둘다 통과 하던지, 하나만 하던지 조금씩 원하는게 다를 겁니다.
그러니까 SPF는 통과 했는데 DKIM은 실패했다거나, 반대라거나 등등 일때 어떻게 할지 정해주는 거예요.

그래서 발신자의 DNS의 정보에 그 처리방법을 적어둡니다.

• sender.com 의 DNS에 TXT로 DMARC 값을 넣는데 이게 그냥 정책 입니다.
• SPF, DKIM 중 하나만 통과하면 OK냐 아니면 둘다 통과해야 OK냐 등등등
• receiver.com) 내가 sender.com 의 DMARC 보니깐 넌 DKIM 통과 해야하는데 SPF만 통과했네?
• 공격자) sender.com 메일 서버를 해킹 해서 SPF 통과 했는데, 딱 걸렸내~

이 결과를 가지고 메일을 보여줄지 말지 스팸함으로 갈지 말지 결정 하도록 합니다.
또한 DMARC는 사람의 개입이 필요하니, 어떤 메일들이 오고 가는지 모니터링을 해야 정책을 잘 잡을 수 있는데요.

그래서 설정 값중에 보고서를 받을 메일 주소를 넣게 됩니다.
정책 통과 못한 메일은 보고서 메일 주소로 오도록요. (메일 내용은 오지 않아요~)

이메일들을 보고 모니터링을 해야, 각각 정책을 수정할 수도 있겠죠?

마무리

HTTP/3 마냥 메일의 세계도 그냥 가만히 있지는 않았죠.
거듭 발전해 오고 있으나, 프로토콜 자체는 매우 오래된 구식 입니다.
마치 태양계 밖으로 나간 보이저 1호를 유지보수 하는 느낌이랄까요.

최근 Gmail 이 DMARC를 강제하면서 부랴부랴 DNS 설정 한바탕 난리 부르스를 추신 분들이 많으실 겁니다.
하면서도 왜 하는지 몰랐다면,

에헤이 별 것 아니었네 하면서 이 글로 인해 자세히 알아가셨길 바랍니다.

다음에도 좋은 글로 찾아올께요.

아임웹 CTO 매튜 드림.