Apa metode terbaik untuk mengirim email atas nama domain klien saya?


15

Saya ingin tahu cara terbaik untuk membuat server surat saya mengirim email atas nama domain klien saya, tanpa di-greylisted dan juga menghindari masalah bouncing.

Saya telah membaca beberapa pertanyaan lain di sini , di sini dan di sini tetapi tidak ada yang mengeksplorasi semua solusi yang mungkin. Berikut adalah beberapa kemungkinan yang ingin saya bandingkan:

SEBUAH.

HELO mymailserver.com
MAIL FROM<do-not-reply@myapp.com>  # mymailserver.com same IP as myapp.com
DATA
  From: <res@client.com>
  Sender: <do-not-reply@myapp.com>

Pertanyaan : Inilah yang dilakukan gmail. Header msg "Dari:" yang memiliki domain berbeda, bukan pengirim amplop.
emailclients akan menampilkan "Dari: res@client.com via do-not-reply@myapp.com" atau "Dari: do-not-reply@myapp.com Atas Nama res@client.com" , yang bukan masalah untuk saya.
Sekarang, apakah ini akan berdampak buruk pada reputasi domain saya, fakta bahwa tajuk "Dari:" memiliki domain yang berbeda? (dan jika bukan Google yang melakukannya ..)

B.

HELO mymailserver.com
MAIL FROM<do-not-reply@myapp.com>
DATA
   From: <res@client.com>
   # same as A, but no "Sender:"

Sepertinya Google pernah melakukan ini dan menyebutnya kesalahan http://groups.google.com/group/Gmail-Help-Message-Delivery-en/browse_thread/thread/f651cb1db5d9dd23/3a8bcd0548487863?lnk=gst&q=%22on+behalf + dari% 22 & pli = 1
Bug menghapus "Pengirim:" dari pesan mereka dan "via" tidak muncul di klien email. (RFC mengatakan bahwa itu HARUS hadir jika tidak sama dengan "Dari:")

C.

HELO mymailserver.com
MAIL FROM<res@client.com>
DATA 
  From: <res@client.com>

Seolah-olah client.com mengirim pesan (MAIL FROM juga "palsu"). Tetapi jika domain client.com terkenal atau memiliki entri SPF dalam DNS-nya, saya harus mengubah DNS-nya, memungkinkan mymailserver.com untuk mengirim pesan atas nama mereka .. (Ini tidak mungkin bagi saya karena nb . klien, dan juga beberapa klien saya tidak memiliki kontrol atas domain mereka, yaitu menggunakan @ gmail.com sendiri)

D.

HELO mymailserver.com    
MAIL FROM<do-not-reply@myapp.com>
DATA 
  From: <do-not-reply@myapp.com>
  Reply-to: <res@myclient.com>

Pertanyaan : Ini adalah yang paling sederhana, saya hanya akan menambahkan header "Balas-ke:". Apakah ini benar-benar diperhitungkan SEMUA SAAT oleh klien email? Bisakah ini dianggap sebagai spoof juga, menambahkan domain yang berbeda ke header "Balas-ke", dan menjadi pengaruh buruk bagi reputasi domain saya?
- RFC hanya mengatakan bahwa "jika bidang Balas-Ke ada, maka balasan HARUS pergi ke alamat yang ditunjukkan di bidang itu dan bukan ke alamat yang ditunjukkan dalam bidang Dari.".
- Hanya label tajuk "Dari:" yang akan "dipalsukan":
"Dari: myclient.com (via myapp.com) <do-not-reply@myapp.com>".


Saat membaca RFC, 'HARUS' berarti itu adalah rekomendasi yang sangat kuat. Satu-satunya alasan klien tidak akan dalam kebanyakan kasus adalah karena sudah tua dan belum diperbarui sejak RFC ditulis. Lihat RFC 2119 untuk definisi standar: ietf.org/rfc/rfc2119.txt
Matthew Scharley


