Alasan yang sah SMTP "MAIL FROM:" tidak akan cocok dengan "From:" Header di DATA

Pernahkah ada alasan sah untuk bidang SMTP "MAIL FROM:" untuk tidak cocok dengan bidang "Dari:" di bagian DATA pesan, selain milis?

Dari /programming/1750194/smtp-why-does-email-needs-envelope-and-what-does-the-envelope-mean :

“Tetapi, untuk melanjutkan metafora surat siput Anda, sebagian besar surat profesional akan berisi alamat pengirim dan penerima yang tercetak pada surat itu sendiri. Alamat-alamat itu tidak diperlukan untuk tukang pos, tetapi sebaliknya adalah milik penerima. Jadi masuk akal jika email akan bekerja dengan cara yang sama. "

Masalah dengan garis logika ini terletak di sini: "kesopanan kepada penerima". Memasukkan alamat “Dari:” dalam email melalui SMTP bukanlah rasa hormat; diperlukan jika penerima dapat mengirim balasan.

From: Bagaimana membatasi header From agar cocok dengan MAIL FROM di postfix? :

"Tetapi jika Anda benar-benar ingin memastikan Dari: dan MAIL DARI maka Anda harus menerapkan header_checks sehingga Return-Path: cocok dengan Dari:"

Apa implikasi dari melakukan ini? Milis jelas akan menjadi masalah. Apakah ada kegunaan lain yang berbeda dari informasi header “MAIL FROM:” dan “From:”?

Ada banyak alasan mengapa alamat Header dan Amplop Dari tidak cocok. Sebagian besar menyangkut proses otomatis mengirim surat, di mana masalah pengiriman perlu dilaporkan ke alamat yang tidak mewakili siapa yang mengirim surat, atau siapa yang dikirim atas nama, atau siapa yang harus dijawab. Milis seperti yang Anda tunjukkan adalah contoh yang bagus.

Alasan utama mengapa pesan yang dikirim dari klien email pengguna mungkin berbeda dari alamat adalah email yang diteruskan. Konten surat kemudian harus cukup beriman dengan aslinya, tetapi dalam hal kesalahan pengiriman, itu harus dilaporkan kepada pengguna yang meneruskan email, bukan pengirim asli.

Selain tajuk SMTP, Ada berbagai tajuk MIME yang digunakan berbagai program untuk mencoba membedakan antara pengirim asli, dan pengirim perantara, dan / atau alamat yang disukai untuk melaporkan kesalahan. Misalnya Balas Ke, Pengirim, Asal-Dari , Kesalahan-Untuk, dll, dll, Masing-masing dengan semantik berbeda. Beberapa di antaranya memiliki dukungan standar, sementara banyak lagi yang tidak, tetapi mungkin sedang digunakan. Cara berbagai program email berperilaku sangat bervariasi.

Apakah cara mengalamatkan surat disarankan adalah masalah yang berbeda dari apakah surat itu "sah" seperti yang Anda tanyakan. Jika Anda mempertimbangkan legitimasi di sini dalam hal sesuatu seperti kebijakan untuk menangani potensi spam, maka tidak, saya tidak berpikir Anda akan dapat membuat perbedaan sederhana dengan cara ini.

Pikirkan baik-baik tentang penandatanganan email DKIM, dan otentikasi SPF server email untuk domain email. Jika Anda mengirim banyak surat, mungkin penting untuk dapat mengautentikasi surat Anda dengan cara-cara ini, dan itu mungkin memiliki implikasi untuk pengalamatan surat Dari header, karena Anda hanya dapat mengautentikasi surat yang terkait dengan domain yang Anda miliki otoritasnya. .

-

Diperpanjang berdasarkan permintaan:

Header 'Balas-Ke' MIME mengarahkan MUA (Agen Pengguna Email, biasanya klien email seseorang) untuk mengirim balasan ke alamat yang berbeda, alih-alih alamat MIME 'Dari'. Ini tidak digunakan oleh MTA (Mail Transport Agent) untuk hal-hal seperti kesalahan.

