요약

  • 1982년 SMTP는 수신 서버가 다른 서버로 갈 메일을 맡고, 다음 구간에서는 발신 서버가 되는 중계를 허용했다.
  • 1999년 RFC 2505는 허가 없는 중계를 막으라고 했다. 호출자가 마음대로 쓰는 HELO와 MAIL FROM은 통행증이 될 수 없었다.

택배 회사 창구에 낯선 사람이 와서 “사장 친구예요”라고 말한다. 그는 먼 도시까지 트럭을 보내 달라며 짐을 놓고 간다. 기름값과 민원은 회사 몫이다. 초창기 인터넷 메일에는 시스템 사이를 잇는 운송이 정말 필요했다. 열린 중계 서버의 우스운 점은 운송 자체가 아니라, 처음 보는 손님이 회사 도장을 스스로 찍는 듯한 접수 방식이었다.

1982년 8월의 SMTP 명세 RFC 821에서 중계는 정상적인 기능이다. 수신 서버는 다른 서버로 가는 메시지를 받아들일 수도, 거절할 수도 있었다. 받아들이면 다음 구간의 발신자가 된다. 명세는 최종 사서함 주소와 여러 호스트를 지나는 경로도 구분했다. 서로 다른 네트워크와 메일 환경을 잇는 데 이 역할은 쓸모가 있었다.

그런데 누가 그다음 운송을 주문할 권리가 있을까. 1999년 2월 Best Current Practice 30으로 발표된 RFC 2505는 허가 없이 남의 서버를 중계에 쓰는 일을 자원 도용과 운영자 평판의 위험으로 다뤘다. 메일 전송 프로그램이 그런 사용을 제어하고 거절할 수 있어야 한다고 했다. 운전사를 없애자는 얘기가 아니라, 차주가 손님 명단을 정하게 하자는 얘기였다.

SMTP 대화에 나오는 정보는 신뢰도가 제각각이다. HELO의 호스트 이름은 연결한 쪽이 말한다. 꾸며낼 수 있다. MAIL FROM의 반송 주소도 그쪽이 말하며 위조할 수 있다. RCPT TO는 배달할 대상을 가리킨다. 서버는 연결해 온 쪽의 네트워크 주소도 본다. 첫 두 문구만 보고 중계를 허락하면, 손님이 직접 만든 명함 한 장으로 트럭 열쇠를 건네는 셈이다.

RFC 2505가 권한의 기준으로 제시한 것은 서버 자신의 업무 범위다. 서버가 맡는 수신 도메인, 또는 약속에 따라 전달해 주는 도메인으로 가는 메일을 받는다. 출발지 주소로 허가한 호출자, 혹은 운영자가 DNS를 신뢰하기로 한 경우 허가한 호스트 이름의 호출자에게 중계를 허용한다. 나머지 운송 요청은 거절한다. 고객이 무슨 이름을 대든, 실제로 누구의 우편물을 처리할지 정하는 곳은 서버 운영자다.

목적지를 읽는 일도 가끔 함정이었다. RFC 2505는 @a,@b: 같은 소스 경로, %를 쓰는 우회 표기, !가 들어가는 UUCP 경로를 경고했다. 겉으로는 지역 주소처럼 보여도 끝까지 해석하면 다른 서버로 나가야 하는 주소가 있었다. 반대로 정당한 게이트웨이도 낯선 표기를 사용했다. 운영자는 문을 잠그기 전에 자신이 쓰는 라우팅 방식을 확인해야 했다. 목적지의 앞부분만 읽는 경비원은 엉뚱한 출구를 지킨다.

같은 해 6월 DON'T SPEW라는 제목의 RFC 2635는 인터넷 서비스 제공업체의 몫을 짚었다. 낯선 이에게 열린 중계 서버를 두지 말고, 이용 정책을 공개하며, 계정 제재 전에는 남용 사실을 확인하고, 누군가 읽는 abuse와 postmaster 연락처를 운영하라고 했다. MTA 설정은 접수 한 건을 막을 수 있다. 신고를 받고 잘못된 혐의를 가리는 일에는 조직이 필요하다.

2008년 10월의 SMTP 명세 RFC 5321은 문을 잠근 뒤에도 남는 긴장을 기록했다. 메일에는 배달하거나 실패를 알려야 한다는 오랜 원칙이 있었다. 원치 않는 대량 메일 때문에 거절이나 폐기가 현실적인 운영 선택이 되었지만, 말없이 사라지는 편지는 전달 체계의 신뢰를 갉아먹는다. 중계를 허가할지 결정하는 일과 이미 받은 편지의 운명을 알리는 일은 같은 책상 위의 다른 서류다.

메일 서버는 여전히 길을 잇는다. 달라진 것은 손님이 스스로 운송 허가를 써내는 관행이다. HELO의 반가운 인사는 인사로 남고, 트럭의 열쇠는 트럭을 운영하는 사람 손에 남았다.