Cara melakukan e-mail dan tidak mengacaukan: tips praktis

Pengembang, yang pertama kali menjumpai pembuatan email, hampir tidak memiliki peluang untuk menulis aplikasi yang akan melakukan ini dengan benar. Sekitar 40% dari email yang dihasilkan oleh aplikasi perusahaan memiliki beberapa jenis pelanggaran standar, dan, sebagai akibatnya, masalah pengiriman dan tampilan. Ada beberapa alasan untuk ini: email secara teknis jauh lebih rumit daripada web, email diatur oleh beberapa ratus standar dan jumlah praktik yang diterima secara umum (dan tidak demikian), dan klien email beragam dan tidak dapat diprediksi. Pengujian dapat secara signifikan memperbaiki situasi, tetapi praktis tidak ada bahan yang ditujukan untuk menguji surat.

Mail.Ru mail secara teratur berinteraksi dengan penggunanya melalui email. Dalam proyek kami, semua komponen yang bertanggung jawab untuk menghasilkan email, dan bahkan surat tunggal, menjalani pengujian wajib. Dalam artikel ini kami akan membagikan pengalaman kami (dan penuh dengan benjolan).

• Apa itu email?
• Siapa yang terlibat dalam proses pengujian dan kontrol
• Pengiriman surat dan pos
• Antarmuka infrastruktur surat dan batas-batas aplikasi yang diuji
• Definisi parameter yang diuji
• Struktur khas aplikasi pembangkit
• Apa dan kapan menguji
  
  1. Infrastruktur pengiriman
  2. Membuat aplikasi
  3. Templat surat struktur dan tata letak
• Persyaratan dasar untuk memeriksa infrastruktur
• Persyaratan Otorisasi
• Verifikasi aplikasi penghasil
  
  • Persyaratan Alamat Pos
  • Persyaratan Header Email
  • Persyaratan untuk struktur surat itu
  • Persyaratan URI
  • Persyaratan Tata Letak
• Melakukan tes split

Apa itu email?

Aplikasi ini dapat menghasilkan berbagai jenis huruf. Mereka dapat diklasifikasikan ke dalam beberapa kategori. Dengan metode pemilihan penerima: trigger - selective - group. Dengan perjanjian: transaksional - pemasaran - layanan. Berbagai jenis huruf dapat memiliki persyaratan yang berbeda dan menerapkan skrip tes yang berbeda.

Email pemicu dihasilkan sebagai respons terhadap peristiwa apa pun, misalnya, tindakan pengguna atau perubahan status objek sistem apa pun. Mereka dihasilkan oleh aplikasi, dan karena itu yang paling menarik dalam hal pengujian. Email pemicu dapat berupa transaksi dan pemasaran.

Surat khusus dikirim ke pilihan dinamis pengguna yang cocok dengan kriteria apa pun.

Pesan grup dikirim ke grup penerima yang dikenal, misalnya, untuk semua pengguna atau mitra. Surat selektif dan kelompok paling sering dipasarkan, pengiriman surat semacam itu dimulai secara manual atau sesuai dengan jadwal.

Huruf transaksional dihasilkan ketika pengguna melakukan suatu tindakan. Surat-surat tersebut termasuk, misalnya, faktur, tiket atau pemberitahuan status pengiriman, surat-surat dengan kode pemulihan akses, dll. Email transaksional selalu menjadi pemicu. Kompatibilitas maksimum penting bagi mereka, yang berarti mereka harus sesederhana mungkin, dan mereka harus diuji pada sejumlah besar pelanggan.

Surat pemasaran mendorong pengguna untuk mengambil tindakan apa pun, misalnya, mungkin tawaran diskon individu berdasarkan pembelian sebelumnya. Dalam surat-surat ini data transaksional dapat digunakan, mereka dapat menjadi pemicu dan massa - periodik atau satu kali. Untuk surat-surat ini, efisiensi lebih penting, biasanya ditentukan oleh hasil tes split. Beberapa aspek kompatibilitas dapat dikorbankan untuk efisiensi.

Surat pemasaran grup, misalnya, pesan tentang penawaran musiman, promosi dan penjualan, sering dikirim "secara manual" dan bukan bagian dari aplikasi Anda, tetapi Anda dapat (dan harus) menerapkan prinsip pengujian umum untuk mereka.

