GN⁺: 실종된 기간의 미스터리한 사건
(tjaart.substack.com)이메일 본문에서 사라진 마침표의 미스터리
단순하지 않은 단순 메일 전송 프로토콜
-
Tjaart
- 2024년 2월 20일
문제 발생
- 한 고객에게 보낸 이메일 본문에서 마침표가 사라졌다는 설명을 들음.
- 동일한 이메일을 다른 고객에게 보냈을 때는 마침표가 사라지지 않음.
프로젝트 회상
- 약 7년 전, 문서 템플릿을 단일 시스템으로 통합하는 솔루션을 개발했음.
- 클라이언트는 Microsoft Word 템플릿을 사용하여 문서에 자리 표시자를 넣었음.
- 직원이 이메일로 문서를 보낼 때마다 자리 표시자를 실제 내용으로 교체해야 했음.
템플릿 관리 문제
- 여러 템플릿 버전이 존재하여 관리가 어려웠음.
- 일부 템플릿은 오래된 약관, 로고, 글꼴 등을 사용하고 있었음.
- 중앙에서 모든 템플릿을 관리할 수 있는 솔루션을 개발했음.
솔루션 구현
- 클라이언트는 PDF 문서, 문자 메시지, 이메일 본문을 생성할 템플릿을 중앙에서 관리할 수 있었음.
- 예를 들어, 새로운 고객에게 보내는 환영 편지 템플릿을 설정할 수 있었음.
- 각 전달 방법(이메일, 문자 메시지, 우편)에 따라 다른 템플릿을 구성할 수 있었음.
문제 재현
- 특정 고객에게 보낸 이메일에서만 마침표가 사라지는 문제 발생.
- 템플릿 소스 코드에는 마침표가 포함되어 있었음.
- 로컬 환경에서 이메일 본문을 미리보기 했을 때 마침표가 보였음.
문제 원인 분석
- 이메일 본문을 생성할 때 각 줄의 길이를 제한하는 코드가 있었음.
- 줄이 길이를 초과하면 새로운 줄을 생성하고 나머지 내용을 이동시켰음.
- SMTP 사양에 따르면, 줄이 마침표로 시작하면 추가 마침표를 삽입하고, 서버는 첫 번째 마침표를 삭제함.
해결책
- 코드 수정: 줄이 마침표로 시작하면 추가 마침표를 삽입하여 서버가 삭제해도 마침표가 남도록 함.
- 수정된 코드를 테스트한 결과, 마침표가 사라지지 않음을 확인함.
- 문제를 해결하고 다른 팀에도 버그를 알림.
후속 문제
- 몇 달 후, 다른 팀에서 동일한 버그를 수정하지 않아 중요한 이메일에서 마침표가 사라짐.
- 일부 고객은 새로운 월간 요금이 $27.00 대신 $2700으로 표시된 이메일을 받음.
- 즉시 코드 패치 후 문제 해결.
GN⁺의 의견
- SMTP 사양 이해의 중요성: 이메일 전송 시 발생할 수 있는 문제를 해결하기 위해 SMTP 사양을 깊이 이해하는 것이 중요함.
- 템플릿 관리의 복잡성: 여러 버전의 템플릿을 관리하는 것은 복잡할 수 있으며, 중앙 관리 시스템이 필요함.
- 디버깅 기술: 문제를 재현하고 원인을 분석하는 디버깅 기술이 중요함.
- 팀 간 커뮤니케이션: 문제를 해결한 후 다른 팀과 정보를 공유하는 것이 중요함.
- 자동화된 테스트: 이러한 문제를 방지하기 위해 자동화된 테스트를 도입하는 것이 좋음.
Hacker News 의견
해커뉴스 댓글 모음 요약
-
SMTP 클라이언트 구현의 어려움
- SMTP 클라이언트 구현은 어렵고, 제대로 구현되지 않으면 버그가 발생하기 쉬움. 템플릿 레이어는 SMTP를 신경 쓰지 않아야 함.
- 많은 사람들이 터미널을 통해 기본 프로토콜을 배우지 않아서 이런 문제가 발생함. "단일 점"으로 메시지를 끝내는 규칙은 중요함.
- 많은 프로그래머들이 이스케이핑 개념을 이해하지 못함. "단일 점"을 포함한 이메일을 보내는 상황을 고려하지 않음.
-
독일의 추천서 이야기
- 독일에서는 고용 종료 시 추천서를 받는 것이 일반적임. 추천서의 마지막 문장에 마침표가 없으면 부정적인 의미를 담고 있음.
- 변호사에게 추천서를 검토받았을 때 마지막 문장에 마침표가 없어서 문제가 있었음.
-
크론 잡과 SMTP 클라이언트
- 이메일을 보내는 크론 잡이 자체 SMTP 클라이언트를 구현할 필요가 없음. mailutils 같은 프로그램을 사용하면 됨.
- 기본적인 SMTP 상호작용을 소켓을 통해 구현하는 것은 비효율적임. TLS 연결과 인증이 필요함.
- 크론은 이미 이메일을 보내는 기능을 가지고 있음. MAILTO 변수를 사용해 이메일 주소를 설정할 수 있음.
-
두 가지 나쁜 습관
- 표준을 대충 구현하지 말아야 함. 필요한 주의를 기울이거나 미리 만들어진 라이브러리를 사용해야 함.
- 의존성을 벤더링하지 말아야 함. 라이브러리는 정기적으로 업데이트해야 함. 업데이트를 미루면 큰 문제가 발생할 수 있음.
-
점 스터핑 필요
- SMTP와 POP3에서 점 스터핑이 필요함. 관련 RFC 문서를 참조할 수 있음.
-
HTML MIME 첨부 파일 문제
- "We are happy to welcome you to our family." 문장이 라인 제한에 걸리지 않음. HTML MIME 첨부 파일일 가능성이 있음.
- HTML을 무작정 라인으로 나누면 태그가 깨질 수 있음.
-
첫 번째 문자가 점인 경우
- 첫 번째 문자가 점이고 다른 문자가 있는 경우 첫 번째 문자가 삭제됨. 단일 점이 메일의 끝을 의미하기 때문임.
- 왜 점을 삭제하는지 이해하기 어려움. 다음 문자를 확인하기 위해 한 바이트를 저장할 수 있음.
-
버그 패치 알림
- SMTP 클라이언트 코드가 이전 프로젝트에서 가져온 것이라 다른 팀에게 버그를 알림.
- 다른 팀이 이 버그를 패치하지 않았을 가능성이 있음.
-
NNTP 서버 구현 경험
- RFC 사양을 기반으로 NNTP 서버를 구현하면서 점 스터핑 문제를 바로 이해함. 80년대 프로토콜임.