Biasanya MTA akan menggunakan alamat SMTP Envelope 'MAIL From' untuk mengirim kesalahan. TI dapat diganti dengan tajuk 'Kesalahan-Ke' MIME, yang merupakan instruksi MTA. Tidak semua MTA akan menghormatinya, jadi ini merupakan mekanisme yang lebih rendah untuk menetapkan alamat Amplop SMTP, tetapi ada banyak keadaan di mana dimungkinkan untuk mengatur Header MIME dalam sebuah pesan, tetapi bukan alamat SMTP Envelope From. Misalnya perangkat lunak yang berjalan di lingkungan hosting bersama mungkin menemukan dirinya dalam situasi ini.

'Pengirim' jauh lebih ambigu sebagai instruksi kepada agen perangkat lunak, tetapi menunjukkan siapa atau apa yang mengirim email di mana itu berbeda dari alamat Dari yang lebih mirip dengan siapa email dikirim atas nama. Misalnya ketika Anda mengisi formulir mail-on-politisi Anda secara online, akan sangat sesuai untuk email yang dihasilkan untuk menggunakan email Anda di header Dari, tetapi memiliki alamat pengirim yang terkait dengan organisasi yang mengatur formulir.

'Originally-From' digunakan oleh beberapa perangkat lunak MUA saat meneruskan surat, dengan alamat penerusan digunakan untuk header 'Dari'. MUA lain akan meninggalkan alamat From saja, dan menggunakan header 'Resent-From'. Apakah MUA menerima berbagai email tajuk ini menafsirkan tajuk dengan bermanfaat, atau bahkan menampilkannya cukup bervariasi. Saat membalas surat yang telah diteruskan kepada Anda, kepada siapa seharusnya jawaban tersebut dikirim secara default? Mungkin sebaiknya mengatur tajuk 'Balas Ke' itu?

Perilaku MUAS adalah variabel, dan didefinisikan dengan buruk, meskipun tampaknya membaik seiring waktu. Sebaliknya, semantik Amplop jauh lebih jelas. Biasanya ada posisi kuat bahwa MTA seharusnya tidak pernah mementingkan diri mereka sendiri dengan header MIME, tetapi karena MTA semakin bertanggung jawab atas konten surat (mis. Lihat SPF dan standar DMARC yang muncul), ada tekanan untuk kejelasan posisi yang akan terdegradasi. Mekanisme lama seperti Errors-To juga bertentangan dengan gagasan MTA yang tidak melihat konten header, yang merupakan bagian dari mengapa mekanisme tersebut selalu diterapkan secara tidak konsisten. Filosofi penulis perangkat lunak bervariasi.

Anda mungkin menemukan bahwa berguna untuk memeriksa http://tools.ietf.org/html/rfc4021#section-2 , tetapi ingatlah bahwa praktik sebenarnya dari banyak perangkat lunak email di luar sana bervariasi dengan cara yang belum tentu diberkati dengan standar.

Tidak apa-apa untuk mencoba memunculkan filosofi yang jelas tentang bagaimana Anda berpikir surat harus digunakan, tetapi jangan berharap bahwa semua orang akan melakukan hal-hal seperti yang Anda pikirkan.

Pemrosesan otomatis adalah alasan besar. Anda ingin dapat mengirim bouncing / autoreplies / kesalahan untuk diproses secara terpisah, jika tidak pesan tersebut hilang, atau diabaikan, atau beberapa getah miskin harus menggali melalui mereka. Ya, menambahkan header-X untuk diproses adalah mungkin, tetapi banyak waktu memantul / dll. tidak akan menyertakan email asli atau hanya sebagian yang sudah hancur dan Anda tidak akan bisa mendapatkan sumbernya.

