배달되지 않은 메일 헤더 구문 분석 (바운스 된 메일)


9

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

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

우분투와 Postfix를 사용하고 있습니다. 별칭과 가상 별칭으로 VERP를 성공적으로 구현했습니다. 따라서 반송 된 이메일의 반송 경로는 bounce+OrigEmailAddress@example.com 이며 스크립트로 파이프 할 수 있습니다.

VERP 설정이 완료되었으므로 원래 이메일을 보낸 사람을 알고 있지만 반송 메일 헤더를 구문 분석하여 소프트 바운스인지 하드 바운스인지 알아 내야합니다.

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

메일 서버의 평판을 보호하려고하므로 도움을 주시면 감사하겠습니다.

답변:


9

RFC3463에서 설명하는 것처럼 5로 시작하는 상태 코드는 영구 오류에 사용되고 4는 영구적 인 일시적 오류에 사용됩니다. 다른 형식으로 여러 메시지를 구문 분석하는 대신 서버 로그를 사용하여 다음과 같이 시도 할 수 있습니다.

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

이것은 mail.log (Postfix 형식)에서 영구적 인 오류를 발견하고 모든 주소에 대한 주소와 바운스 양을 제공합니다. "dsn = 4"를 사용할 수도 있습니다. 일시적인 오류가있는 주소를 가져옵니다.


고마워요! postfix가 메일 로그에 그 정보를 가지고 있다는 것을 몰랐습니다. 이것이 당신이 사용하는 솔루션입니까? 접미사가 하드 바운스 dsn = 5를 올바르게 분류한다는 것을 알고 있습니까? 일부 메일 서버가 RFC를 준수하지 않는다는 것을 읽었습니다. 그래서 더 복잡한 해결책이 필요할 것이라고 생각했습니다. 당신의 경험은 무엇입니까? 우리가 postfix를 올바르게 시험해 볼 수 있다면 이것은 좋은 해결책 인 것 같습니다 :-)
Richard

정말 유용한 스크립트-감사합니다! grep의 -P 플래그 (Mac 사용자 등)의 대안에 대한 레시피 : unix.stackexchange.com/a/437694/275762 grep " dsn=5." /var/log/mail.log | pcregrep -o1 " to=<(.+?)>" | sort | uniq -c
Peter M.

8

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

  1. 접미사가 전자 메일을 배달 할 때 원격 메일 서버 를 직접 거부 하여 반송됩니다 .
  2. 원격 서버 (후위 수정 후 다음 홉 서버)로 인해 반송 메일이 최종 수신자에게 메시지를 전달하지 못합니다.

첫 번째 사례는 이미 Esa Jokinen의 훌륭한 답변 으로 이미 다루어졌습니다 . 가장 좋은 방법은 메일 로그를 파싱하는 것입니다.

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

  • 수신자 fakemail@example.com 이있는 이메일 을 mail.example.com 서버로 보냅니다.
  • mail.example.com에서 fakemail@example.com 별칭 된 realmail@example.net 과에 전달해야 mail.example.net .
  • 언젠가 mail.example.net 은 메시지를 거부하므로 mail.example.com 은 서버에 반송 메일을 보내야합니다.
  • mail.example.com이 이미 메시지를 수락했지만 mail.example.net 으로 전달하지 못했기 때문에 서버의 maillog에 "dsn = 2" 가 있습니다 .

두 번째 유형의 예는 이메일을 반송합니다. 전달 규칙 Yahoo 메일 서버 myuser@yahoo.com-> myuser@example.net이 있습니다. 불행히도 example.net의 메일 서버는 메시지를 거부합니다 :(

From MAILER-DAEMON  Thu Mar  5 05:07:26 2015
Return-Path: <>
X-Original-To: noreply-myuser=yahoo.com@example.org
Delivered-To: noreply-263462085117-1425506829-myuser=yahoo.com@example.org
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 <noreply-263462085117-1425506829-myuser=yahoo.com@example.org>; 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: MAILER-DAEMON@yahoo.com
To: noreply-263462085117-1425506829-myuser=yahoo.com@example.org
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.

<myuser@example.net>:
Remote host said:
550 5.1.1 User unknown
 [RCPT_TO]

이 경우 유일한 방법은 바운스 메시지를 파싱하는 것입니다. 불행히도 표준 바운스 형식이 없으므로 본문을 파싱하고 거부를 결정해야합니다.

접미사 바운스 구문 분석의 기능 점검 목록 :

  1. VERP 주소가 유효한지 확인하십시오. 잘못된 메시지를 파싱하고 싶지 않습니다.
  2. 몸을 구문 분석하고 연질 또는 경질 거부인지 확인하십시오.

두 번째 기능의 경우 일반적인 거부 메시지를 Google에 표시 할 수 있습니다. 예는 이쪽 반송 정규식-list.xml 의해 야쿱리스 카 .


Esa Jokinen은이 두 가지 바운스 유형에 대해 아래 의견에서 좋은 지적을했습니다 . 목표가 서버 평판을 유지하는 경우 첫 번째 바운스 유형을 처리하는 것으로 충분합니다. 두 번째 바운스는 목록 정리에 관한 것입니다. 따라서 죽은 전자 메일을 지워 서버의 일부 리소스 를 비워야 합니다.

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


1
이 솔루션은 다른 주소로 자동 전달되는 메일도 처리해야하는 경우 유용하고 더욱 철저합니다. 그러나 메일 서버의 평판을 보호하는 것이 목표라면 직접 거부를 처리하는 것으로 충분합니다. 전달 MTA 관리자는 오래된 전달 및 메일 목록을 제거하여 평판을 보호하고 불필요한 트래픽을 피해야합니다. 그 후 우리는 사례 1로 돌아 왔습니다. 2 차 바운스의 양이 많은 경우 OP에서이 솔루션을 사용해야합니다. 적은 노력이 필요합니다.
Esa Jokinen

@masegaloeh, 정보 주셔서 감사합니다! 나는 그 전달 상황을 가능성으로 생각조차하지 않았다! 지금은 주로 메일 서버의 담당자를 보호하는 데 관심이 있지만 바운스가 증가하면 매우 유용 할 수 있습니다.
Richard
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.