Hacker News 의견

• 개인 메일 서버를 운영하는 사람으로서, 러시아 IP 주소가 내 도메인 이름으로 이메일을 보내려는 시도를 계속하는 것을 알림

  • 이메일을 보내는 것이 사업인 사람들은 이메일 설정을 제대로 하는 방법을 알고 있음
  • 많은 시스템 관리자들이 기본적인 설정을 제대로 하지 못하는 것에 놀람
  • SPF 서명이 잘못되어 Sendgrid 이메일이 거부된다는 DMARC 이메일을 받으면 마케팅이 이를 합법적으로 사용하는지 물어봐야 할 것임
  • 자동 서명은 제한된 가치를 가지지만, SPF와 DKIM에 기반한 거부가 실수인 경우는 드물음
  • 대형 조직에서는 상황이 더 나쁠 수 있지만, 작은 이메일 서버에서는 기술적 거부가 보통 올바른 결정임
  • 메일링 리스트는 예외지만, 이를 사용하는 사람들은 예외를 추가하는 방법을 알아낼 수 있음

• SPF, DKIM, DMARC를 제대로 설정하고 스팸 점수가 0인 도메인을 가지고 있어도 스팸 폴더에 들어가는 문제를 겪고 있음

  • 이메일이 Gmail에 수락되기 위해서는 "평판"이 필요함
  • 이메일이 스팸으로 바로 가면 그 평판이 어떻게 쌓일지 혼란스러움
  • Linkedin 이메일은 스팸이 아니며, 그들의 다크 패턴이 이메일 리스트에 추가되더라도 차단되지 않음

• SPF/DKIM은 메일 서버의 평판과 관련이 있음

  • Google, Microsoft, Yahoo와 같은 대형 서버에 주로 이익이 됨
  • 대형 제공자의 스팸 방지 시도가 소형 제공자에게 해를 끼침
  • 이메일 서버 평판을 추적할 필요는 없고, 발신자 평판을 추적해야 함
  • 익명 이메일과 실제로 아는 사람의 이메일을 다르게 처리할 수 있어야 함
  • 현재로서는 알려진 이메일 발신자가 미지의 발신자를 안전하게 소개할 방법이 없음

• SPF와 DKIM이 스팸을 완전히 막지는 못하지만, DMARC는 아마도 쓸모없음

  • 스팸 발신자도 이 표준을 읽을 수 있기 때문에 SPF/DKIM이 스팸을 완전히 막지는 못함
  • SPF/DKIM 도입 전에는 "support@paypal.com"과 같은 주소로 피싱 메일을 많이 받았음
  • Paypal은 SPF로 허용된 IP 주소를 명확히 표시하고, DKIM으로 메일을 검증할 수 있음
  • Spamassassin은 올바른 DKIM과 paypal.com에서 온 메일의 스팸 점수를 크게 줄임

• SPF/DKIM/DMARC의 목적은 이메일을 도메인에 묶어 스푸핑을 방지하는 것임

  • 인증만으로 스팸을 줄일 수 있다고 기대하는 것은 순진함

• Google은 SPF와 DKIM에 서툼

  • 몇 달 전 Chromium 버그 트래커 메시지에 이메일로 응답하려 했으나 실패함
  • SPF/DKIM 검사가 실패했다는 이유로 이메일이 처리되지 않음
  • 내 SPF와 DKIM은 문제가 없었음
  • Google Workspace 설정 시 사용하라는 도구가 오랫동안 제대로 작동하지 않음
  • 피드백 링크도 제대로 작동하지 않음

• 개인 이메일 서버를 운영하며, 대부분의 스팸은 SPF/DKIM을 통과하지 못함

  • 최근 몇 년간 통과하는 스팸의 비율이 증가하고 있음
  • 예상한 메일의 90-95%가 SPF/DKIM을 통과함
  • 엄격한 발신자 규칙을 적용하고 있음
  • 사이트에 이메일 주소를 공개했지만 스팸이 거의 없음

• 간단한 휴리스틱 기반의 스팸 필터를 운영 중임

  • 발신 메일을 확인하고, 발신한 주소나 제목이 포함된 메일은 스팸으로 표시하지 않음
  • 새로운 주소에서 온 스팸은 읽지 않은 상태로 표시됨
  • 구독 확인 같은 경우는 스팸 폴더 상단에 위치함

• Proton으로 메일을 옮겼고, DNS 항목 추가 및 검증 과정이 매우 쉬웠음

  • 처음에는 이 단계가 두려웠지만, 쉽게 해결됨

• SPF, DKIM, DMARC의 가치는 IP 기반에서 도메인 기반으로 평판이 이동하는 것이라 생각했음

  • 도메인 평판을 잘 유지하고 SPF, DKIM, DMARC를 올바르게 설정하면 어떤 IP에서도 SMTP 서버를 호스팅할 수 있을 것이라 기대했음
  • 왜 그렇게 작동하지 않는지 궁금함