Phân tích tiêu đề thư chưa được gửi (thư bị trả lại)


9

Cách tốt nhất để phân tích các tiêu đề của email bị trả lại (không gửi được) được gửi trở lại máy chủ của tôi và xác định xem đó là một thư bị trả lại mềm hay cứng?

Tôi chỉ gửi email chọn tham gia cho người dùng của mình, nhưng đôi khi một số địa chỉ email bị cũ. Khi một email bị trả về máy chủ của tôi, tôi muốn tìm lý do tại sao nó bị trả lại (mềm / cứng). Sau đó, tôi có thể xử lý nó một cách thích hợp trong cơ sở dữ liệu của mình và / hoặc gắn cờ người dùng cập nhật email của họ khi đăng nhập tiếp theo.

Tôi đang sử dụng Ubuntu và Postfix. Tôi đã thực hiện thành công ĐỘNG TỪ với các bí danh và bí danh ảo. Vì vậy, các email bị trả lại có đường dẫn trả về nảy +OrigEmailAddress@example.com và tôi có thể chuyển chúng thành một tập lệnh.

Bây giờ tôi đã thiết lập VERP, tôi biết email gốc được gửi cho ai, nhưng tôi cần phân tích các tiêu đề thư được trả lại để tìm hiểu xem đó là một thư bị trả lại mềm hay bị trả lại cứng.

cách tốt nhất để xử lý này là gì? Theo tôi hiểu, không phải tất cả các máy chủ thư đều chơi theo cùng một quy tắc và các tiêu đề có thể có nhiều định dạng khác nhau. Có một số dự án nguồn mở theo dõi các loại điều này không? Một cái gì đó đơn giản tôi có thể thực hiện sẽ phân loại phần lớn các lần thoát đúng?

Tôi đang cố gắng bảo vệ danh tiếng của máy chủ thư của mình, vì vậy mọi sự trợ giúp đều được đánh giá cao!

Câu trả lời:


9

Như RFC3463 giải thích, mã trạng thái bắt đầu bằng 5 được sử dụng cho các lỗi vĩnh viễn và 4 cho các lỗi tạm thời liên tục. Thay vì cố phân tích một số thư với các định dạng khác nhau, bạn có thể dựa vào nhật ký máy chủ và thử một cái gì đó như thế này:

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

Điều này sẽ tìm thấy các lỗi vĩnh viễn từ mail.log (định dạng Postfix) và cung cấp địa chỉ cũng như số lần thoát trên mỗi địa chỉ. Bạn cũng có thể sử dụng "dsn = 4." để có được địa chỉ với các lỗi tạm thời.


Cảm ơn Esa! Tôi đã không nhận ra rằng postfix có thông tin đó trong nhật ký thư. Đây có phải là giải pháp mà bạn sử dụng? Bạn có thấy rằng postfix phân loại chính xác các số bị trả lại DSN = 5 không? Tôi đã đọc được rằng một số máy chủ thư không tuân thủ RFC. Vì vậy, tôi nghĩ rằng một giải pháp phức tạp hơn có thể được yêu cầu. đã kinh nghiệm của bạn là gì? Đây có vẻ là một giải pháp tốt nếu chúng ta có thể kiểm tra hậu tố để làm cho đúng :-)
Richard

Kịch bản thực sự hữu ích - cảm ơn bạn! Công thức ở đây để thay thế cho cờ -P của grep (đối với người dùng Mac, v.v.): unix.stackexchange.com/a/437694/275762 grep " dsn=5." /var/log/mail.log | pcregrep -o1 " to=<(.+?)>" | sort | uniq -c
Peter M.

8

Nói chung có hai loại bị trả lại

  1. Bounce gây ra bởi sự từ chối trực tiếp của máy chủ thư từ xa khi postfix của bạn gửi email.
  2. Các thư bị trả lại do máy chủ từ xa (máy chủ hop-hop sau postfix của bạn) không gửi được tin nhắn đến người nhận cuối cùng.

Trường hợp đầu tiên đã được bao phủ bởi câu trả lời xuất sắc của Esa Jokinen ở trên. Đặt cược tốt nhất của bạn là phân tích cú pháp maillog.

Trường hợp thứ hai là trường hợp đặc biệt bị trả lại. Kịch bản ví dụ:

  • Bạn gửi email với người nhận fakemail@example.com đến máy chủ mail.example.com .
  • Trong mail.example.com, fakemail@example.com được đặt bí danh là realmail@example.net và phải được chuyển tiếp đến mail.example.net .
  • Một ngày nào đó mail.example.net từ chối thư của bạn để mail.example.com phải gửi thư đến máy chủ của bạn.
  • Thật không may, maillog trong máy chủ của bạn sẽ có "dsn = 2" vì mail.example.com đã chấp nhận thư nhưng không chuyển tiếp được đến mail.example.net .

Ở đây ví dụ về loại email bị trả lại. Có quy tắc chuyển tiếp máy chủ thư Yahoo myuser@yahoo.com -> myuser@example.net . Thật không may, máy chủ mail của example.net từ chối thư :(

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]

Trong trường hợp này, phương pháp duy nhất của bạn là phân tích cú pháp tin nhắn bị trả lại. Thật không may, không có định dạng bị trả lại tiêu chuẩn, vì vậy bạn phải phân tích cú pháp cơ thể và xác định sự từ chối gây ra.

Danh sách kiểm tra tính năng của phân tích cú pháp trả lại hậu tố của bạn:

  1. Kiểm tra xem địa chỉ VERP có hợp lệ không. Bạn không muốn phân tích tin nhắn không hợp lệ.
  2. Phân tích cơ thể, xác định xem chúng là loại bỏ mềm hay cứng.

Đối với tính năng thứ hai, bạn có thể google một số thông báo từ chối phổ biến. Ví dụ là tệp nảy-regex-list.xml này của Jakub Liska .


Esa Jokinen đã đưa ra một điểm tốt trong bình luận dưới đây về hai loại nảy này. Nếu mục tiêu của bạn là giữ uy tín cho máy chủ, thì việc xử lý loại thoát đầu tiên là đủ. Lần thoát thứ hai là về việc làm sạch danh sách của bạn. Vì vậy, email chết nên được xóa để giải phóng một số tài nguyên trong máy chủ của bạn.

Một số người quản lý danh sách gửi thư như PHPlist và Mailman cũng giải quyết vấn đề thoát này bằng cách phân tích cơ thể email vì họ không có tài nguyên để phân tích cú pháp maillog.


1
Giải pháp này hữu ích và kỹ lưỡng hơn nếu cần xử lý các thư cũng tự động chuyển tiếp đến địa chỉ khác. Tuy nhiên, nếu mục tiêu là bảo vệ danh tiếng của máy chủ thư, xử lý các từ chối trực tiếp là đủ. Quản trị viên của MTA chuyển tiếp nên xóa các danh sách chuyển tiếp và thư đã lỗi thời (để bảo vệ danh tiếng của họ và để tránh lưu lượng không cần thiết). Sau đó, chúng tôi trở lại trong trường hợp một. OP nên sử dụng giải pháp này nếu số lần thoát thứ cấp là đáng kể. Mà bao giờ mất ít nỗ lực.
Esa Jokinen

@masegaloeh, cảm ơn thông tin! Tôi thậm chí đã không coi tình huống chuyển tiếp đó là một khả năng! Hiện tại tôi chủ yếu quan tâm đến việc bảo vệ đại diện của máy chủ thư của mình, nhưng nếu số lần tăng tăng thì điều này có thể rất hữu ích.
Richard
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.