3P by GN⁺ | ★ favorite | 댓글 1개

이메일 전달성에 대한 심층 분석

  • 1971년 10월, MIT 졸업생인 Ray Tomlinson이 최초의 이메일을 네트워크를 통해 보냄.
  • 지난해 약 121조 개의 이메일이 약 43억 명 사이에서 전송됨.
  • 이메일은 지구상에서 가장 중요한 서면 형태의 커뮤니케이션 수단이며, 가까운 미래에도 그럴 것임.

개요

  • 2023년 10월 3일, Google과 Yahoo는 스팸, 피싱, 맬웨어 시도를 방지하기 위한 새로운 이메일 보안 표준을 발표함.
  • 이메일 서비스 제공업체들이 이러한 정책을 시행하면서, 이메일 전달성에 대한 가이드라인 준수가 필수적임.
  • 가장 큰 변화는 SPF, DKIM, DMARC와 같은 이메일 인증 표준의 구현임.
  • Gmail의 경우 인증되지 않은 메일은 차단됨.

영향을 받는 사람들

  • 대량 발송자들이 주로 영향을 받으며, SPF, DMARC, DKIM을 자신들의 도메인에 활성화해야 함.
  • 대량 발송자가 아니더라도 가이드라인을 준수하지 않으면 영향을 받을 수 있음.

타임라인

  • Google은 2024년 2월부터 대량 발송자들이 이메일을 인증하도록 요구함.
  • Yahoo도 2024년 1분기부터 동일한 요구사항을 적용함.

가이드라인

  • 발송자 인증: SPF, DKIM, DMARC와 같은 이메일 인증 프로토콜 구현.
  • 대량 발송자 요구사항: 스팸 필터링과 평판 손상을 피하기 위해 불필요한 대량 이메일 발송을 피함.
  • 쉬운 구독 해지: 구독 해지 옵션을 쉽게 구현함.
  • 참여: 오해의 소지가 있는 제목, 과도한 개인화, 스팸 필터를 유발하는 프로모션 콘텐츠 피함.

발송자 인증

  • SPF, DKIM, DMARC는 조직의 이메일을 보호하는 데 도움이 되는 3가지 인증 표준임.
  • 이러한 표준의 적절한 구성은 공격으로부터 보호하고 전달성을 높여 이메일이 스팸 폴더가 아닌 수신함에 도달하도록 함.

영향

  • Google은 알고리즘과 사용자 보고 데이터를 지속적으로 업데이트하여 이메일 필터링과 사용자 경험을 개선함.
  • 새로운 보안 가이드라인이 이메일 전달성과 참여에 미치는 영향을 밝힘.

도구

  • 이메일 위생을 설정, 확인 및 유지 관리하는 데 도움이 되는 무료 온라인 리소스 목록 제공.

구현

  • 이러한 가이드라인을 구현하는 것은 자원이 제한된 소규모 조직에게 도전이 될 수 있음.
  • 이메일 인증을 구현하기 위해 서비스 제공업체의 리소스나 지원을 참조함.

보너스

  • 해커들이 이메일 보안 취약점을 악용하는 몇 가지 방법을 소개함.

GN⁺의 의견

  • 이 기사는 이메일 보안과 관련된 최신 표준을 준수하는 것의 중요성을 강조함. 이는 이메일을 통한 커뮤니케이션의 신뢰성을 높이고, 스팸이나 피싱과 같은 위협으로부터 사용자를 보호하는 데 기여함.
  • 이메일 서비스 제공업체들이 새로운 보안 표준을 시행함에 따라, 조직들은 이러한 변화에 적응하고 준수하기 위한 노력을 기울여야 함. 이는 특히 개인 정보 보호와 데이터 보안에 민감한 시대에 더욱 중요함.
  • 이 기사는 이메일 마케팅과 관련된 사업을 운영하는 기업들에게 특히 유용할 수 있음. 이메일 마케팅은 여전히 많은 기업들에게 중요한 마케팅 채널이기 때문에, 이메일 전달성을 유지하는 것은 성공적인 캠페인을 위해 필수적임.
  • 이메일 인증 표준을 구현하는 것은 기술적인 도전이 될 수 있으며, 특히 SPF, DKIM, DMARC와 같은 프로토콜을 처음 접하는 조직에게 어려울 수 있음. 이러한 표준을 도입할 때는 기술적인 지원과 리소스가 필요할 수 있으며, 이는 시간과 비용을 요구할 수 있음.
  • 이 기사는 이메일 보안을 강화하고자 하는 조직에게 유용한 가이드라인과 도구를 제공함으로써, 이메일 시스템의 취약점을 보완하고 사용자 경험을 향상시키는 데 도움을 줄 수 있음.

