500마일 이메일

500마일 이메일, 다른 말로 500마일 이상 가지 않는 이메일은 엔지니어링에서 유명한 이야기입니다.

본문

The case of the 500-mile email 로부터 번역되었습니다.

불가능한 것처럼 들리는 문제가 있습니다... 많은 청중에게 이야기를 게시한 것을 거의 후회합니다. 학회자리에서, 술을 마시며 멋진 이야기를 만들기 때문입니다.:-) 이야기는 잘못된 부분을 지우고, 관련없거나 지루한 세부 사항을 생략하고 일반적으로 전체를 더 재미있게 만들기 위해 약간 변경되었습니다.

몇 년 전에, 캠퍼스 이메일 시스템을 운영하는 일을 하고 있을 때 통계학과의 학과장으로부터 전화를 받았습니다.

"학과 외부로 이메일을 보내는 데 문제가 있습니다."

"무엇이 문제인가요?" 나는 물었다.

“이메일이 500마일 이상 가지 않습니다.” 라고 학과장은 설명했습니다.

나는 마시던 커피를 뱉을 뻔 했습니다. "뭐라고 하셨죠?"

"여기에서 500마일 이상 떨어진 곳에서는 이메일을 보낼 수 없습니다." 그는 연이어 말했습니다. "조금 더요. 정확하게는 520마일 정도입니다. 하지만 그 이상은 안 됩니다."

"음... 이메일은 일반적으로 그런 식으로 작동하지 않습니다." 나는 목소리에 당황함이 묻어나오지 않게 하려 애쓰며 말했습니다. "어떻게 500마일 이상 우편물을 보낼 수 없다는 이야기인가요?"

"내가 생각하는 것과는 다릅니다." 학과장이 퉁명스럽게 대답했습니다. "보시다시피, 우리가 이런 일이 일어나는 것을 처음 알았을 때가, 며칠 전이었는데요."

"며칠동안 이 현상이 있었다고요?" 나는 말을 가로막았다. 떨림이 내 목소리를 간지럽혔다. "그리고 그동안 이메일을 보낼 수 없었나요?"

"이메일은 보낼 수 있습니다. 단지 그 거리보다 더 먼 거리--"

"아, --500마일, 네." 나는 말을 대신 정리했습니다.

"음, 우리는 지금까지 무슨 일이 일어나고 있는지 확신할 만큼 충분한 데이터를 수집하지는 못했습니다." 그렇습니다. 그 분은 통계학과 교수었습니다. "어쨌든, 나는 지리통계학자 중 한 명에게 조사를 요청했는데--"

"지리 통계학자요..."

"네, 그리고 그 분은 우리가 이메일을 보낼 수 있는 반경이 500마일보다 약간 더 많은 것을 보여주는 지도를 만들었습니다. 그 반경 안 일부 기관에는 전혀 이메일이 가지 않거나, 자주 또는 가끔 도달할 수 있는 곳들이 있습니다. 분명한 것은, 우리는 이 반경보다 더 멀리 이메일을 보낼 수 없습니다."

"알겠습니다." 나는 말하고 머리를 손으로 잡았습니다.

"언제부터 이 문제가 시작됐습니까? 며칠 전부터 문제가 있었다고 말씀하셨는데, 당시에 시스템에 변경된 사항이 있나요?"

"컨설턴트가 와서 우리 서버를 패치하고 재부팅했었습니다. 그런데 전화를 해서 확인해봤는데, 메일 시스템은 건드리지 않았다고 합니다."

"알겠습니다. 한 번 살펴보고 다시 전화드리겠습니다." 이건 장난이 아닐거라고, 장난일 것 그 자체를 두려워하며 전화를 끊었습니다.

분명히 만우절은 아니었습니다. 혹시나, 누군가가 나에게 장난을 치고 있는지, 그럴만한 사람이 있는지 기억하려고 노력했습니다.

통계학과 메일 서버에 로그인하고 몇 개의 테스트 메일을 보냈습니다. 이것은 노스캐롤라이나의 연구소 삼각지대(Research Triangle)에 있었고 내 계정으로는 테스트 메일이 문제없이 배달되었습니다. 리치몬드, 애틀랜타, 워싱턴에 보낸 사람도 마찬가지입니다. 프린스턴(400마일)까지도 정상이었습니다.

하지만 멤피스(600마일)에 이메일을 보내려고 했습니다. 실패했습니다. 보스턴, 실패. 디트로이트, 실패. 나는 내 주소록을 꺼내서 이것을 좁히기 시작했습니다. 뉴욕(420마일)은 성공했지만 프로비던스(580마일)는 실패했습니다.

