DMARC 공개 14 년 후, 여전히 68.4% 의 기업이 정책 강제 실패
DMARC has been public since 2012 but most company domains still don't enforce it
2012 년 공개된 DMARC 표준에도 불구하고, 조사한 67,336 개 도메인 중 68.4% 는 여전히 정책을 강제하지 않습니다. 기록이 없는 경우가 45.1% 인 반면, 기록은 있으나 모니터링만 하는 p=none 설정이 23.3% 를 차지합니다. 단순한 무지가 아닌, 복잡한 리포트 분석으로 인해 실제 발송 주체를 식별하지 못해 정책 전환이 지연되고 있습니다.
관리자가 한 주의 리포트를 바라볼 때, 그들은 벤더 목록을 보는 것이 아니라 소유자가 불분명한 IP 주소와 발신자 문자의 무더기를 보고 있습니다.
HN 토론
158- bcrl
안타깝게도 이 기사는 DMARC 가 실제로 유용한 성과를 이루고 있는지에 대해서는 거의 다루지 않습니다. 제가 운영 중인 메일 서버 중 하나에 대해 수신 메일에 DMARC 를 적용했을 때, 결국 몇몇 고객으로부터 온 메일이 정기적으로 차단되는 문제가 발생했습니다. 반면 들어오는 스팸의 거의 대부분은 유효한 SPF/DKIM/DMARC 를 가지고 있었으며, 대부분의 피싱 공격도 마찬가지였습니다.
핵심 문제는 이메일 최종 사용자의 진정한 필요는 특정 발신자를 신뢰할지 여부를 판단하는 방법을 찾는 데 있다는 점입니다. 서명은 발신자의 신뢰성에 대한 정보를 전혀 제공하지 않는 순수한 기술적 조치에 불과합니다. 그 결과 이메일 점수 산정은 여전히 콘텐츠 기반으로 이루어져야 하며, 서명 확인 기술은 실제로 내 받은 편지함에 메일을 표시해야 할지 여부를 결정하는 데 있어 유용한 신호 없이 순수한 노이즈일 뿐입니다.
기술 산업은 사용자가 실제로 해결해야 할 문제와 인접한 문제에 대한 해결책을 제공하는 나쁜 습관이 있으며, 사용자의 실제 문제는 방치해 둡니다.
- EvanAnderson
저는 수백 개의 소규모 조직 (각 조직당 1,000 명 미만의 수신자) 의 이메일을 관리합니다. 더 잘 알았을 것 같은 발신자들 (포천 100 대 기업급) 에서조차 SPF 와 DKIM 실패가 너무 많습니다. 사용자가 누락된 메일에 대해 불평하는 것을 원하지 않기 때문에, 게시된 정책이 달리 명시하더라도 실패를 무시하게 됩니다.
- TheChaplain
이메일을 사용하지 않는 도메인이 있다면, 이를 악용당하지 않도록 DNS 레코드를 설정하는 것이 좋을 수 있습니다.
DNS SPF 레코드: mydomain.io. TXT "v=spf1 -all"
DNS DMARC: _dmarc.mydomain.io. TXT "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s"
이렇게 하면 누구도 귀하의 도메인을 발신처로 사용하려는 시도를 막을 수 있습니다.
- tgv
이 기사는 DMARC 모니터링에 대해 말하고 있지만, 이를 '설정'하는 것에는 대해선 다루지 않습니다. 많은 조직은 이러한 사항을 주시할专人负责가 있을 만큼 충분히 크지 않습니다. 제가 일하는 곳에서는 CTO 가 DNS 를 관리했지만, 그 모든 것이 무엇을 의미하는지에 대해 거의 이해하지 못했습니다. 그저 복사해서 붙여넣기만 했을 뿐입니다. 그리고 예, p=none 으로 설정되어 있기도 합니다. 아마도 예제에 그렇게 나와서일 것입니다. 회사의 웹사이트를 설정하고 임의의 WordPress 인스턴스를 선택하는 것과 같습니다. 위험을 어떻게 알 수 있겠습니까? 정말로 너무 많습니다.
- jwr
저는 주요 이메일 제공업체가 악용 처리를 위한 자동화 방식을 제공하지 않고, 악용 보고서를 전혀 신경 쓰지 않는 훨씬 더 큰 문제를 해결해야 한다고 정말로 생각합니다. 제 스팸의 대부분은 세 가지 주요 이메일 제공업체에서 오며, 이제는 보고서가 무시당하기만 하므로 아예 악용 보고서를 보내는 시도조차 포기했습니다.
대기업들은 구글, 마이크로소프트, 아마존을 차단하려는 사람이 아무도 없기 때문에 신경 쓸 필요가 없습니다. 그들은 너무 커서 실패할 수 없습니다.
From 필드를 위조하는 문제는 이에 비해 사소한 문제입니다.