Sayangnya pada 2018 banyak klien email masih mengabaikan header Balas-Ke. meta.discourse.org/t/…
Martin Meixger

Jawaban:


2

Pertanyaan yang sangat bagus Saya baru saja menghabiskan beberapa jam untuk meneliti hal yang sama.

Saya sebelumnya telah menyebarkan banyak situs web yang menggunakan Opsi C untuk formulir email (terutama karena kenaifan), tetapi kami mengalami peningkatan jumlah masalah pengiriman. Penyedia email secara bertahap memperketat hal-hal. Misalnya, Yahoo baru-baru ini mengubah kebijakan DMARC mereka untuk meminta penerima menolak semua email From: ____@yahoo.comtanpa tanda tangan DKIM yang valid . Menerima server SMTP yang mengikuti DMARC (yang mencakup Gmail, dan mungkin Hotmail / Outlook.com dan Yahoo) akan sulit memantulkan pesan ini. Saya percaya eBay dan Paypal memiliki kebijakan ketat serupa, dalam upaya mengurangi phishing. Sayangnya menentukan header "Pengirim" tidak membantu.

(Saya ingin tahu bagaimana cara Gmail menangani hal ini saat mengirim "Dari" alias Yahoo ?!)

Opsi A akan menjadi pilihan yang lebih baik jika Anda tahu email "Dari" tidak memiliki kebijakan DMARC yang ketat (Anda mungkin bisa mengonfirmasi ini melalui permintaan DNS sederhana).

Meskipun paling tidak menarik secara visual, Opsi D benar-benar paling aman dan apa yang akan saya rekomendasikan untuk sebagian besar proyek masa depan kita. Itu perlu dicatat bahwa PayPal sebelumnya digunakan Opsi A, tapi sekarang telah beralih ke Option D .

Untuk mendapatkan kredibilitas tambahan dan peningkatan peluang pengiriman, saya akan melihat penerapan SPF dan / atau DKIM. Ini dan hal-hal lain disebutkan dalam Panduan Pengirim Massal Google yang menurut saya sangat membantu.


1

Saya tidak yakin apa yang Anda inginkan. Tidak ada cara "aman" atau "tidak aman" untuk melakukan apa yang Anda inginkan.

Saya selalu lebih suka D). Selain itu saya akan menambahkan catatan SPF. Tapi seperti yang saya katakan ini tidak lebih aman atau tidak aman daripada yang lain (apa pun yang Anda maksud dengannya).

Header Balas-Ke tidak memengaruhi reputasi dengan cara apa pun. Itu hanya menyarankan klien untuk menggunakan alamat itu untuk balasan (Duh, mungkin dari sinilah namanya berasal ?!). Jika klien mengikuti rekomendasi ini tidak dijamin.


Yang saya maksud dengan "aman" adalah memperkecil kemungkinan domain saya di-greylisted, secara keliru dianggap sebagai spoofer / spammer karena solusi yang saya pilih. Ya, jika saya menggunakan D, saya dapat mempertimbangkan untuk menambahkan entri SPF ke domain saya dan menandatangani pesan menggunakan DKIM.
dgaspar

Saya telah mengedit pertanyaan saya dan mencoba menjelaskannya ..
dgaspar

@dgaspar Greylisting berbasis amplop. Jadi konten Anda (Dari :, Pengirim :, ...) benar-benar diabaikan. Karena setiap orang dapat menulis alamat email apa pun sebagai pengirim, setiap alamat pengirim dianggap palsu. Kecuali Anda menandatangani surat Anda dengan SPF atau DKIM.
mailq

0

Dua solusi andal:

  1. minta dari pelanggan untuk menambahkan server surat Anda dalam catatan domain SPF mereka
  2. minta pelanggan untuk memberi Anda kredensial akun email (IP server surat mereka, nama pengguna, kata sandi) dan gunakan ini di dalam aplikasi Anda untuk terhubung ke server surat mereka dan mengirim email (Anda benar-benar membuat klien email di dalam aplikasi Anda).
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.