Selain itu, mungkin ada surat layanan yang dihasilkan karyawan untuk CRM otomatis atau otomatis, penjurnalan, audit, atau sistem DWH. Surat-surat tersebut adalah pemicu, yang berarti bahwa mereka juga merupakan bagian dari aplikasi dan harus diuji.

Siapa yang terlibat dalam proses pengujian dan kontrol

1. QA-engineer - berpartisipasi di semua tahapan proses.
2. Insinyur Jaringan - Bertanggung jawab untuk mengkonfigurasi jaringan dan infrastruktur perpesanan. Seorang insinyur jaringan harus dilibatkan dalam perencanaan pengujian infrastruktur.
3. Spesialis Deliverability adalah orang yang memantau pengiriman surat, yang juga mengambil bagian dalam memantau parameter teknis dan administratif dari semua pesan yang dikirim dan memantau kemajuan proses pengiriman. Dia bertanggung jawab untuk memastikan bahwa surat yang dikirim mencapai persentase maksimum yang mungkin dari pengguna dan tidak jatuh ke dalam spam, dan untuk ini spesialis harus memiliki pengetahuan dan kontak tertentu. Jika timbul masalah dengan pengiriman surat, dialah yang harus memahami kemungkinan penyebabnya dan menghilangkannya: baik dengan menghilangkan hambatan teknis; atau mengubah sesuatu dalam isi surat; atau memecahkan masalah dengan layanan dukungan dari penyedia surat, yang tidak dapat dijangkau surat-surat. Spesialis seperti itu (jika ada) juga harus dilibatkan dalam persiapan daftar periksa dan pengujian infrastruktur yang menghasilkan aplikasi dan surat. Namun, proses pengujian itu sendiri harus di bawah kendali layanan QA.
4. Pemasar email - menentukan efektivitas kampanye pemasaran. Di bawah kendalinya, pengujian terpisah untuk audiens yang diperlukan untuk surat pemasaran diadakan. Pemasar email juga mengontrol segmentasi basis pengguna, komposisi dan frekuensi email yang dikirim, dan "presentasi" visual dari email kepada pengguna.

Semua peran ini tidak harus dilakukan oleh karyawan yang terpisah: peran pemasar dapat dimainkan oleh salah satu manajer produk, dan peran spesialis kemampuan pengiriman dapat dilakukan oleh, misalnya, karyawan pendukung atau insinyur jaringan. Dan pada startup dengan tingkat probabilitas tinggi, semua ini harus dilakukan oleh satu orang, dan mereka mungkin berubah menjadi spesialis berkualitas.

Pengiriman surat dan pos

Struktur email mirip dengan gunung es besar, dan memiliki dua tingkat. Ada lebih dari seratus standar berbeda yang mengatur surat, tetapi hampir semuanya memiliki salah satu dari dua tingkat ini:

Bagian bawah laut dari gunung es adalah layanan jaringan yang protokol dasarnya adalah protokol aplikasi SMTP, didefinisikan oleh RFC 5321. Ia bertanggung jawab atas pengiriman surat. Untuk mengirimkan surat, sebuah amplop SMTP disebut dibentuk, yang meliputi alamat pengirim dan penerima tingkat SMTP. Layanan jaringan lain seperti DNS juga bertanggung jawab untuk mengirimkan surat itu. Komponen utama dari infrastruktur jaringan adalah Mail Transfer Agent, atau singkatan MTA lebih sering digunakan. MTA bertanggung jawab untuk menangani antrian pengiriman pesan dan proses pengiriman ke server penerima. Contoh MTA adalah Postfix, Sendmail, Exim, layanan Microsoft SMTP.

Bagian bawah laut gunung es ini, yang meliputi MTA, parameter DNS dan parameter jaringan lainnya, kami akan memanggil infrastruktur surat, atau infrastruktur pengiriman pesan.

Permukaan gunung es adalah huruf itu sendiri. Struktur dasar surat itu didefinisikan dalam RFC 5322. Surat itu terdiri dari header layanan dan satu atau lebih bagian dengan data. Data dapat berisi teks dalam teks biasa dan / atau HTML, gambar sebaris atau lampiran dari hampir semua jenis.

