업무와 관계없는 문의가 갑자기 늘었다면 수신한 메일이 모두 사람이 새로 보낸 질문인지부터 확인합니다. 노무·행정 사무소의 공용 문의함에 ‘자리를 비웠습니다’ 같은 답장이 계속 도착하는 상황이라면, 검색 글이 잘못된 기대를 만들었다는 해석에 앞서 자동 응답끼리 이어진 대화인지 살펴볼 수 있습니다. 이때 고칠 대상은 서비스 소개의 범위가 아니라 메일을 신규 문의로 세는 방식과 자동 회신의 동작일 수 있습니다.
다음은 원리를 설명하기 위한 가정입니다. 사무소의 접수 알림에 상대방의 부재중 답장이 돌아왔고, 문의함이 그 답장에도 접수 알림을 다시 보냅니다. 상대편이 또 자동으로 응답한다면 사람이 새로운 질문을 쓰지 않아도 수신 목록은 늘어납니다. 실제 사무소에서 발생한 사례나 모든 메일 서비스의 기본 동작을 설명하는 것은 아닙니다. 같은 제목이 반복됐다는 이유만으로 이런 왕복이 있었다고 확정해서도 안 됩니다.
메일 담당자에게는 원문 보기에서 자동 생성 여부와 답장 관계를 확인해 달라고 요청할 수 있습니다. IETF RFC 3834는 자동으로 회신한 메시지에 Auto-Submitted의 auto-replied 값을 표시하도록 권고합니다. 원래 메일과의 연결을 나타내는 In-Reply-To와 References도 답장 관계를 살피는 단서입니다. 제목의 ‘답장’ 표시만 보는 것보다 어떤 메시지에 대한 자동 응답인지 확인할 수 있습니다. 다만 이런 표기를 발신자의 신원이나 내용의 진실성을 보증하는 인증으로 취급하지 않습니다.
검토에서는 사람이 작성한 첫 문의와 이후 자동 답장을 한 줄의 시간 흐름으로 놓습니다. 사무소의 어느 자동 안내 뒤에 부재중 응답이 왔고, 그것이 다시 어떤 안내를 발생시켰는지 확인합니다. 실제 연결 근거가 없는 메일까지 제목이 비슷하다는 이유로 합치지 않습니다. 수신 시각과 메시지 관계로 충분하다면 사건 내용이나 첨부 서류를 분석표에 복사할 이유도 없습니다. 원문은 업무상 허용된 위치에서 확인하고 점검표에는 필요한 구분만 남깁니다.
자동으로 만들어진 메일을 전부 문의에서 빼는 규칙도 적절하지 않습니다. 홈페이지에 사람이 남긴 질문을 시스템이 메일로 알려 주는 경우처럼, 자동 알림 안에 실제 신규 요청이 들어 있을 수 있습니다. 분리하려는 것은 기계가 발송했다는 형식 전체가 아니라 이미 보낸 안내에 되돌아온 자동 응답입니다. 새 질문을 전달하는 알림과 부재중 통지를 구별하지 않으면 반복 수신을 줄이는 과정에서 정상 문의를 놓칠 수 있습니다.
왕복이 확인됐다면 자동 회신 담당자는 어떤 종류의 수신에 다시 답하도록 되어 있는지 살핍니다. RFC 3834는 Auto-Submitted 값이 no가 아닌 메시지에 자동 응답하지 않는 방향을 권고합니다. 실제 적용은 사용 중인 메일 서비스와 사무소의 응대 절차에 맞춰 담당자가 검토해야 합니다. 모든 알림을 끄거나 특정 발신 주소를 통째로 차단하는 제안으로 바로 넘어가지 않습니다. 같은 주소에서 필요한 새 문의도 올 수 있기 때문입니다.
수정 결과를 볼 때에는 정상 문의가 담당자에게 도착하는지와 자동 답장이 새 왕복을 만들지 않는지를 각각 확인합니다. 시험은 승인된 내부 환경에서 수행하고 외부 고객에게 반복 메일을 보내며 재현하지 않습니다. 받은 메일을 목록에서 정리했다고 최초 문의에 답한 것으로 처리해서도 안 됩니다. 자동 답장 사이에 남아 있는 원래 요청의 처리 상태를 따로 확인해야 합니다.
콘텐츠 보고서에는 확인된 자동 응답 묶음과 실제 요청을 구별한 근거를 남깁니다. 과거 자료에서 구분할 수 없는 건을 모두 고객 문의나 자동 응답으로 밀어 넣지 않습니다. 부적합 문의가 많다는 숫자를 보고 제목을 더 제한적으로 고치기 전에, 그 숫자가 사람의 질문을 세고 있었는지 확인하는 것입니다. 자동 답장 왕복이 원인이었다면 메일 경로의 수정을 기록하고 원래 글의 질문과 제공 범위는 별도 근거로 평가합니다.
확인 자료: IETF RFC 3834, Recommendations for Automatic Responses to Electronic Mail, §§2, 3.1.6–3.1.7, 5.2 https://www.rfc-editor.org/rfc/rfc3834