이제는, 내가 정신이 제대로 잡혀있는지 궁금해지기 시작했습니다. 노스캐롤라이나에 살지만 ISP가 시애틀에 있는 친구에게 이메일을 보내려고 했습니다. 고맙게도 실패했습니다. 문제가 메일 서버가 아닌 받는 사람의 위치와 관련이 있었다면 눈물을 흘리며 무너졌을 것입니다.

믿을 수 없을 정도로, 이 문제가 확실하게 사실이고 반복 재현이 가능하다는 것을 확인했습니다.

그리고는, 그 서버의 sendmail.cf 파일을 살펴보았습니다. 상당히 평범해 보였습니다. 파일 내용은 심지어 매우 익숙하게 느껴졌습니다.

내 홈 디렉토리에 있는 sendmail.cf와 비교했습니다. 차이가 없었습니다. 서버의 sendmail.cf 는 이전에 내가 작성한 sendmail.cf였습니다. 그리고 "FAIL_MAIL_OVER_500_MILES"(500마일이상 가지 않도록 하는 옵션) 옵션을 활성화하지 않았다고 확신했습니다. 어쩔 수 없이 SMTP 포트에 텔넷으로 연결했습니다. 서버는 SunOS sendmail 배너로 행복하게 응답했습니다.

잠깐만... SunOS sendmail 배너? 그 당시 Sun은 Sendmail 8이 상당히 잘 만들어졌고, 지원됨에도 불구하고 여전히 운영 체제와 함께 Sendmail 5를 내장하고 있었습니다. 저는 훌륭한 시스템 관리자로서 Sendmail 8을 표준으로 사용하고 있었습니다. 또한 훌륭한 시스템 관리자로서 저는 Sendmail 5 에서 사용되던 암호같은 코드로 만들어신 설정 파일 대신 Sendmail 8에서 사용할 수 있는 긴 자체 문서화 옵션과 변수 이름을 사용하는 sendmail.cf를 작성했습니다.

모든 문제의 조각들이 한꺼번에 맞아 떨어지기 시작했고, 나는 이제 차가워진 커피의 찌꺼기에 다시 사레가 들리기 시작했습니다. 컨설턴트가 "서버를 패치"했을 때 분명히 SunOS 버전을 업그레이드했으며 그렇게 함으로써 Sendmail을 다운그레이드(기존에 설치되어있던 Sendmail 5를 오버라이드하여 SunOS 의 Sendmail 8 가 설치됨)했습니다. 업그레이드는 sendmail.cf가 이제 잘못된 버전의 설정파일이 되었음에도 불구하고 그대로 두었습니다.

Sendmail 5(최소한 Sun이 출시한 버전)는 Sendmail 8 의 sendmail.cf를 처리할 수 있었습니다. 두 버전 사이에서, 대부분의 규칙이 변경되지 않았기 때문입니다. 그러나, 새로운 구성 옵션은 쓰레기로 간주되어 건너뛰었습니다. 그리고 sendmail 바이너리에는 이들 대부분에 대해 설정된 기본값이 없었기 때문에 sendmail.cf 파일에서 적합한 설정을 찾지 못했고 0으로 설정되었습니다.

0으로 설정된 설정 중 하나는 원격지의 SMTP 서버에 연결하는 시간 제한이었습니다. 일부 실험에서는 일반적인 로드가 있는 이 특정 시스템에서 제로 타임아웃이 3밀리초가 약간 넘는 시간에 연결 호출을 중단한다는 사실을 확인했습니다.

당시 우리 캠퍼스 네트워크의 특이한 점은 100% 스위치였다는 것입니다. 발신 패킷은 POP에 도달하기 전이나, 라우터가 굉장히 멀지만 않으면 라우터 지연이 거의 없었습니다. 따라서 근처 네트워크에서 로드가 적은 원격 호스트에 연결하는 데 걸리는 시간에는 부수적인 라우터 지연은 영향을 거의 주지 않습니다. 거의 빛의 속도에 가까운 속도로 통신하므로, 이는 대상까지의 거리에 좌우되는 요소였습니다.

약간 현기증이 나서, 쉘에 다음을 입력했습니다.

$ units
1311 units, 63 prefixes

You have: 3 millilightseconds
You want: miles
        * 558.84719
        / 0.0017893979

'500마일, 어쩌면 조금 더.'