Penggunaan header SMTP "Pengirim" yang benar?


20

Aplikasi web kami mengirimkan pesan email kepada orang-orang ketika seseorang memposting konten baru. Baik pengirim dan penerima telah memilih menerima pesan email dari aplikasi kami. Saat menyiapkan pesan seperti itu, kami menetapkan tajuk SMTP berikut:

DARI: author@example.com
KEPADA: recipient@example.com
SENDER: webapp@mycompany.com

Kami memilih untuk menggunakan alamat email penulis di header FROM dalam upaya untuk memberikan pengalaman terbaik bagi penerima; ketika mereka melihat pesan di klien email mereka, penulis jelas. Untuk menghindari munculnya spoofing, kami menambahkan header SENDER (dengan alamat email perusahaan kami sendiri) untuk memperjelas bahwa kami mengirim pesan atas nama penulis. Setelah membaca RFC 822 dan 2822, ini tampaknya merupakan tujuan penggunaan header pengirim.

Sebagian besar server email penerima tampaknya menangani ini dengan baik; pesan email dikirim secara normal (dengan asumsi kotak surat penerima ada, tidak melebihi kuota, dll). Namun, saat mengirim pesan DARI alamat di domain KE alamat di domain yang sama, beberapa domain penerima menolak pesan dengan respons seperti:

571 IP salah - psmtp (sebagai balasan untuk perintah RCPT TO)

Saya pikir ini berarti server penerima hanya melihat bahwa alamat header FROM berada di domainnya sendiri, dan bahwa pesan tersebut berasal dari server yang dianggapnya tidak berwenang mengirim pesan untuk domain tersebut. Dengan kata lain, server penerima mengabaikan header SENDER.

Kami memiliki solusi di tempat: webapp menyimpan daftar domain seperti itu yang tampaknya mengabaikan header SENDER, dan ketika header FROM dan TO keduanya dalam domain seperti itu, ia menetapkan header FROM ke alamat email kami sendiri. Tetapi daftar ini membutuhkan pemeliharaan.

Apakah ada cara yang lebih baik untuk mencapai pengalaman yang diinginkan? Kami ingin menjadi "warga negara yang baik" dari jaringan, dan semua pihak yang terlibat - pengirim dan penerima - ingin berpartisipasi dan menerima pesan-pesan ini. Salah satu alternatifnya adalah dengan selalu menggunakan alamat email perusahaan kami di header FROM, dan tambahkan nama / alamat penulis ke subjek, tetapi ini tampaknya agak canggung.


Mengapa tidak menggunakan From: authorbukan From: author@example.com?
Pacerier

Jawaban:


16

Anda melihat hal-hal yang salah. Itulah tajuk pesan . Anda harus melihat amplop SMTP . (Cara amplop ditentukan tergantung dari bagaimana, tepatnya, aplikasi Anda mengirimkan surat ke sistem surat. Pada banyak sistem amplop ditentukan oleh argumen baris perintah ke program utilitas pengiriman surat.) Tergantung dari kapan tepatnya dalam transaksi protokol ia memutuskan untuk mengeluarkan respons 571 itu, server SMTP Relay mungkin bahkan tidak melihat header pesan sama sekali.

Teks respons mengatakan bahwa administrator server SMTP Relay tertentu yang Anda ajak bicara telah membatasi apa yang dapat Anda masukkan ke dalam amplop SMTP. Tampaknya mengeluh tentang bagian penerima amplop. Tetapi mungkin menunda validasi pengirim amplop sampai spesifikasi penerima pertama, sehingga mungkin mengeluhkan pengirim.

Perhatikan bahwa pengirim amplop adalah tempat pengiriman pesan status pengiriman, dan Anda tidak akan menginginkannya diarahkan ke orang-orang acak di seluruh dunia. (Selain dari kenyataan bahwa banyak orang tidak suka ini, tidak masuk akal untuk pengiriman pesan status agar surat Anda dikembalikan kepada siapa pun kecuali Anda.) Tetapkan diri Anda sebagai pengirim amplop.

MXOmong-omong, memerlukan catatan sumber daya. Server Relay SMTP dapat ditemukan oleh Adan AAAAcatatan sumber daya jika tidak ada MXcatatan sumber daya apa pun . Lihat RFC 5321 § 5.1.


Saya memeriksa RFC sebelum mengimplementasikan pemeriksaan MX record, dan mempelajari hal yang sama: memeriksa fallback A record dengan tidak adanya MX record. Saya akan melihat ke dalam amplop SMTP; Terima kasih untuk sarannya.
Eric Rath

Saya meneliti amplop SMTP, menguji ini. Anda benar - saya salah berasumsi bahwa semua pemeriksaan awal akan menggunakan tajuk pesan "Dari", tetapi sepertinya amplop yang digunakan.
Eric Rath

5

Saya mungkin salah, tetapi kemungkinan penyebab kesalahan di atas, terutama dalam kasus Postini, adalah bahwa domain di mana Anda ditolak memiliki kebijakan SPF yang ketat. Sebagian besar server email dengan pemeriksaan SPF hanya akan memeriksa header Dari:, mereka tidak akan peduli dengan header Pengirim.

Untuk memeriksa apakah ini yang menjalankan "dig + TXT domain.com" singkat di mana domain.com adalah apa yang memberi Anda pesan kesalahan. Anda harus mendapatkan sesuatu seperti:

"v = spf1 mx -semua"

Bagian yang penting adalah -semua. Ini berarti bahwa pemilik domain telah menyatakan bahwa mereka hanya akan mengirim email dari server yang bertindak sebagai server email mereka, semua email lain akan ditolak.

Untungnya, jika ini masalahnya, Anda dapat secara aktif memeriksa sebelum mengirim email! Dapatkan WebApp untuk melakukan pemeriksaan SPF ketika pengguna memasukkan alamat email mereka. Jika ada kebijakan ketat, tambahkan domain ke daftar Anda. Tidak ada kekurangan perpustakaan untuk semua bahasa yang dapat melakukan pemeriksaan SPF.


Terima kasih, itu ide yang bagus. Saya memeriksa (dengan menggali) beberapa domain yang telah disajikan dengan perilaku yang tidak diinginkan, dan pasangan memang memiliki catatan SPF dengan ~ semua. Jadi ini bukan solusi yang lengkap, tetapi saya pikir akan sulit untuk menemukan solusi lengkap untuk masalah ini. Saya pikir yang lain menerapkan logika dasar yang sama, tetapi tanpa menyimpan / mempublikasikan informasi dalam catatan SPF.
Eric Rath

Ide Anda menyarankan pemeriksaan validasi lain untuk dilakukan: domain alamat harus memiliki data MX yang valid. Jika seseorang salah mengetik alamat email mereka, dan kesalahan itu jatuh di bagian domain dari alamat (misalnya person@domainn.com), pengiriman akan gagal karena tidak ada catatan MX dapat ditemukan untuk domain (dengan asumsi kesalahan tidak menghasilkan berbeda, namun masih valid, domain).
Eric Rath

Saya mengubah "penerima jawaban" ke JdeBP di bawah ini - perbedaan antara header pesan dan header amplop benar-benar berhasil. Tapi terima kasih atas umpan baliknya.
Eric Rath

5
Koreksi: SPF memeriksa "MAIL FROM" dalam amplop, bukan header "Dari" atau "Pengirim".
Simon East
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.