Antarmuka infrastruktur surat dan batas-batas aplikasi yang diuji

Infrastruktur surat, sebagai suatu peraturan, memiliki satu atau lebih antarmuka dengan mana surat dikirim (memasuki antrian pengiriman MTA). Misalnya, layanan Pengiriman SMTP, fungsi mail() dalam PHP, transfer data ke aplikasi email eksternal atau sendmail, API layanan internal atau eksternal (misalnya, GetResponse, SendPulse atau Amazon SES). Kami akan mempertimbangkan antarmuka ini sebagai bagian dari infrastruktur. Cukup sering ada situasi di mana aplikasi A menyiapkan data untuk surat dan daftar penerima, dan kemudian mentransfernya ke aplikasi B melalui API-nya (untuk pemasaran surat massal, ini dapat dilakukan secara manual melalui antarmuka pengguna - UI), dan sudah aplikasi B menghasilkan pesan email di Format RFC 5322 dan entah bagaimana mengantre untuk pengiriman MTA. Dari sudut pandang aplikasi A (dan ketika mengujinya), aplikasi B akan menjadi bagian dari infrastruktur surat. Aplikasi B API atau UI akan menjadi antarmuka infrastruktur email untuk aplikasi A. Meskipun dari sudut pandang aplikasi B, situasinya akan berbeda, dan infrastruktur surat untuk itu akan menjadi aplikasi atau protokol jaringan tingkat rendah.

Definisi parameter yang diuji

Saat menguji setiap aplikasi, penting untuk menyoroti semua infrastruktur surat yang digunakan olehnya (mungkin ada beberapa), dan untuk setiap infrastruktur, pilih antarmuka yang digunakan (mungkin juga ada beberapa untuk setiap infrastruktur). Untuk setiap antarmuka, komposisi dan format data yang ditransfer ke sana ditentukan seakurat mungkin, misalnya: teks pesan dalam TEXT / HTML, teks pesan dalam TEXT / PLAIN, subjek pesan, nama penerima, alamat penerima, nama pengirim, alamat pengirim surat (RFC5321.From ), alamat pengirim konduktor SMTP (RFC5322.mailfrom). Selanjutnya, seperangkat persyaratan dikembangkan untuk setiap parameter (representasi, pengkodean, nilai batas, dll.), Metode kontrol untuk masing-masing parameter ditentukan (dengan cara apa hasil aktual dapat dibandingkan dengan yang diharapkan).

Struktur khas aplikasi pembangkit

Sebagai aturan, produk yang kami uji bertanggung jawab untuk menghasilkan surat dan data di dalamnya. Ini biasanya aplikasi server (tetapi terkadang klien). Ini mendefinisikan struktur surat, bagian dari header layanan, format untuk enkapsulasi data, penyajian string dan pengodean teks. Contoh sederhana aplikasi semacam itu adalah skrip yang membentuk huruf dan memanggil fungsi mail() .

Elemen utama dari aplikasi yang perlu dikendalikan:

• kode yang bertanggung jawab untuk menghasilkan tajuk dan / atau struktur huruf jika struktur huruf dihasilkan secara dinamis dan / atau templat surat statis yang menggambarkan strukturnya;
• tata letak bagian HTML surat (idealnya, ini adalah entitas yang terpisah atau bagian dari templat / tata letak surat, tetapi dapat dijahit ke dalam kode aplikasi);
• Substitusi data aplikasi dalam surat (atau dalam templat surat);
• integrasi aplikasi dengan infrastruktur pengiriman surat, kebenaran parameter yang ditransfer ke antarmuka infrastruktur.

Apa dan kapan menguji

Suka atau tidak suka, seluruh gunung es perlu diuji. Ada beberapa komponen utama yang memerlukan pengujian:

1. Infrastruktur pengiriman

Penekanan dalam pengujian harus ditempatkan pada: pengiriman surat; kebenaran catatan DNS, termasuk catatan PTR / FCrDNS, MX dan A; Pengaturan protokol SMTP (HELO, menggunakan TLS); otorisasi surat (SPF / DKIM / DMARC); Alamat amplop SMTP (jika tidak dikelola oleh aplikasi); pemrosesan parameter input yang benar dari antarmuka infrastruktur; pelacakan, akuntansi dan pemrosesan surat yang tidak terkirim.

