요약

메일 한 통에 발신자가 몇 명인가

받는 사람이 화면에서 보는 From 주소와 메일 서버가 SMTP 대화 중 사용하는 MAIL FROM은 같은 자리가 아니다. EHLO에도 이름이 나온다. 전달 서버를 한 번 거치면 보이는 주소와 실제 접속한 서버의 관계는 더 복잡해진다. 도메인 소유자가 DNS에 허용된 송신 서버를 적어 놓아도, 받는 서버가 먼저 어느 도메인에 그 허가를 적용할지 정해야 한다.

IETF의 MARID 작업 그룹 규약은 From, Sender, MAIL FROM, EHLO를 후보로 나열하고 검사할 신원을 고르는 일을 첫 과제로 삼았다. Sender ID는 PRA 알고리즘으로 헤더에서 책임을 지는 것으로 여겨지는 주소를 찾았다. SPF는 SMTP 거래에서 제시된 신원을 살폈다. 두 방식 모두 DNS에 정책을 올릴 수 있었지만, 정책이 가리키는 대상까지 같지는 않았다.

무료 허락에도 남은 배포 창구

2004년 9월 서한에서 Apache는 Microsoft의 당시 특허 허락 조건이 Apache License 2.0과 맞지 않는다고 판단했다. 이론적인 반대에 그치지 않았다. 스팸 필터 SpamAssassin과 메일 서버 JAMES에 Sender ID를 구현하거나 도입하지 않겠다고 밝혔다.

서한이 지목한 걸림돌은 구체적이었다. Apache의 해석에 따르면 특허 권한을 뒤이어 코드를 받는 사람에게 자연스럽게 재허락하기 어려웠고, 이름을 바꾸거나 다시 배포하려는 쪽은 Microsoft에 연락해야 했다. 오픈소스 코드는 개발자에게서 패키지 관리자와 운영자에게 넘어가며 고쳐지고 다시 묶인다. 그 과정에 특허권자의 별도 창구가 들어서면 청구액이 0이어도 유통 경로의 권한은 달라진다.

Apache가 거부할 수 있었던 것은 자신이 관리하는 프로젝트의 채택이었다. 다른 회사의 메일 프로그램까지 금지한 것은 아니다. 그러나 공개된 기술 문서를 읽을 수 있는 권리와 그 문서대로 만든 코드를 자유롭게 전달할 수 있는 권리가 서로 다른 것임을 분명히 보여줬다.

두 문서를 발표해도 한 뜻이 되지 않았다

2006년 4월, IETF는 Sender ID와 SPF 문서를 모두 Experimental RFC로 발표했다. IESG의 주석은 폭넓은 기술 합의가 없었고 두 접근을 조정하려던 시도가 실패했다고 적었다. Sender ID 수신기가 SPF용으로 게시된 DNS 기록을 자기 규칙으로 해석하면 정상 메일을 전달하지 못할 수 있다고 경고했다. 자동 전달과 Resent-* 헤더도 호환성 문제로 지적됐다.

두 제안을 기록해 시험할 길은 열렸다. 그러나 같은 DNS 문구를 보는 모든 수신기가 같은 신원을 검증하게 된 것은 아니었다. 논쟁의 끝에는 문서 번호보다 수신 여부가 달린 메일 한 통이 있었다.

2012년 IETF 실험 평가는 SPF가 널리 구현되고 사용된 반면 Sender ID의 PRA와 SUBMITTER는 강한 사용 집단을 확보하지 못했다고 결론지었다. 두 방식의 소프트웨어는 존재했고, 사용 가능한 구현이 없어서 선택이 막힌 것은 아니었다고 명시했다. 이 평가는 배포 현황을 살핀 것으로 두 알고리즘의 추상적인 우열을 판정한 것은 아니다. SPF는 2014년 표준화 경로로 올라갔고, Sender ID의 RFC 세 건은 2020년 Historic으로 바뀌었다.

Apache의 2004년 결정은 특정 구현 경로 하나를 닫았다. 나중의 IETF 평가는 메일 운영자들이 장기간 어떤 방식을 채택했는지 보여준다. 그 사이를 잇는 기술적 사실은 2006년 경고에 담겨 있다. DNS의 허가 문장을 읽는 쪽마다 발신자를 다르게 고르면, 그 불일치의 대가는 도착하지 않은 정상 메일이 치른다.