배달되지 않은 메일 헤더(반송된 메일) 구문 분석

배달되지 않은 메일 헤더(반송된 메일) 구문 분석

내 서버로 다시 전송된 반송된(배달할 수 없는) 이메일의 헤더를 구문 분석하고 소프트 바운스인지 하드 바운스인지 확인하는 가장 좋은 방법은 무엇입니까?

내 사용자에게만 동의 이메일을 보내지만 가끔 일부 이메일 주소가 유효하지 않은 경우가 있습니다. 이메일이 내 서버로 반송되면 반송된 이유(소프트/하드)를 찾고 싶습니다. 그런 다음 내 데이터베이스에서 이를 적절하게 처리하거나 다음에 로그인할 때 이메일을 업데이트하도록 사용자에게 플래그를 지정할 수 있습니다.

저는 Ubuntu와 Postfix를 사용하고 있습니다. 별칭과 가상 별칭을 사용하여 VERP를 성공적으로 구현했습니다. 따라서 반송된 이메일의 반환 경로는 다음과 같습니다.[이메일 보호됨], 스크립트로 파이프할 수 있습니다.

이제 VERP 설정이 완료되었으므로 원본 이메일이 누구에게 전송되었는지 알 수 있지만 반환된 메일 헤더를 분석하여 소프트 바운스인지 하드 바운스인지 파악해야 합니다.

이 문제를 처리하는 가장 좋은 방법은 무엇입니까? 내가 이해하는 바에 따르면 모든 메일 서버가 동일한 규칙에 따라 작동하는 것은 아니며 헤더는 다양한 형식을 가질 수 있습니다. 이러한 유형의 것들을 추적하는 오픈 소스 프로젝트가 있습니까? 반송 메일의 대부분을 올바르게 분류하기 위해 구현할 수 있는 간단한 방법은 무엇입니까?

나는 내 메일 서버의 평판을 보호하려고 노력하고 있으므로 어떤 도움이라도 주시면 감사하겠습니다!

답변1

처럼RFC34635로 시작하는 상태 코드는 영구적인 오류에 사용되고 4는 지속적인 일시적 오류에 사용됩니다. 다양한 형식의 여러 메시지를 구문 분석하는 대신 서버 로그에 의존하여 다음과 같이 시도해 볼 수 있습니다.

grep " dsn=5." /var/log/mail.log | grep -o -P " to=<(.+?)>" | sort | uniq -c

이것은 mail.log(Postfix 형식)에서 영구적인 오류를 찾아내고 모든 주소에 대한 주소와 반송 횟수를 제공합니다. "dsn=4"를 사용할 수도 있습니다. 일시적인 오류가 있는 주소를 얻으려면

답변2

일반적으로 바운스에는 두 가지 유형이 있습니다.

  1. 다음으로 인한 바운스직접postfix가 이메일을 전달할 때 원격 메일 서버를 거부합니다.
  2. 원격 서버(접미사 이후의 다음 홉 서버)로 인한 반송으로 인해 최종 수신자에게 메시지가 전달되지 않습니다.

첫 번째 사건은 이미 다루어졌습니다.훌륭한 답변위의 Esa Jokinen이 작성했습니다. 가장 좋은 방법은 메일로그를 구문 분석하는 것입니다.

두 번째 경우는 바운스의 특별한 경우였습니다. 예시 시나리오:

  • 수신자와 함께 이메일을 보냅니다.[이메일 보호됨]에게mail.example.com섬기는 사람.
  • mail.example.com에서는[이메일 보호됨]별칭으로 지정되었습니다.[이메일 보호됨]그리고 다음 주소로 전달해야 합니다.mail.example.net.
  • 언젠가mail.example.net그래서 당신의 메시지를 거부mail.example.com서버에 반송 메일을 보내야 합니다.
  • 불행하게도 서버의 메일로그에는 "dsn=2"가 있을 것입니다.mail.example.com이미 메시지를 수락했지만 다음 사용자에게 전달하지 못했습니다.mail.example.net.

다음은 이메일을 반송하는 두 번째 유형의 예입니다. Yahoo 메일 서버에 전달 규칙이 있습니다.[이메일 보호됨]->[이메일 보호됨]. 불행히도 example.net의 메일 서버는 메시지를 거부합니다 :(

From MAILER-DAEMON  Thu Mar  5 05:07:26 2015
Return-Path: <>
X-Original-To: [email protected]
Delivered-To: [email protected]
Received: from nm21-vm7.bullet.mail.gq1.yahoo.com (nm21-vm7.bullet.mail.gq1.yahoo.com [98.136.217.54])
        (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits))
        (No client certificate requested)
        by mx.example.org (Postfix) with ESMTPS id D6365565FC
        for <[email protected]>; Thu,  5 Mar 2015 05:07:25 +0700 (WIT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=bounce; t=1425506842; bh=zk/tWZNl6c36dmlPDmakM9ekK8cHVJANXMmSdsbkcWc=; h=From:To:Date:Subject:From:Subject; b=Im95h1qTg6qN3yUI7vF1fXtJ0SbUnzv8rUPwLbpNwxGPN2p8wfosXJzQgJ3nzr4L4ZQ50P2d9E9U4jEUNtnyi7nlFd5kKbtiVuda4H56h1PFnt+7wSpgHcd5Irs/lLODumb6ZZSEpCOWttcB9+JLaDfEUUPjGcbR+xww4XeH5Eo=
From: [email protected]
To: [email protected]
Date: Wed, 04 Mar 2015 22:07:22 -0000
Subject: Failure Notice
X-Yahoo-Newman-Property: bmbounce

Sorry, we were unable to deliver your message to the following address.

<[email protected]>:
Remote host said:
550 5.1.1 User unknown
 [RCPT_TO]

이 경우 유일한 방법은 반송 메시지를 구문 분석하는 것입니다. 불행하게도 표준 반송 형식이 없으므로 본문을 구문 분석하고 원인이 거부되었는지 확인해야 합니다.

postfix 바운스 구문 분석 기능 체크리스트:

  1. VERP 주소가 유효한지 확인하세요. 잘못된 메시지를 구문 분석하고 싶지 않습니다.
  2. 본문을 분석하여 소프트 거부인지 하드 거부인지 확인합니다.

두 번째 기능의 경우 Google에서 일반적인 거부 메시지를 검색할 수 있습니다. 그 예는 이렇습니다바운스 정규식 목록.xml~에 의해야쿠브 리스카.


에사 조키넨이 만든아래 댓글의 좋은 점이 두 가지 바운스 유형에 대해 알아보세요. 목표가 서버 평판을 유지하는 것이라면 첫 번째 반송 유형을 처리하는 것으로 충분합니다. 두 번째 바운스는 목록 정리에 관한 것이었습니다. 따라서 죽은 이메일은 지워서 해방되어야 합니다.일부귀하의 서버에 있는 리소스.

PHPlist 및 Mailman과 같은 일부 메일링 목록 관리자는 메일 로그를 분석할 리소스가 없기 때문에 이메일 본문을 분석하여 반송 문제를 처리합니다.

관련 정보