Penting untuk menguji infrastruktur selama implementasi awal dan setiap kali ketika perubahan dilakukan pada infrastruktur itu sendiri (konfigurasi MTA, DNS atau perubahan jaringan) atau antarmuka untuk mengirim surat; Menggunakan domain, jaringan, atau API baru Secara signifikan mengubah karakteristik email yang dikirim, seperti bahasa, ukuran, atau jumlah mereka. Menurut pengalaman, infrastruktur cenderung berubah tanpa menyatakan perang, jadi tes dasar harus dilakukan secara berkala, bahkan jika tidak ada informasi tentang perubahan apa pun.

Seorang insinyur jaringan dan spesialis kemampuan pengiriman dapat dan harus dilibatkan dalam persiapan rencana dan memeriksa daftar pengujian infrastruktur.

2. Aplikasi penghasil

Anda harus mengontrol alamat amplop SMTP (jika dikontrol oleh aplikasi, mis. Ditransfer ke antarmuka - amplop-dari, amplop-ke), nilai-nilai tajuk pesan layanan (Tanggal, ID-Pesan, Daftar-Berhenti Berlangganan, Diserahkan Otomatis, dll.) p.), otorisasi surat (DKIM / DMARC), pengkodean MIME (base64, dikutip-cetak), kebenaran umum format surat, misalnya, tidak adanya karakter non-ASCII di header, komposisi data yang diganti, pemicu pemicu yang tepat, mekanisme berhenti berlangganan, mekanisme pelacakan, mekanisme pelacakan koleksi surat dan statistik (tajuk kepala sekolah, misalnya, Feedback-ID atau X-Mailru-Msgtype, serta piksel pelacakan) .

Anda perlu menguji aplikasi selama pengembangannya, ketika mengubah semua komponen terkait yang bertanggung jawab untuk menghasilkan dan menyimpan data, dengan perubahan signifikan pada templat surat, saat mengubah infrastruktur yang digunakan atau antarmuka, serta dalam kerangka regresi umum.

3. Templat surat struktur dan tata letak (dapat menjadi bagian dari aplikasi penghasil atau dikembangkan secara terpisah)

Struktur pesan diperiksa (Tipe-Konten, Disposisi-Konten, bersarang dari Multi-bagian surat, pengkodean teks, parameter string), nilai target dan header yang ditampilkan (Dari, Ke, Balas ke, Subjek), pesan ditampilkan dalam daftar huruf dan saat membaca dalam berbagai antarmuka, Microformats (misalnya, bahwa acara kalender diakui sebagai acara kalender, atau tiket udara sebagai tiket udara), pencitraan merek.

Template email harus diuji setiap kali Anda membuat setidaknya perubahan sekecil apa pun, dan juga secara terpisah, misalnya, dalam situasi di mana surat masuk ke aplikasi sebelum bagian server siap.

Disarankan agar Anda menggunakan pemasar surel dan spesialis pengiriman untuk menulis daftar periksa untuk menguji templat surat.

Persyaratan dasar untuk memeriksa infrastruktur

Alamat IP yang dipilih untuk server e-mail harus semirip mungkin dengan alamat IP server e-mail. Dianjurkan untuk memeriksanya menggunakan utilitas whois. Secara khusus, alamat pengirim tidak boleh milik jaringan yang dapat dianggap dinamis; Jaringan yang dipilih harus memiliki kontak yang valid tempat Anda dapat mengirim keluhan; jaringan harus digunakan (berstatus ASSIGNED dalam RIPE). Alamat IP harus memiliki catatan PTR yang dikonfigurasi dengan benar. Ini dapat dikonfigurasi secara independen melalui panel kontrol hosting, atau menggunakan layanan dukungan penyedia. Catatan PTR harus menunjuk ke nama host asli dan pada saat yang sama bermakna, menyelesaikan kembali ke alamat IP yang sama (yang disebut cek FCrDNS), tidak mengingatkan nama host dinamis dan tidak termasuk sekelompok besar angka atau karakter. Contoh yang baik adalah mailserver.example.com.

