메일 링 애플리케이션에서 다음 헤더가 포함 된 이메일을 보냅니다.
FROM: marketing@customer.com
TO: subscriber1@domain1.com
Return-PATH: bouncemgmt@ourcompany.com
우리가 겪고있는 문제는 일부 이메일 서버가 메시지를 즉시 반송하고 반송 반송 서버 (from bounce mgmt server) 대신 발신 또는 역방향 경로 (marketing@customer.com)를 사용한다는 것입니다. 모든 바운스를 잡을 수 있다면 헤더에서 회신을 리턴 경로와 동일하게 수정하는지 알고 싶습니다.
다른 아이디어는 환영받을까요?
다음 문서를 참조로 사용하고 있습니다.
VERP
RFC
반송 메시지
편집 1 : 우리 가이 해결을 얻을 수 있는지 확인하기위한 몇 가지 추가 정보.
메시지를 릴레이하는 전자 메일 서버가 회신 대 반환 경로를 사용하기로 선택한 시점을 알고 싶습니다. 메시지를 릴레이하는 첫 번째 smtp 서버가 거부되면 답장으로 보내지 만 한 번의 홉 후에 발생하면 리턴 경로로 보냅니다.
답변
간단한 예부터 시작하겠습니다. 다음 RFC2822 컨텐츠 를 발송할 이메일 목록이 있다고 가정하십시오 .
From: <coolstuff@mymailinglist.com> To: <you@yourcompany.com> Subject: Super simple email Reply-To: <coolstuff-threadId=123@mymailinglist.com> This is a very simple body.
이제 메일 링리스트에서 VERP (또는 다른 리턴 경로를 사용하는 다른 바운스 추적 메커니즘)를 구현하는 메일 링리스트에서 전송한다고 가정 해 보겠습니다 . 반환 경로가이라고 가정하겠습니다 coolstuff-you=yourcompany.com@mymailinglist.com
. SMTP 세션은 다음과 같습니다.
{S}220 workstation1 Microsoft ESMTP MAIL Service {C}HELO workstation1 {S}250 workstation1 Hello [127.0.0.1] {C}MAIL FROM:<coolstuff-you=yourcompany.com@mymailinglist.com> {S}250 2.1.0 me@mycompany.com....Sender OK {C}RCPT TO:<you@yourcompany.com> {S}250 2.1.5 you@yourcompany.com {C}DATA {S}354 Start mail input; end with <CRLF>.<CRLF> {C}From: <coolstuff@mymailinglist.com> To: <you@yourcompany.com> Subject: Super simple email Reply-To: <coolstuff-threadId=123@mymailinglist.com> This is a very simple body. . {S}250 Queued mail for delivery {C}QUIT {S}221 Service closing transmission channel
여기서 {C} 및 {S}는 각각 클라이언트 및 서버 명령을 나타냅니다.
받는 사람의 메일은 다음과 같습니다.
Return-Path: coolstuff-you=yourcompany.com@mymailinglist.com From: <coolstuff@mymailinglist.com> To: <you@yourcompany.com> Subject: Super simple email Reply-To: <coolstuff-threadId=123@mymailinglist.com> This is a very simple body.
이제 다른 “FROM”을 설명하겠습니다.
- 반환 경로 (역방향 경로, 봉투 발신자 또는 봉투의 발신자라고도 함)는이
MAIL FROM
명령 의 SMTP 세션에서 사용되는 값 입니다. 보다시피, 이것은 메시지 헤더에있는 것과 같은 값일 필요는 없습니다. 받는 사람의 메일 서버 만 전자 메일 상단에 Return-Path 헤더를 추가해야합니다. SMTP 세션 중에 실제 Return-Path 발신자를 기록합니다. 메시지에 Return-Path 헤더가 이미 있으면 해당 헤더가 제거되고 수신자의 메일 서버로 대체됩니다.
SMTP 세션 중에 발생하는 모든 바운스는 반송 경로 주소로 되돌아 가야합니다. 일부 서버는 모든 전자 메일을 수락 한 다음 수신자의 사서함으로 배달 할 수있는 스레드가 생길 때까지 로컬로 대기시킵니다. 수신자가 존재하지 않으면 수신자는 기록 된 Return-Path 값으로 반송해야합니다.
모든 메일 서버가이 규칙을 준수하는 것은 아닙니다. 일부 메일 서버는이를 FROM 주소로 반송합니다.
-
FROM 주소는 FROM 헤더에있는 값입니다. 이것은 메시지가 보낸 사람이어야합니다. 이것이 대부분의 메일 클라이언트에서 “FROM”으로 표시됩니다. 이메일에 회신 헤더가없는 경우 모든 사람 (메일 클라이언트) 응답은 FROM 주소로 돌아갑니다.
-
회신 헤더는 발신자 (또는 발신자의 소프트웨어)가 추가합니다. 모든 사람의 답변도 다루어야합니다. 기본적으로 사용자가 “답장”을 클릭하면 회신 대상 값은 새로 작성된 전자 메일의 수신자로 사용되는 값이어야합니다. 회신 서버 값을 서버에서 사용해서는 안됩니다. 클라이언트 측 (MUA) 전용입니다.
그러나 알 수 있듯이 모든 메일 서버가 RFC 표준이나 권장 사항을 준수하는 것은 아닙니다.
잘만되면 이것이 문제를 해결하는 데 도움이 될 것입니다. 그러나 내가 놓친 부분이 있으면 알려 주시면 답변을 드리겠습니다.
답변
Return-Path
vs 를 생각하는 또 다른 방법 Reply-To
은 달팽이 메일과 비교하는 것입니다.
우편으로 봉투를 보낼 때 반송 주소 를 지정합니다 . 받는 사람이 없거나 메일을 거부하면 우체국 장이 봉투를 반송 주소로 반송합니다. 이메일의 경우 반송 주소 는 Return-Path
입니다.
봉투의 내부는 문자 일 수 있으며, 문자의 내부는 수신자에게 ” 예제 주소로의 통신문 보내기”를 지시 할 수 있습니다 . 이메일의 경우 주소 예 는 Reply-To
입니다.
본질적으로 우편 반송 주소는 SMTP Return-Path
헤더와 비슷하며 SMTP Reply-To
헤더는 편지에 포함 된 회신 지침과 유사합니다.
답변
질문의 제목 때문에 여기에 온 사람들을 위해 :
Reply-To:
webforms에 주소를 사용 합니다. 누군가 양식을 작성하면 웹 페이지가 자동으로 이메일을 페이지 소유자에게 보냅니다. 는 From:
자동 메일 발신자의 주소이므로 소유자는 해당 주소가 웹 양식에서 온 것임을 알고 있습니다. 그러나 Reply-To:
주소는 사용자가 양식에 기입 한 주소이므로 소유자는 답장을 눌러 연락 할 수 있습니다.
답변
Redmine 인스턴스가 보낸 이메일에 Return-Path 헤더를 추가해야했습니다. 발신자 만 올바른 (기본값이 아닌) Return-Path를 결정할 수있는 greatwolf에 동의합니다. 전자 메일은 기본 전자 메일 주소로 전송됩니다. admin@yourcompany.com 그러나 조치를 시작하는 실제 사용자는 반송 이메일을 수신하기를 원합니다. (및 다른 고양이가 채찍질하는 응용 프로그램 관리자가 아닙니다 :-)). 우리는 이것을 사용하며 응용 프로그램 서버의 exim과 zimbra를 최종 회사 메일 서버로 완벽하게 작동합니다.
답변