댓글과 토론

Hacker News 의견들
  • “Gmail”, “Outlook”, “Yahoo” 같은 이메일 제공자가 가진 영향력을 보면, 기업을 겨냥한 다른 공격으로 표적형 도달 실패가 가능하지 않을까 늘 궁금했음
    피해자, 특히 기업·메일링 리스트·NGO가 공격자가 소유한 주소들로 대량 메일을 보내게 만들고, 공격자는 Gmail/Yahoo/Outlook에서 그 메일을 스팸으로 표시함
    그러면 AI 스팸 필터가 새 스팸 활동으로 학습해 이후 실제 고객에게 가는 메일까지 스팸 처리하거나 도착 전에 삭제할 수 있음
    1년쯤 지나면 회사는 분기마다 돈을 잃고, 광고 부서는 이메일 참여율 하락을 의아해하며, 기술 부서는 혼란에 빠질 수 있음
    큰 회사는 버티거나 이메일을 아예 포기할 수 있겠지만, 작은 회사나 NGO·정치 메일링 리스트는 기부 감소 같은 타격을 받을 가능성이 있음
    솔직히 공격 경로로는 낮은 가능성이겠지만 계속 마음에 남아 있던 생각임

    • 실제 스패머가 합법적인 이메일 템플릿을 그대로 훔쳐 쓴 피해자를 알고 있음
      스패머는 합법 템플릿을 이메일 안에 보이지 않게 넣고, 실제 사기 문구 몇 줄만 보이게 함
      필터가 이메일 대부분을 정상으로 보이게 판단해 통과시키려는 방식이고, 결국 사용자들이 충분히 스팸 신고를 하면 템플릿 자체가 차단을 유발함
      그러면 스패머는 아직 필터를 통과하는 다음 피해자의 이메일 템플릿으로 옮겨 가고, 첫 피해자는 자기 메일이 어디에도 도달하지 않는 뒤처리를 떠안게 됨
    • 이걸 기업 공격 관점이 아니라 소비자 권리나 보이콧 관점에서 생각해 본 적 있음
      주주가치 극대화를 내세우는 큰 회사와 너무 나쁜 경험을 해서, 예전 이메일 기록을 뒤져 그 회사의 모든 커뮤니케이션을 스팸으로 표시했음
      물방울 하나일 수 있지만, 스팸 세계에서는 많은 표가 필요하지 않을 수도 있음
      이메일 전달은 곧 더 노골적인 유료 통과 모델로 진화할 것 같고, 이미 막후 합의가 있는지도 모름
    • 그래서 대부분의 전자상거래 사이트는 마케팅 메일을 별도 도메인에서 보냄
      그 도메인이 신고당해도 거래성 이메일은 주 도메인에서 계속 보낼 수 있음
      물론 두 메일 서버가 서로 다른 IP에 있다는 전제가 필요함
    • 아는 웹 포럼에는 자기들이 보내는 이메일 알림을 스팸으로 표시하지 말라는 규칙이 있음
      사이트에서 수신 거부는 할 수 있지만, 이메일 클라이언트 쪽에서 스팸 처리하지 말아 달라는 것임
      작은 조직에는 꽤 현실적인 위험일 수 있음
      큰 조직이 어떻게 완화하는지는 잘 모르겠음
    • 그건 DMARC 정책으로 막을 수 있는 것 아닌가 싶음
      공격자가 보낸 이메일이 SPF/DKIM에 실패한다면, Gmail이 애초에 그 가짜 메일을 전달하지 않도록 DMARC 정책을 설정할 수 있음
      그러면 그런 공격은 성립하지 않음
  • 이 변화는 필요했고 너무 늦었음
    많은 양의 이메일을 보내는 도메인 소유자에게 메시지 서명을 제대로 요구하면, 수신자는 IP 주소 평판이 아니라 도메인 평판을 기반으로 좋은 메일과 나쁜 메일을 더 명확히 구분할 수 있음
    점점 더 많은 도메인이 거래성·마케팅 서비스의 공유 IP 공간을 통해 이메일을 보내는 상황에서, 평판을 발신 도메인에 안정적으로 붙일 수 있는 능력은 악용을 줄이는 데 매우 유용함

    • “많은 양”이라는 조건은 사실이 아님
      Google은 하루 5,000통 이상을 보낼 때만 새 요구사항이 필수라고 하지만, 그건 거짓임
      나는 하루에 많아야 몇 통, 보통 Gmail 계정으로는 하루 한 통도 안 보냈고 요구사항 일부만 구현했는데도 Google이 내 메시지를 거부하기 시작했음
      결국 다소 중복적인 요구사항까지 모두 구현하느라 시간을 낭비해야 했음
    • 시스템 관리자로서 수신자의 Office365 메일 서버 설정 오류 때문에 이메일의 5%가 스팸으로 들어가면 어떻게 해야 하나 싶음
      전체적으로는 긍정적 변화에 동의하지만, 이메일이 스팸함에 들어가는 이유가 수신자 쪽 설정 오류일 때 정말 답답함
      예를 들면 전달 과정에서 SPF가 깨지는 경우가 있음
    • 우리도 서서히 IPv6로 이동하고 있는데, 원하는 만큼 새 IP 주소를 가질 수 있다면 IP 기반 평판은 어느 정도 쓸모없어질 것임
      악의적 발신자가 이메일마다 다른 IPv6 주소에서 보낼 수 있다면, 새로 보이는 IPv6 주소는 기본적으로 전부 신뢰하지 않도록 해야 할 수도 있음
    • 동의함, 이게 확실한 장점임
      불편은 있지만 이 변화가 이메일 생태계를 정리해 주길 바람
  • 스팸은 악성 콘텐츠와 구분할 수 없음
    그 “뉴스레터”에 가입한 적도 없고, 이메일 주소가 수집되어 당신을 괴롭히려는 악의적 행위자에게 넘어간 것임
    무엇이든 클릭하면, 그 회사가 당신의 정보를 가지고 당신의 이익을 전혀 고려하지 않을 웹사이트로 가게 됨
    최선의 경우 받은편지함의 쓰레기 출처 하나를 제거할 수 있을 뿐이고, 최악의 경우 컴퓨터에 악성코드를 설치하는 무언가를 클릭하게 됨
    그래서 수신 거부 링크를 클릭하지 말고, 스팸 신고 버튼을 누르며, 스팸 신고를 무시하는 대형 이메일 서비스를 그만 써야 함
    Gmail은 다른 대기업이 당신에게 스팸을 보내도록 봐주면서 전체 도메인을 직접 차단할 선택지도 주지 않음
    개인정보와 보안을 진지하게 다루는 이메일 제공자로 옮기기 전까지 악성 콘텐츠는 계속 받은편지함에 들어올 것임

    • 타당한 평가임
      어떤 이메일 서비스 제공자를 쓰는지 궁금함
  • 원클릭 수신 거부 테스트를 통과하지 못하는 대기업이 이렇게 많다는 게 놀라움
    Cloudflare나 Akamai가 연결을 막거나, 페이지 로딩에 5초 이상 걸리거나, 로그인이나 이메일 주소 재입력을 요구하는 식임
    그러고도 고객이 스팸 신고 버튼을 누른다고 놀라면 안 됨

    • 내가 동의하지 않은 이메일은 수신 거부하지 않음
      그래서 스팸 신고를 누름
    • NextDNS에 광고 차단 목록을 붙여 쓰고 있는데, 사실상 클라우드의 Pi-hole임
      가장 짜증나는 건 이메일 발신자가 광고 차단 목록에 막히는 도메인으로 클릭 추적을 한다는 점임
      그런 링크를 복사해 붙여 넣기 위한 별도 브라우저 인스턴스를 두고 있지만, 그러면 또 로그인해야 함
      링크를 클릭하기보다 수신 거부 이메일을 보내는 편을 선호하고, Gmail은 이걸 자동화할 수 있음
    • 수신 거부는 하겠지만, 2024년에 “적용까지 14일이 걸릴 수 있습니다” 같은 헛소리는 이제 인정 못 함
      며칠 안에 또 이메일이 오면 스팸으로 표시할 것임
      TripAdvisor는 AI 생성 여행 일정을 만들 수 있다면, 그걸 이메일로 보내지 않는 방법도 알아낼 수 있어야 함
    • 결국 단순한 UI 경쟁이라고 봄
      고객은 수신 거부든 스팸 신고든 더 편한 쪽을 선택함
  • 4월 변경사항이 깨뜨리는 것 중 하나는 이메일 서비스 간 전달
    예를 들어 예전 대학 주소 foo@school.edu에서 개인 Gmail 계정 bar@gmail.com으로 전달하고 있다면 더 이상 동작하지 않을 것임
    주요 제공자들이 밀어붙이는 걸 보면 비교적 드문 사용례겠지만, 영향을 받는 사람들에게는 꽤 성가신 변화임

    • 왜 더 이상 동작하지 않는다는 건지 모르겠음
      이메일을 전달할 때 전달자가 메시지 내용을 수정하지 않는 한 DKIM 서명과 여전히 일치하므로 통과해야 함
    • 이건 새로운 변화가 아님
      SPF는 항상 봉투의 보낸 사람 주소를 건드리지 않는 전달자를 깨뜨렸고, 그게 맞고 적절함
      여전히 메일 전달은 가능하지만, 전달자가 return path를 다시 써야 함
    • 꽤 중대한데, 이제 이메일 전달이 더는 안 된다는 뜻인가?
  • SPF, DKIM, DMARC가 완벽히 설정되어 있지 않은데도 누군가 메일을 통과시키고 있었다는 게 놀라움
    나는 몇 년 동안 잘 설정된 자가 호스팅 개인 이메일 서버를 운영했는데도 가끔 통과시키는 데 어려움을 겪었고, 그래도 조금씩 나아지는 것 같음

    • SPF, DKIM, DMARC를 완벽히 설정했다고 해서 수신 서버도 그렇게 본다는 뜻은 아님
      특히 Microsoft 서버는 아무 문제 없는 DKIM 설정을 이유 없이 무작위로 실패 처리하는 일이 잦음
    • 설정만의 문제가 아니라 평판도 중요함
      발송량이 낮으면 잘 알려진 발신자가 아니라는 이유만으로도 버려질 위험이 있음
    • 나도 몇 년 동안 이 문제와 씨름해 왔음
      큰 3곳이 이런 지침을 공개하고 투명하게 만들었으니 동작이 더 일관적이길 바람
    • 내 경험상 DKIM은 필요하지 않았고, 새 Google 지침에서도 SPF를 사용하면 여전히 필수는 아님
    • 사람들이 이메일 도달성을 SPF, DKIM, DMARC 설정으로만 본다는 게 놀라움
      스패머도 진입 장벽이 낮으니 똑같이 할 수 있음
      중요하긴 하지만 현실 세계의 도달성과는 관련이 매우 작음
  • DMARC에서 가장 힘든 건 특히 Microsoft에서 자주 실패한다는 점임
    그리고 수신자가 메일을 전달하는 모든 사용례에서도 문제가 생기는데, 이때 SPF 정렬이 깨짐
    모범 사례를 따르고 싶어서 최근 p=quarantine을 p=none으로 바꿨음
    DKIM과 SPF를 제대로 설정했는데도 합법 이메일이 DMARC를 통과하지 못할까 봐 두려웠기 때문임
    p=reject를 정말 쓰고 싶지만, 수신자들이 이메일 전달로 DMARC가 깨지는 같은 예외 상황을 처리하도록 수신 메일 서버를 고치기 전까지는 못 하겠음

    • DMARC를 적용하면서 자기 이메일이 전달되길 바라는 발신자는 DKIM을 써야 함
      DKIM 서명된 메시지를 전달해도 DMARC는 전혀 깨지지 않음
  • 최악은 메일을 받아 놓고 조용히 스팸으로 표시한 뒤, 의도한 수신자가 절대 보지 못할 곳에 넣어 버리는 것임
    Google의 Gmail이 이걸 가장 심하게 함
    기업 이메일은 더 이상 이메일이 아니라 Facebook 같은 벽으로 둘러싸인 정원이자 사일로임

    • 그런 벽이 있어서 다행임
      그렇지 않으면 콜드 이메일 스팸에 익사했을 것임
      진지하게 말하면, 자체 서버 운영과 관리를 포기해서 모든 회사에 Gmail을 쓰고 있음
      이게 이렇게 어려워졌다는 건 비극임
      잘 설정된 Gmail Workspace 위에 있지 않으면, 합법 메일이라도 통과할 가능성이 없는 것처럼 느낌
    • 정말 짜증남
      내가 이해하기로는 스패머에게 메시지가 정상 메일인지 스팸인지 판별됐다는 신호를 주고 싶지 않은 것 같음
      스패머가 실제로 그런 정보를 얼마나 영리하게 활용하는지 알고 싶음
      대부분의 스팸은 실패 피드백을 고려하지 않고 두들겨 대는 시도처럼 보임
      내 메일 서버에서는 정크로 분류된 메시지를 일반 오류 메시지와 함께 계속 임시 거부함
      적어도 잘못 분류된 합법 발신자는 지연 DSN을 받고, 최종적으로 메시지가 수신되지 않았다는 피드백을 받음
      많은 메일 서버와 서비스는 잘못 분류된 합법 사용자에게 유용한 신호를 주는 것보다 스패머에게 신호를 주지 않는 쪽을 더 중요하게 보는 듯함
      아마 자기들의 분류가 아주 훌륭해서 오분류하지 않는다고 생각하는지도 모름
    • 옳다고 말하는 건 아니지만, 효과는 있음
      Gmail의 스팸 필터와 프로모션 필터는 사용자 입장에서 99% 이상 신뢰할 만하고, 오탐도 정말 적음
    • 안타깝게도 요청하지 않은 스팸에 대한 많은 법적 보호는 소비자 사용에만 적용됨
      B2B에서는 당신의 이메일 주소를 알 수 있는 마케터라면 원하는 만큼 메시지를 보낼 권리가 있는 셈임
      벽이 없었다면 완전히 쓸 수 없게 됐을 것임
  • 내 개인 VM이 어떤 RBL에 올라갔는데, 전체 /24 주소 공간이 블랙리스트에 올랐기 때문임
    누군가가 스팸을 보냈다고 하고, 이제 일주일에 이메일을 세 통 정도 보내는 내 머신도 차단됨

    • 문제는 VM 제공자가 의도치 않게 같은 주소 공간을 스패머에게 제공하고 있다는 점임
      스패머가 그 범위 안의 임의 주소를 썼을 수도 있고, 누군가 릴레이를 허용하는 잘못 설정된 SMTP 서버를 띄웠을 수도 있음
      고객 IP 범위에서 발신 SMTP 서버를 운영하는 건 어차피 문제가 되기 쉬움
      그런 범위는 스패머들이 평판을 신경 쓰지 않고 쓰기 때문에 전부 의심스럽게 볼 수 있음
    • 맞음, 이건 고통스러움
      차단 목록 운영자들이 악용 신고 검증을 잘 못 하거나, 네트워크 운영자가 조치하게 만들려고 부수 피해를 일으키는 것 같음
      차단 목록에 오르는 건 싫지만, 넓은 인터넷에는 순효과가 있을지도 모름
      메일 서버와 서비스가 IP 기반 차단 목록을 잘못 쓰고 있다고 봄
      여러 신호 중 하나로 쓰고, 처음 보는 발신자에게는 가중치를 더 줄 수는 있음
      하지만 SPF/DKIM/DMARC로 인증된 메시지와 거래를 계속 주고받던 IP가 갑자기 차단 목록에 올라갔다면, 이전의 긍정적 평판이 그 차단보다 강해야 함
      알려진 상대와는 계속 통신할 수 있어야 하고, 그들이 스팸으로 표시한 뒤에야 이후 전달을 거부하거나 정크 처리할 수 있어야 함
      지금은 많은 메일 서버와 서비스가 시스템 부하를 줄이려고 SMTP 과정 초기에 IP 차단 목록을 적용하는 것 같음
      시스템 부하에는 좋지만 분석 성능에는 나쁨
      전반적으로 대형 무료메일 서비스조차 정상/스팸 판단에서 기존 평판을 활용하는 능력이 좋지 않아 보임
      최근 내가 만든 온라인 웹서비스를 이메일 기반 가입으로 바꿨는데, 메일링 리스트 가입처럼 특정 주소로 이메일을 보내 가입하는 방식임
      아이디어는 사용자가 내 서비스에 이메일을 보내면 내가 사용자의 알려진 상대 목록에 들어간다는 것임
      그러면 내 메일 서버가 보내는 SPF/DKIM/DMARC 정렬된 확인 답장은 당연히 받아들여져야 함
      이보다 더 명확한 옵트인이 얼마나 더 필요한가 싶음
      몇몇 대형 무료메일에서 테스트했더니 Yahoo는 원본 메시지를 참조하는 확인 답장마저 정크 폴더에 넣었음
      대형 메일 서비스와 경쟁할 수 없다고 생각하는 사람들에게 말하자면, 기준은 생각보다 높지 않음
    • 정말 안됐음
      평판을 고치는 건 잘해도 악몽에 가까움
      주 도메인을 보호하려고 다른 도메인을 사서 그쪽에서 이메일을 보내라는 제안도 봤지만, 별로 하고 싶지는 않음
  • 본문에서 봉투(RFC5321)헤더(RFC5322) 를 섞어 쓴 것 같음
    “이메일 봉투 헤더의 From: 필드에 있는 도메인명이 검사되고 SPF나 DKIM으로 인증된 다른 도메인과 정렬된다”고 했는데, 봉투에는 헤더가 없고 헤더는 이메일 콘텐츠/본문 안에 있음
    “모든 이메일 보안 지침을 통과하는 조직의 이메일 봉투 예시”라는 스크린샷도 봉투 정보가 아니라 메일 헤더임
    이 주제에 대한 dmarc.org의 좋은 발표 자료가 있음
    https://dmarc.org/presentations/Email-Authentication-Basics-...