Setiap domain yang digunakan dalam alamat amplop atau header pesan harus memiliki catatan MX yang valid yang menunjuk ke catatan-A dari host, yang, setidaknya, dapat memproses pesan tentang kegagalan pengiriman. Untuk MX, tidak diperbolehkan untuk merujuk langsung ke alamat IP.

Kontrol bagian SPF, DKIM, DMARC. SPF memungkinkan pemilik domain untuk menentukan dalam TXT merekam daftar server yang memiliki hak untuk mengirim pesan email dengan alamat pengirim di domain ini. Ini dikonfigurasi untuk alamat yang digunakan dalam amplop-dari (amplop SMTP) di bagian manajemen zona DNS domain. DKIM memberikan verifikasi kepengarangan pesan atau pengirimnya milik domain tertentu menggunakan teknologi tanda tangan digital, yang ditambahkan ke pesan itu sendiri (dalam header Tanda Tangan DKIM-nya). Biasanya, tanda tangan DKIM dikonfigurasikan di tingkat MTA (infrastruktur). DMARC menetapkan kebijakan untuk memeriksa surat masuk di domain tertentu dan tindakan pada surat yang tidak lulus otentikasi SPF atau DKIM. Saat Anda mencoba melanggar kebijakan ini, laporan terstruktur datang dengan informasi tentang upaya semacam itu. DMARC, serta SPF, diterbitkan sebagai catatan TXT di zona domain.

Periksa pengiriman surat ke layanan pos utama - untuk Rusia, Mail.Ru, Yandex, GMail, Microsoft (Hotmail / Outlook.com / Office365), Rambler, nic.ru. Dalam surat-surat Anda perlu memverifikasi kebenaran HELO; ketersediaan dan melewati pemeriksaan PTR / FCrDNS, SPF, DKIM dan DMARC; validitas header dan data di dalamnya, khususnya, sinkronisasi jam dalam tanggal dan kebenaran zona waktu.



Pembentukan parameter tertentu, misalnya, otorisasi, pengiriman, dan spamming, dipengaruhi secara integral oleh semua komponen, namun biasanya ada alat operasional terpisah untuk mengendalikannya - laporan DMARC dan FBL, API layanan postmaster, alat pelacakan email, dan statistik pengiriman. Pengujian harus mempertimbangkan tingkat penerapan alat pemantauan operasional di perusahaan - misalnya, jika tidak ada pemantauan operasional laporan DMARC, Anda harus menguji otorisasi surat secara berkala, jika tidak ada pemantauan operasional terhadap pengiriman - secara teratur memeriksa bagaimana dan di mana surat diterima, bahkan jika tidak ada pengembangan terkait dengan pengiriman surat tidak dilakukan.

Untuk memeriksa infrastruktur, Anda dapat menggunakan layanan khusus, misalnya, mail-tester.com , mxtoolbox.com . Persyaratan infrastruktur terperinci dapat ditemukan di artikel ini .

Persyaratan Otorisasi

Memeriksa bagian SPF, DKIM, DMARC biasanya dimungkinkan menggunakan header Authentication-Results di server penerima.

Periksa validitas catatan SPF untuk sintaks, batas untuk permintaan DNS (misalnya, menggunakan mxtoolbox.com). Saat membentuk SPF, semua sumber pengiriman harus diperhitungkan (jangan lupakan sistem CRM, semua infrastruktur pengiriman yang digunakan, termasuk yang melaluinya kampanye pemasaran satu kali dilakukan). Disarankan untuk mengatur server yang diizinkan untuk domain melalui daftar jaringan ('ip4' / 'ip6'). SPF diperiksa untuk alamat pengirim dari amplop SMTP. Pastikan domain amplop SMTP (amplop-dari) cocok dengan domain dari header Dari. Kesalahan SPF umum tercantum dalam artikel ini .

