Apa perbedaan perilaku antara jalur balik, balasan ke dan dari?

162

Pada aplikasi surat kami, kami mengirim email dengan tajuk berikut:

FROM: marketing@customer.com
TO: subscriber1@domain1.com
Return-PATH: bouncemgmt@ourcompany.com

Masalah yang kita hadapi adalah beberapa server email akan segera mengembalikan pesan dan menggunakan jalur dari atau sebaliknya (marketing@customer.com) sebagai gantinya ke server mgmt bouncing kami. Kami ingin tahu apakah kami memodifikasi di header jawaban untuk sama dengan jalur balik jika kami dapat menangkap semua bouncing.

Ada ide lain yang disambut?

Kami menggunakan dokumen-dokumen berikut sebagai referensi: VERP RFC Bounce Messages

Parsing Log SMTP untuk mendapatkan Bouncing

EDIT 1: Beberapa bit informasi lagi untuk melihat apakah kita dapat memperoleh tekad ini.

Kami ingin tahu pada titik mana server email yang menyampaikan pesan akan memilih untuk menggunakan jalur balasan versus jalur pengembalian. Kami telah memperhatikan bahwa ketika server smtp pertama menyampaikan pesan ditolak, ia mengirimkannya ke reply-to, tetapi ketika itu terjadi setelah satu hop mengirimkannya ke jalur kembali.

— Geo
sumber

1

Bagaimana dengan menentukan bidang Pengirim: dan Diutamakan:? Saya ingin tahu lebih banyak tentang bagaimana mereka mempengaruhi server mail yang berbeda ketika datang ke bouncing dan keluar dari autoreplies tipe kantor. Siapa saja?

— PapaFreud

postmastery.com/blog/about-the-return-path-header

— Akuntan

257

Mari kita mulai dengan contoh sederhana. Katakanlah Anda memiliki daftar email, yang akan mengirimkan konten RFC2822 berikut .

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.

Sekarang, katakanlah Anda akan mengirimkannya dari milis, yang mengimplementasikan VERP (atau mekanisme pelacakan bouncing lain yang menggunakan jalur pengembalian yang berbeda). Katakanlah ia akan memiliki jalur kembali coolstuff-you=yourcompany.com@mymailinglist.com. Sesi SMTP mungkin terlihat seperti:

{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

Di mana {C} dan {S} masing-masing mewakili perintah Klien dan Server.

Surat penerima akan terlihat seperti:

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.

Sekarang, mari kita gambarkan "FROM" yang berbeda.

Jalur balik (kadang-kadang disebut jalur balik, pengirim amplop, atau amplop dari - semua istilah ini dapat digunakan secara bergantian) adalah nilai yang digunakan dalam sesi SMTP dalam MAIL FROMperintah. Seperti yang Anda lihat, ini tidak perlu nilai yang sama dengan yang ditemukan di header pesan. Hanya server email penerima yang seharusnya menambahkan header Jalur-Kembali ke bagian atas email. Ini mencatat pengirim Jalur yang sebenarnya selama sesi SMTP. Jika header Jalur Kembali sudah ada dalam pesan, maka header itu dihapus dan diganti oleh server email penerima.

Semua pantulan yang terjadi selama sesi SMTP harus kembali ke alamat Jalur Kembali. Beberapa server dapat menerima semua email, dan kemudian mengantri secara lokal, hingga memiliki utas gratis untuk mengirimkannya ke kotak surat penerima. Jika penerima tidak ada, itu harus memantulkannya kembali ke nilai Path yang dikembalikan.

Catatan, tidak semua server email mematuhi aturan ini; Beberapa server email akan memantulkannya kembali ke alamat FROM.

Alamat FROM adalah nilai yang ditemukan di header FROM. Ini seharusnya adalah siapa pesannya DARI. Ini adalah apa yang Anda lihat sebagai "DARI" di sebagian besar klien email. Jika email tidak memiliki tajuk Balas-Ke, maka semua balasan manusia (klien email) harus kembali ke alamat FROM.
Header Balas-Ke ditambahkan oleh pengirim (atau perangkat lunak pengirim). Di sinilah semua balasan manusia juga harus ditangani. Pada dasarnya, ketika pengguna mengklik "balasan", nilai Balas-Ke harus menjadi nilai yang digunakan sebagai penerima email yang baru dikomposisikan. Nilai Balas-Ke tidak boleh digunakan oleh server mana pun. Ini dimaksudkan hanya untuk penggunaan sisi klien (MUA).

Namun, seperti yang Anda tahu, tidak semua server email mematuhi standar atau rekomendasi RFC.

Semoga ini bisa membantu membereskan semuanya. Namun, jika saya melewatkan sesuatu, beri tahu saya, dan saya akan mencoba menjawab.

— dave wanta
sumber

Ini sangat membantu. Terima kasih atas waktunya. Satu pertanyaan. Mungkinkah beberapa bouncing akan menuju ke reply-to bukannya kembali-path?

— Geo

5

baik, secara teknis Anda dapat (tetapi tidak seharusnya) menambahkan header jalur-kembali, namun, jika header jalur-kembali ada, itu akan ditimpa oleh server smtp penerima. Jika tidak ada, itu harus ditambahkan di bagian atas header.

— dave wanta

7

Saya agak tidak jelas tentang bagaimana return-pathdigunakan. Jika return-pathdimaksudkan sebagai alamat pengirim, mengapa server email penerima akan mengisi kolom ini sebagai ganti pengirim? Bagaimana server penerima tahu apa yang harus dimasukkan ke sana? Bukankah ini kelihatannya terbalik?

— greatwolf

6

Server email penerima memasukkan header Jalur-Kembali ke dalam pesan dengan menyalin nilai yang diberikan oleh server email pengirim dalam perintah SMTP "MAIL FROM". Bayangkan seorang pegawai di ruang surat membuka surat - mereka melihat alamat pengirim di amplop dan menuliskannya di bagian atas surat (dan membuang amplopnya).

— John Hascall

5

Dan bagaimana Sender:header cocok dengan semua ini?

— Simon East

150

Cara lain untuk berpikir tentang Return-Pathvs Reply-Toadalah membandingkannya dengan surat siput.

Ketika Anda mengirim amplop melalui pos, Anda menentukan alamat pengirim . Jika penerima tidak ada atau menolak email Anda, kepala kantor pos mengembalikan amplop ke alamat pengirim. Untuk email, alamat pengirim adalah Return-Path.

Di dalam amplop mungkin berupa surat dan di dalam surat itu mungkin mengarahkan penerima untuk "Kirim korespondensi ke alamat contoh ". Untuk email, alamat contohnya adalah Reply-To.

Intinya, Alamat Pengembalian Pos sebanding dengan Return-Pathtajuk SMTP dan tajuk SMTP Reply-Toserupa dengan instruksi balasan yang terkandung dalam surat.

— Jesse Hobart
sumber

14

Ini analogi yang bagus.

— Lukasz Korzybski

2

@Jesse Hobart +1 untuk penjelasan yang bagus, saya lebih bingung terima kasih karena membuatnya lebih mudah untuk mengerti saya.

— Abhishek

26

Saya akan menunjukkan bahwa konsep utama yang tidak ditangkap dalam analogi ini adalah bahwa Return-Pathheader ditambahkan oleh server email penerima dan bukan oleh pengirim . Jadi lebih seperti ini: Anda dapat menulis alamat apa pun yang Anda inginkan di dalam amplop, tetapi untuk mengirimkannya Anda harus membawanya ke kantor pos dan menunjukkan kepada mereka SIM (atau ID lain) dan mereka memasukkan alamat itu di amplop sebelum mengirimnya. Dengan kata lain, Return-Pathheader sama tepercayainya dengan pemeriksaan yang dilakukan oleh server SMTP penerima, di mana yang lainnya dapat dengan mudah dipalsukan.

— cdhowie

5

bagi mereka yang tiba di sini karena judul pertanyaan:

Saya menggunakan Reply-To:alamat dengan formulir web. ketika seseorang mengisi formulir, halaman web mengirim email otomatis ke pemilik halaman. itu From:adalah alamat pengirim surat otomatis, jadi pemilik tahu itu dari formulir web. tetapi Reply-To:alamatnya adalah yang diisi dalam formulir oleh pengguna, sehingga pemilik dapat menekan balasan untuk menghubungi mereka.

— robotik
sumber

1

Saya harus menambahkan header Jalur-Kembali dalam email yang dikirim oleh instance Redmine. Saya setuju dengan greatwolf hanya pengirim yang dapat menentukan Jalur Pengembalian yang benar (tidak standar). Kasusnya adalah sebagai berikut: Email dikirim dengan alamat email default: admin@yourcompany.com Tapi kami ingin pengguna sebenarnya yang memulai tindakan menerima bouncing email, karena ia akan menjadi orang yang mengetahui cara memperbaiki email penerima yang salah (dan bukan administrator aplikasi yang memiliki cambuk kucing lain :-)). Kami menggunakan ini dan berfungsi dengan baik dengan exim di server aplikasi dan zimbra sebagai server email perusahaan terakhir.

— Tersenyum
sumber