Misalnya, katakan seseorang mendaftar di situs web Anda, dan Anda mengirimi mereka email mengucapkan terima kasih karena telah mendaftar. MAILFROM dan Dari Anda mungkin terlihat seperti ini:

MAIL FROM: <[email protected]>
From: Website X <[email protected]>

Dengan cara ini, pengguna melihat "ramah dari" di klien email. Tetapi jika pengguna tidak ada, MTA mereka akan mengirim pesan bouncing ke:

[email protected]

dan proses otomatis dapat dengan mudah menarik userid (bagian 123123123) dan bagian dari sistem yang membuat bouncing (bagian -supup-) dari header dan dengan mudah menghapus / menandai pengguna yang dinonaktifkan.

Email dari: dalam percakapan smtp dirancang untuk menjadi tempat bouncing akan menuju. Judul Dari: di badan pesan digunakan untuk ditampilkan kepada penerima dan sebagai alamat balasan jika header Balas ke: tidak diatur.

Email yang seharusnya tidak menghasilkan pantulan harus menetapkan pengirim kosong di dalam amplop, misalnya tanda terima pengembalian biasanya memiliki: mail from:<>dengan nama pengguna di header dari :.

Situasi lain adalah ketika server email menggunakan BATV untuk menolak bouncing palsu. Email dari: akan dalam bentuk [email protected].

Kecuali jika saya tidak membaca tajuk atau pertanyaan dengan benar, email dari BlackBerry saya dikirim dari server BlackBerry dan pada dasarnya tidak ada satu pun bidang yang cocok. Sebagian kecil pengguna, saya sadari. Saya telah melihat ini baru-baru ini dalam mengevaluasi server email saya. Di bawah ini adalah email anonim yang dikirim dari BlackBerry saya ke akun Gmail saya:

Delivered-To: [email protected]
Received: by 10.50.11.138 with SMTP id q10csp217364igb;
        Wed, 14 Aug 2013 00:18:53 -0700 (PDT)
X-Received: by 10.42.83.84 with SMTP id g20mr4290552icl.10.1376464731205;
        Wed, 14 Aug 2013 00:18:51 -0700 (PDT)
Return-Path: <SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com>
Received: from smtp08.bis6.us.blackberry.com (smtp08.bis6.us.blackberry.com. [74.82.85.8])
        by mx.google.com with ESMTP id lq6si7427361icb.102.2013.08.14.00.18.51
        for <[email protected]>;
        Wed, 14 Aug 2013 00:18:51 -0700 (PDT)
Received-SPF: pass (google.com: domain of SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com designates 74.82.85.8 as permitted sender) client-ip=74.82.85.8;
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com designates 74.82.85.8 as permitted sender) smtp.mail=SRS0=BQ46+U=R3=example.com=senderusername@srs.bis6.us.blackberry.com
Received: from b15.c8.bise6.blackberry ([192.168.0.115])
    by srs.bis6.us.blackberry.com (8.13.7 TEAMON/8.13.7) with ESMTP id r7E7InfH019786
    for <[email protected]>; Wed, 14 Aug 2013 07:18:49 GMT
Received: from 172.29.201.172 (cmp2.c8.bise6.blackberry [172.29.201.172])
    by b15.c8.bise6.blackberry (8.13.7 TEAMON/8.13.7) with ESMTP id r7E7IlCt013236
    for <[email protected]>; Wed, 14 Aug 2013 07:18:47 GMT
X-rim-org-msg-ref-id: 587275596
Message-ID: <587275596-1376464726-cardhu_decombobulator_blackberry.rim.net-631052459-@b17.c8.bise6.blackberry>
Reply-To: [email protected]
X-Priority: Normal
Sensitivity: Normal
Importance: Normal
Subject: Test
To: "Recipient Name" <[email protected]>
From: [email protected]
Date: Wed, 14 Aug 2013 07:18:45 +0000
Content-Type: text/plain
MIME-Version: 1.0

Test
Sent via BlackBerry by AT&T