Periksa catatan DNS DKIM, validitas dan komposisi Tanda Tangan DKIM. Verifikasi bahwa Anda menggunakan kunci DKIM minimal 1024 bit. Mode hash yang direkomendasikan dari tanda tangan DKIM: santai / santai. Pastikan bahwa semua tajuk penting ditandatangani (Dari, Kepada, Subjek, Tanggal, ID-Pesan, Versi MIME, Tipe-Konten), bahwa tajuk pelacakan (Diterima, Dikirimkan Ke, Jalur Kembali) tidak ditandatangani, dan DKIM divalidasi untuk layanan pos dasar. Mengatur penerusan ke salah satu layanan surat ke yang lain, DKIM tidak boleh "mengalahkan" surat yang diteruskan. Verifikasi bahwa domain tanda tangan DKIM cocok dengan domain pengirim dari header Dari.

Periksa DMARC untuk layanan surat dasar. Periksa laporan DMARC, identifikasi dan atasi masalah SPF dan DKIM untuk semua alamat IP infrastruktur Anda.

Verifikasi bahwa pesan dikirim ke server eksternal menggunakan enkripsi (TLS). Kadang-kadang Anda dapat memeriksa TLS dengan tajuk Diterima di server penerima: misalnya, menentukan protokol ESMTPS atau keberadaan parameter formulir (versi = TLS1_2 cipher = ECDHE-RSA-AES128-GCM-SHA256 bits = 128/128); menunjukkan keberadaan TLS.

Verifikasi aplikasi penghasil

Persyaratan Alamat Pos

Alamat Amplop
Kami memulai verifikasi aplikasi pembangkit dengan alamat di amplop SMTP.

Alamat amplop adalah alamat tingkat infrastruktur surat. Mereka tidak terlihat oleh pengguna, tetapi penting untuk pengiriman, karena di mana kotak surat surat itu diterima, itu ditentukan oleh alamat amplop.

Alamat penerima dalam amplop (amplop-ke, alias RCPT TO :) adalah alamat yang akan dikirimi surat itu.

• untuk semua surat kecuali untuk pendaftaran, alamat harus ditandatangani secara sah dan divalidasi untuk pengiriman sesuai dengan persyaratan administrasi.
• untuk buletin, alamatnya harus “langsung”, alamat yang surat-suratnya tidak dapat dikirimkan secara teratur harus ditandai sebagai tidak aktif, surat-surat kepada mereka tidak boleh dibuat. Tetapi beberapa kategori surat (misalnya, akses pemulihan) mungkin juga harus dikirim ke alamat yang sebelumnya ditandai sebagai tidak aktif.

Alamat pengirim dalam amplop SMTP (biasanya disebut envelope-from, smtp.mailfrom atau Return-Path) - pesan akan dikirimkan ke alamat ini tentang ketidakmampuan untuk mengirim surat dan balasan otomatis. Alamat ini tidak terlihat oleh pengguna. Alamat ini juga digunakan untuk otorisasi SPF. Kami memverifikasi bahwa:

• alamat tersedia;
• Ini bukan alamat karyawan dan tidak diarahkan kepadanya untuk mengecualikan jawaban otomatis, pesan tentang tidak dapat diaksesnya, dll .;
• Ini diproses oleh skrip yang akan menandai alamat pengguna yang tidak dapat diakses sebagai tidak aktif;
• alamat tersebut dapat dibuat secara otomatis, mis. unik untuk setiap huruf;
• Surat ke alamat ini tidak boleh mengarah pada pembuatan surat respons apa pun, misalnya, pesan tentang kotak yang meluap.

Alamat Header Email

Alamat-alamat ini dapat langsung dilihat oleh pengguna atau digunakan ketika membalas surat.

Alamat pengirim (Dari :) tajuk adalah alamat dan nama pengirim yang ditampilkan dalam daftar surat dan saat membaca surat. Kami memverifikasi bahwa:

• Ini adalah alamat ramah "dapat dibaca manusia" yang mengidentifikasi perusahaan.
• Ini tidak hanya berisi e-mail, tetapi juga nama pengirimnya.
• noreply @ adalah mungkin, tetapi hanya jika kita ingin menekankan bahwa kita tidak mengharapkan untuk menerima tanggapan terhadap surat itu dan itu tidak akan dibaca. Lebih baik menggandakan ide ini dalam teks surat itu.
• Di hadapan karakter non-ASCII (misalnya, Cyrillic), nama pengirim harus dikodekan sesuai dengan MIME, domain di hadapan karakter non-ASCII harus dikodekan dalam Punycode.
• Surat dari kategori yang sama harus memiliki alamat yang sama, penggunaan alamat yang dibuat secara otomatis tidak diperbolehkan. Ini disebabkan oleh fakta bahwa Dari: paling sering digunakan oleh orang untuk menyortir surat ke dalam folder menggunakan filter.
• Alamatnya harus berbeda (lebih disukai di subdomain yang berbeda) untuk surat transaksional, pemasaran, dan mendesak (seperti surat dari layanan dukungan). Ini juga disebabkan oleh fakta bahwa pengguna dapat menandai email pemasaran sebagai spam atau memfilternya dalam folder yang tidak dapat dibaca.
• Alamat Dari dan alamat amplop SMTP harus berada di domain yang sama atau di subdomain dari domain organisasi yang sama untuk lulus SPF dalam DMARC.
• Alamat harus berasal dari domain organisasi. Tidak dapat diterima untuk menggunakan layanan surat gratis dan domain surat publik lainnya di Dari, karena surat-surat tersebut tidak akan lulus otentikasi SPF dan DKIM dalam kerangka DMARC.

Alamat Balas-Ke - balasan "manual" akan dikirim ke alamat ini ketika pengguna membalas surat itu. Ini opsional: jika tidak ada, alamat dari Dari digunakan untuk respons. Periksa Balas-Ke:

• Itu dapat dibuat secara otomatis, mis. unik untuk surat tersebut (memungkinkan Anda untuk mengetahui surat yang jawabannya dijawab).
• Seharusnya tidak jatuh ke dalam kotak karyawan untuk menghindari menjawab panggilan, tetapi idealnya harus "dibungkus" dalam CRM.
• Itu dapat menghasilkan jawaban otomatis CRM standar, tetapi seharusnya tidak menghasilkan sesuatu yang berlebihan, misalnya, pesan tentang kotak yang meluap. Saat menghasilkan respons otomatis, langkah-langkah harus diambil untuk menghindari perulangan, mereka terdaftar di RFC 3834.
• Itu bisa dari domain apa pun yang tidak selalu bertepatan dengan Dari, tetapi terkadang ini membuat pengguna takut ketika menjawab.
• Mungkin tidak ada, maka alamat Dari melakukan fungsinya.
• Selain alamat, nama pengirim diindikasikan.

Ke alamat:

• Itu harus berisi email penerima (jika tidak menakut-nakuti penerima pesan dan menjaga anti-spam).
• Idealnya, itu harus berisi nama penerima. Tetapi jika nama itu tidak diketahui atau diragukan (misalnya, alamatnya belum dikonfirmasi), lebih baik untuk tidak menunjukkannya (seseorang mungkin memasukkan alamat orang lain dengan nama yang buruk, dan penerima mungkin tersinggung oleh Anda).

Persyaratan Header Email

Pengkodean teks yang sebenarnya harus sesuai dengan yang ditunjukkan pada header. Dianjurkan untuk menggunakan satu penyandian di semua tajuk dan bagian surat itu. Disarankan agar Anda menggunakan UTF-8 sebagai yang didukung secara luas. Pengkodean ditunjukkan dalam header Tipe-Konten dan tag <META> pada bagian HTML.

Header From:, Message-ID: dan Date: harus dibentuk langsung dalam skrip untuk mengirim surat (dan menurut standar - bersama dengan teks surat) dan selalu dalam format yang benar. Jika tidak ada atau tidak terbentuk dengan benar, salah satu server transit dapat menambahkan header ini, yang mengarah pada pelanggaran integritas tanda tangan DKIM.

Karakter 8-bit di header, termasuk baris subjek (Subjek) dan nama file yang dilampirkan (Tipe Konten dan Disposisi Konten), harus tidak ada; Semua karakter non-ASCII, termasuk Cyrillic, harus dikodekan dalam kutip-cetak atau base64.

Persyaratan untuk struktur surat itu

Untuk bagian HTML surat itu, diinginkan untuk membentuk bagian alternatif - teks (polos). Penting juga untuk memeriksa kesesuaian dan keterbacaan bagian teks biasa dari surat (jika ada) dan struktur umum dari surat tersebut.

