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.