Menurut RFC 5322, panjang garis dalam huruf tidak boleh melebihi 998 karakter 8-bit. Harap dicatat bahwa dalam UTF-8, karakter dapat menempati beberapa oktet. Terminator garis dalam email adalah sepasang CRLF (<cr> ascii 13, lf> ascii 10), yang menempati 2 oktet. Anda perlu memeriksa kebenaran dari terminator string, karena surat sering dikirim menggunakan skrip Unix, dan di Unix, line terminator adalah karakter tunggal jika - ini adalah kesalahan untuk email. Anda juga harus memeriksa untuk melihat apakah terminator string memecah karakter-karakter yang dikodekan UTF-8: Anda tidak dapat mengizinkan keberadaan terminator string antara dua oktet dari karakter yang sama, misalnya, Cyrillic. , base64.

— «Content-Disposition: inline», , , «Content-Disposition: attachment», .
, , : , multipart- (mixed, alternative, related), multipart/mixed , multipart/related — , multipart/alternative — plain text- HTML-. , -, :

multipart/alternative
— text/plain
— text/html

, text/plain text/html multipart/related. , HTML-, - — plain-.

- :

multipart/alternative
— text/plain
— multipart/related
—— text/html
—— image/… (-)
—— image/… (-)

- Content-Disposition: inline multipart/related-.

, , , :

multipart/mixed
— multipart/alternative
—— text/plain
—— multipart/related
——— text/html
——— image/png
——— image/png
...
— application/octet-string (content-disposition: attachment)
— application/octet-string (content-disposition: attachment)
...

(multipart/related- multipart/alternative- , multipart/mixed-)

URI

URI ( src, href, ..) ( https://example.com/somepath ). (/somepath) (//example.com/somepath), , .. file://.

• ASCII- ( , ) URI percent encoding.
• , (.. URL, ), <>, . - , . href A , - . «», .
• htt://, htts:// milto:.
• http:// htts://.
• (, example.com :8080/somepath), .. .
• HTML- - (, , ..) , .. - , ; , , , ( - GET-, POST PUT).
• List-Unsubscribe, , - , .. .
• , , , (, ). . , , , , , .
• Karena URI , URI data:. URI.
• , . , , .
• - .

?

. — (XSS, Crossite scripting), (interface spoofing), DOM clobbering, / (, IP- ) .., . , . :

• ,
• / ,
• ,
• ( ),
• (.. ) ,
• HTML- ( Microsoft Exchange / Outlook RTF, - Outlook ),
• .

, - URI cid://, . , Mozilla Thunderbird cid:// .

- - .

. , URI, - , - , . : , ( , ).

:

• , , , , .
• .
• , , , . ( ). . , .
• , .
• , , .. -, - , c, , ( , , , , - ). , , .
• .
• , , , . (, - ), , , , .
• .
• :
  
  • : « » Mail.Ru, Yandex, Gmail, Rambler Outlook.com;
  • ;
  • , IMAP, , iPhone, Pixel ( Android), Samsung ( Android), MIUI ( Android-);
  • : Chrome, Firefox, Edge, Internet Explorer, Opera .;
  • ( ), Thunderbird, Outlook Apple Mail, The Bat! Opera Mail;
  • - (Exchange, Roundcube, Communigate, Zimbra, SquirrelMail) — B2B-;
  • Retina-, .
• :
  
  • , SPF/DKIM/DMARC.
  • : , .
  • : , , , (, «»).
  • : , .., .
  • .
  • .
  • .
  • , . , , - , , .
    
    
    
    
• ( ) , . , .
• , , , .. , , , «» .
• . , DKIM- - ( DNS DKIM-, ), - ( , , From, Date Message-ID) - ( , , ). «» , .

-

, , .

, , ( ). . , , .

CTR — . postmaster.mail.ru . (), . CTR < 10% — , . CTR > 30%. CTR («») . ( ). , — . , , : https://help.mail.ru/developers/mailing_rules/technical .

- . CTR . ( ). «» — 10 000 , .

: , , . « » . , .

z3apa3a s4ever . EdT 4Alexander .