Cara Membuat Email dan Tidak Mengacaukan: Kiat Praktis

Seorang pengembang, yang pertama kali menemukan menghasilkan email, hampir tidak memiliki kesempatan untuk menulis aplikasi, yang akan melakukannya dengan benar. Sekitar 40% email, yang dihasilkan oleh aplikasi perusahaan, melanggar beberapa bentuk standar, dan karena ini, ada masalah dengan pengiriman dan tampilan. Ada alasan untuk ini: email secara teknis lebih sulit daripada web, dan operasi email diatur oleh beberapa ratus standar, serta jumlah praktik yang diterima (dan tidak sebanyak) yang tak terhitung banyaknya, sedangkan klien email lebih bervariasi. dan tidak dapat diprediksi dibandingkan browser. Pengujian dapat secara signifikan memperbaiki situasi, tetapi materi yang didedikasikan untuk menguji sistem email, praktis tidak ada.

Mail.ru berinteraksi secara teratur dengan para penggunanya melalui email. Dalam proyek kami, semua komponen yang bertanggung jawab untuk menghasilkan email dan bahkan pengiriman individu, harus melalui pengujian wajib. Dalam artikel ini, kami akan membagikan pengalaman kami (belajar dari kesalahan kami).

• Jenis email apa yang ada?
  
• Siapa yang terlibat dalam proses pengujian dan kontrol?
  
• Mailing dan transportasi surat
  
• Antarmuka infrastruktur email dan batas-batas aplikasi yang diuji
  
• Definisi parameter uji
  
• Struktur khas aplikasi pembangkit
  
• Apa dan kapan menguji
  
  • Infrastruktur pengiriman
    
  • Membuat aplikasi
    
  • Template email struktural dan huruf
    
• Persyaratan dasar untuk memeriksa infrastruktur
  
• Persyaratan otentikasi
  
• Verifikasi aplikasi penghasil
  
  • Persyaratan untuk alamat email
    
    • Alamat amplop
      
    • Alamat tajuk email
      
  • Persyaratan untuk tajuk
    
  • Persyaratan untuk struktur email
    
  • Persyaratan URI
    
  • Persyaratan tata letak email
    
• Melakukan tes split
  

Jenis email apa yang ada?

Aplikasi ini dapat menghasilkan berbagai jenis email. Mereka dapat diklasifikasikan ke dalam beberapa kategori. Dengan metode pemilihan penerima - pribadi / dipicu - kelompok selektif. Dengan perjanjian: transaksi- pemasaran- layanan. Anda dapat menetapkan persyaratan berbeda untuk berbagai jenis email dan menerapkan berbagai skenario pengujian.

Email pribadi yang dipicu dihasilkan sebagai respons terhadap peristiwa apa pun, misalnya, tindakan pengguna atau perubahan status objek sistem. Mereka dihasilkan oleh aplikasi, dan karena itu yang paling menarik dalam hal pengujian. Email yang dipicu dapat berupa transaksi, pemasaran, dan untuk penggunaan layanan. Email selektif dikirim ke pilihan pengguna yang dinamis, yang memenuhi beberapa bentuk kriteria. Email grup dikirim ke grup penerima permanen, misalnya, semua pengguna atau mitra. Email selektif dan grup sering digunakan untuk pemasaran, dan pengiriman email semacam itu dimulai secara manual atau sesuai jadwal.

Email transaksional dihasilkan dalam proses pengguna menyelesaikan beberapa bentuk tindakan. Email semacam itu termasuk, misalnya, faktur, tiket, atau pemberitahuan status pengiriman. Email transaksional selalu dipicu dan dimaksudkan untuk membawa informasi penting. Mereka harus sesederhana dan kompatibel mungkin, dan mengujinya harus dilakukan pada sejumlah besar klien email.

Email pemasaran mendorong pengguna untuk mengambil tindakan, misalnya, ini bisa menjadi penawaran untuk diskon pribadi berdasarkan pembelian sebelumnya. Data transaksional dapat digunakan dalam surel ini, dan dapat dipicu surel atau massal, berkala atau satu kali. Untuk email-email ini, efisiensi lebih penting, dan hasil dari split-test biasanya menentukannya. Beberapa aspek kompatibilitas dapat dikorbankan untuk efisiensi.

Email 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) juga menerapkan prinsip pengujian umum.

Juga, mungkin ada email layanan: pemberitahuan yang dihasilkan untuk staf, untuk sistem CRM otomatis, penjurnalan, audit, atau DWH. Email semacam itu biasanya merupakan email yang dipicu, artinya mereka juga merupakan bagian dari aplikasi, dan harus diuji.

Siapa yang terlibat dalam proses pengujian dan kontrol?

1. Insinyur QA - berpartisipasi di semua tahapan proses.
   
2. Insinyur jaringan - bertanggung jawab untuk mengkonfigurasi infrastruktur jaringan dan infrastruktur pengiriman pesan. Insinyur jaringan harus dilibatkan dalam perencanaan dan pengujian infrastruktur.
   
3. Spesialis pengiriman - orang yang memantau pengiriman email, yang juga berpartisipasi dalam memantau parameter teknis dan administratif semua email yang dikirim, dan memantau kemajuan proses pengiriman. Dia bertanggung jawab untuk memastikan bahwa email yang dikirim mencapai persentase pengguna tertinggi, dan tidak berakhir dengan spam. Untuk tujuan ini, spesialis harus memiliki pengetahuan dan kontak khusus. Jika ada masalah dengan pengiriman email, dialah yang harus memahami kemungkinan penyebabnya dan menghilangkannya; baik dengan menghilangkan hambatan teknis; atau mengubah sesuatu dalam isi email; atau coba dan atasi masalah dengan layanan dukungan dari penyedia surat, yang tidak dapat dijangkau oleh email. Spesialis seperti itu (jika ada) juga harus dilibatkan dalam membuat daftar periksa, dan menguji infrastruktur yang menghasilkan aplikasi dan email. Namun, proses pengujian itu sendiri harus di bawah kendali layanan QA.
   
4. Email-marketer - menentukan efektivitas buletin pemasaran. Di bawah kendalinya, pengujian-split untuk distribusi pemasaran kepada audiens terjadi. Pemasar email juga mengontrol segmentasi basis pengguna, komposisi, dan frekuensi email yang dikirim, 'presentasi' visual email kepada pengguna.
   

Semua peran ini tidak harus dilakukan oleh karyawan yang berdedikasi; peran pemasar dapat dilakukan oleh salah satu manajer produk, dan peran spesialis pengiriman, misalnya, dapat dilakukan oleh karyawan pendukung atau insinyur jaringan. Di perusahaan pemula, sangat mungkin bahwa semua ini harus ditangani oleh satu orang, dan mereka mungkin berubah menjadi spesialis yang berkualitas.

Mailing dan transportasi surat

Struktur email seperti gunung es besar, dan ada dua level di dalamnya. Ada lebih dari seratus standar berbeda yang mengatur surel, tetapi hampir semuanya milik salah satu dari dua tingkatan ini:

Bagian bawah laut dari layanan jaringan gunung es , protokol dasar yang merupakan protokol aplikasi SMTP yang didefinisikan oleh RFC 5321. Ia bertanggung jawab atas pengiriman email. Apa yang disebut amplop SMTP dibentuk untuk pengiriman email, yang mencakup alamat pengirim dan penerima level SMTP. Layanan jaringan lain, seperti DNS, juga bertanggung jawab untuk mengirimkan email. Komponen utama dari infrastruktur jaringan adalah Agen Transfer Surat (MTA). MTA bertanggung jawab untuk menyerahkan antrian pengiriman pesan dan proses pengiriman itu sendiri ke server penerima. Contoh MTA termasuk 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 email atau infrastruktur pengiriman pesan.

Ujung gunung es - email itu sendiri. Struktur dasar email ditentukan oleh RFC 5322. standar. Email terdiri dari header layanan dan satu atau lebih bagian data. Data mungkin dalam format teks biasa dan / atau HTML atau bahkan AMP, dengan gambar inline atau lampiran dari hampir semua jenis.

Antarmuka infrastruktur email dan batas-batas aplikasi yang diuji

Infrastruktur email, sebagai suatu peraturan, memiliki satu atau beberapa antarmuka melalui mana email dikirim (ketika memasuki antrian pengiriman MTA). Misalnya, layanan Pengiriman SMTP, function mail() dalam PHP, transfer data ke aplikasi email eksternal atau sendmail, API untuk layanan internal atau eksternal (seperti GetResponse, SendPulse, atau Amazon SES). Kami akan mempertimbangkan antarmuka ini sebagai bagian dari infrastruktur. Sering terjadi bahwa Aplikasi A menyiapkan data untuk email dan daftar penerima, dan kemudian mengirimkannya ke Aplikasi B melalui API-nya (untuk pemasaran surat massal, ini dapat dilakukan secara manual melalui antarmuka pengguna- UI), dan aplikasi B menghasilkan pesan di RFC 5322, dan mengirimkannya ke MTA. Untuk aplikasi A (dan saat mengujinya), aplikasi B akan menjadi bagian dari infrastruktur email. API atau UI aplikasi B akan untuk antarmuka aplikasi infrastruktur email. Meskipun untuk Aplikasi B, situasinya akan berbeda, dan infrastruktur surat untuknya adalah aplikasi atau protokol jaringan tingkat rendah.

Definisi parameter uji

Saat menguji setiap aplikasi, penting untuk memilih semua infrastruktur surat yang digunakan olehnya (mungkin ada beberapa di antaranya), dan untuk setiap infrastruktur untuk memilih antarmuka yang digunakan (mungkin ada beberapa di antaranya untuk setiap infrastruktur). Untuk setiap antarmuka, komposisi dan format data yang dikirimkan ke sana ditentukan seakurat mungkin, misalnya teks email dalam TEXT / HTML, teks email dalam TEXT / PLAIN, subjek email, nama penerima, alamat penerima, alamat penerima, nama pengirim, alamat pengirim, alamat pengirim (RFC5321.From), alamat pengirim konvektor SMTP (RFC5322.mailfrom). Selanjutnya, seperangkat persyaratan dikembangkan untuk setiap parameter (representasi, pengkodean, nilai batas, dll.), Metode untuk memantau masing-masing parameter ditentukan (cara membandingkan hasil aktual dengan yang diharapkan).

Struktur khas aplikasi pembangkit

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

• kode yang bertanggung jawab untuk menghasilkan tajuk dan / atau struktur email, jika struktur email dihasilkan secara dinamis, dan / atau templat email statis yang menggambarkan strukturnya;
  
• Layout HTML dari email (idealnya, itu adalah entitas yang terpisah atau bagian dari templat / layout email, tetapi dapat disematkan dalam kode aplikasi);
  
• substitusi data aplikasi menjadi email (atau ke templat email);
  
• integrasi aplikasi dengan infrastruktur pengiriman email, kebenaran parameter diteruskan ke antarmuka infrastruktur.
  

Apa dan kapan menguji

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

Infrastruktur pengiriman

Penekanan dalam pengujian harus dilakukan pada: pengiriman email; catatan DNS yang benar, termasuk catatan PTR / FCrDNS, MX dan A; Parameter protokol SMTP (HELO, gunakan TLS); otorisasi email (SPF / DKIM / DMARC); Alamat amplop SMTP (jika aplikasi tidak mengelolanya); kebenaran pemrosesan parameter input dari antarmuka infrastruktur; melacak, merekam, dan memproses email yang tidak terkirim.

Penting untuk menguji infrastruktur selama implementasi awal dan setiap kali perubahan dilakukan pada infrastruktur itu sendiri (konfigurasi MTA, DNS atau perubahan jaringan) atau antarmuka untuk mengirim email; menggunakan domain, jaringan, atau API baru; pengujian tambahan diperlukan jika karakteristik email yang dikirim, seperti bahasa, ukuran atau angka mereka berubah secara signifikan. Menurut pengalaman, infrastruktur cenderung berubah "dengan sendirinya", jadi tes dasar harus dilakukan secara berkala, bahkan jika tidak ada informasi tentang perubahan apa pun.

Dimungkinkan dan perlu untuk melibatkan insinyur jaringan dan spesialis kemampuan pengiriman dalam menyusun rencana dan daftar periksa untuk menguji infrastruktur.

Membuat aplikasi

Alamat amplop SMTP harus dipantau (jika aplikasi mengendalikannya, yaitu, mereka ditransfer ke antarmuka - amplop-dari, amplop-ke), nilai-nilai header layanan email (Tanggal, Pesan -ID, Daftar-Berhenti Berlangganan, Dikirim Otomatis, dll.). Klausul), otorisasi email (DKIM / DMARC), penyandian MIME (base64, dikutip-cetak), kebenaran umum format email, misalnya, tidak adanya karakter non-ASCII di header, komposisi data yang disuntikkan , pemicu yang tepat dari pemicu, mekanisme berhenti berlangganan, mekanisme pelacakan menulis dan mengumpulkan statistik (header postmaster, misalnya, Feedback-ID atau X-Mailru-Msgtype, serta piksel pelacakan).

Penting untuk menguji aplikasi selama pengembangannya, ketika semua komponen terkait yang bertanggung jawab untuk menghasilkan dan menyimpan perubahan data, dengan perubahan signifikan dalam template email, ketika mengubah infrastruktur atau antarmuka yang digunakan untuk itu, serta dalam kerangka kerja regresi umum.

Templat email struktural dan penataan huruf (dapat menjadi bagian dari aplikasi penghasil atau dikembangkan secara terpisah)

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

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

Disarankan untuk melibatkan spesialis pemasaran email dan spesialis kemampuan pengiriman untuk menyusun daftar periksa untuk menguji templat email.

Persyaratan dasar untuk memeriksa infrastruktur

Alamat IP yang dipilih untuk server surat harus sedekat mungkin dengan alamat IP server surat. Dianjurkan untuk memeriksanya menggunakan utilitas whois. Secara khusus, alamat pengirim tidak boleh milik jaringan, yang dapat dianggap dinamis; jaringan yang dipilih harus memiliki kontak aktif yang dapat mengirim keluhan; jaringan harus digunakan (memiliki status DITANDATANGANI di RIPE) Alamat IP harus memiliki catatan PTR yang dikonfigurasi dengan benar. Ini dapat dikonfigurasi secara independen melalui panel kontrol hosting, atau dengan bantuan penyedia layanan. Catatan PTR harus menunjuk ke nama host nyata dan masih bermakna, diputuskan kembali ke alamat IP yang sama (disebut cek FCrDNS), tidak mengingatkan nama host dinamis, dan tidak termasuk kelompok besar angka atau karakter. Contoh yang baik adalah mailserver.example.com.

Setiap domain yang digunakan dalam alamat amplop atau header email harus memiliki catatan MX yang valid yang menunjuk ke host Catatan, yang, setidaknya, dapat menangani pesan yang tidak terkirim. MX tidak diizinkan untuk langsung merujuk ke alamat IP.

Kontrol bagian SPF, DKIM, DMARC. SPF memungkinkan pemilik domain untuk menentukan dalam TXT mencatat daftar server yang berwenang untuk mengirim email dengan alamat pengirim di domain ini. Ini dikonfigurasikan untuk alamat yang digunakan dalam amplop-dari (amplop SMTP) di bagian pengelolaan zona DNS domain. DKIM memberikan verifikasi kepengarangan pesan atau pencetusnya ke domain tertentu menggunakan teknologi tanda tangan digital, yang ditambahkan ke email itu sendiri (di 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 email yang tidak lulus otentikasi SPF atau DKIM. Ketika mencoba untuk melanggar kebijakan ini, laporan terstruktur datang bersama dengan informasi tentang upaya tersebut. DMARC, serta SPF, diterbitkan sebagai catatan TXT di zona domain.

Periksa kemampuan pengiriman email ke layanan pos utama - untuk Russia Mail.Ru, Yandex, Gmail, Microsoft (Hotmail / Outlook.com / Office365), Rambler, nic.ru. Di email yang tiba, Anda perlu memeriksa kebenaran HELO; kehadiran dan perjalanan cek PTR / FCrDNS, SPF, DKIM, dan DMARC; validitas header dan data di dalamnya, khususnya, sinkronisasi jam di tanggal dan kebenaran zona waktu.


(Surat pendaftaran telah merusak otentikasi karena alamat freemail digunakan)

Pembentukan beberapa parameter, misalnya, otorisasi, pengiriman, dan spam secara integral dipengaruhi oleh semua komponen, tetapi untuk kontrol mereka, biasanya ada alat operasional yang terpisah - laporan DMARC dan FBL, API layanan postmaster, alat pelacakan email, statistik pengiriman. Pengujian harus mempertimbangkan tingkat implementasi alat pemantauan operasional di perusahaan - misalnya, dengan tidak adanya kontrol operasional laporan DMARC, otorisasi email harus diuji secara berkala, sedangkan jika tidak ada kontrol operasional pengiriman, di mana dan bagaimana email berjalan, bahkan jika tidak ada pengembangan terkait dengan pengiriman email.

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


(contoh dari catatan SPF yang rusak)

Persyaratan otentikasi

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 surat harus diperhitungkan (jangan lupakan sistem CRM, semua infrastruktur pengiriman yang saat ini 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 (https://medium.com/hackernoon/myths-and-legends-of-spf-d17919a9e817).

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 semua header penting ditandatangani (Dari, Ke, Subjek, Tanggal, ID-Pesan, Versi MIME, Tipe-Konten), bahwa header pelacakan (Diterima, Dikirimkan Ke, Jalur Kembali) tidak ditandatangani, dan DKIM divalidasi untuk layanan email dasar. Mengatur penerusan ke salah satu layanan surat ke yang lain; DKIM tidak boleh "mengalahkan" pada email yang diteruskan. Verifikasi bahwa domain tanda tangan DKIM cocok dengan domain pengirim dari header 'Dari'.

Periksa DMARC untuk layanan email 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). Anda kadang-kadang dapat memeriksa TLS dengan tajuk yang Diterima di server penerima: misalnya, menentukan protokol ESMTPS atau memiliki parameter formulir (versi = TLS1_2 cipher = ECDHE-RSA-AES128-GCM-SHA256 bits = 128/128); menunjukkan keberadaan TLS.

Verifikasi aplikasi penghasil

Persyaratan alamat email

Alamat amplop

Kami memulai verifikasi aplikasi pembangkit dengan alamat di amplop SMTP.
Alamat amplop adalah alamat tingkat infrastruktur email. Mereka tidak terlihat oleh pengguna, tetapi mereka penting untuk pengiriman karena alamat amplop menentukan ke kotak surat mana email masuk.

Alamat penerima dalam amplop ( envelope-to , alias RCPT TO: adalah alamat yang akan dikirimi email.

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

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

• Alamatnya tersedia;
  
• Ini bukan alamat karyawan dan tidak dialihkan 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 dapat dibuat secara otomatis, yaitu unik untuk setiap email;
  
• Email ke alamat ini tidak boleh mengarah ke pembuatan email respons apa pun, misalnya, pesan tentang kotak surat meluap.
  

Alamat tajuk email

Alamat-alamat ini dapat langsung dilihat oleh pengguna atau digunakan saat membalas email.
Alamat pengirim (header From: adalah alamat dan nama pengirim yang ditampilkan dalam daftar email dan saat membaca email. Kami memverifikasi bahwa:

• Ini adalah alamat ramah yang dapat dibaca manusia yang mengidentifikasi perusahaan.
  
• Ini tidak hanya berisi alamat email tetapi juga nama pengirim.
  
• Noreply @ dimungkinkan, tetapi hanya jika kami ingin menekankan bahwa kami tidak berharap menerima tanggapan terhadap email dan itu tidak akan dibaca. Lebih baik menggandakan ide ini dalam teks email.
  
• Di hadapan karakter non-ASCII (misalnya, Cyrillic), nama pengirim harus dikodekan sesuai dengan MIME, domain di hadapan karakter non-ASCII harus dikodekan dalam Punycode
  
• Email dari kategori yang sama harus memiliki alamat yang sama; penggunaan alamat yang dibuat secara otomatis harus dihindari. Ini disebabkan oleh fakta bahwa 'Dari:' paling sering digunakan oleh orang untuk mengurutkan email berdasarkan folder menggunakan filter.
  
• Alamatnya harus berbeda (lebih disukai di subdomain yang berbeda) untuk email transaksional, pemasaran, dan mendesak (seperti email 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 From: dan alamat amplop SMTP harus dalam domain yang sama atau dalam subdomain dari domain organisasi yang sama untuk dapat lulus SPF dalam DMARC.
  
• Alamat harus berasal dari domain organisasi. Tidak dapat diterima untuk menggunakan layanan surat gratis dan domain surat publik lainnya di From: karena surat-surat tersebut tidak akan lulus otentikasi SPF dan DKIM dalam kerangka DMARC.
  

Reply-to alamat Reply-to balasan 'manual' akan dikirim ke alamat ini ketika pengguna menjawab email. Itu opsional. Jika tidak ada, alamat dari 'Dari:' digunakan untuk respons. Periksa bahwa 'Balas-ke':

• Ini dapat dibuat secara otomatis, yaitu unik untuk email (memungkinkan Anda untuk mencari tahu di email mana jawabannya datang).
  
• Seharusnya tidak masuk ke kotak surat karyawan untuk menghindari jawaban otomatis, tetapi idealnya harus "dibungkus" dalam CRM.
  
• Itu dapat menghasilkan jawaban otomatis CRM standar, tetapi seharusnya tidak menghasilkan sesuatu yang berlebihan, misalnya, kotak surat meluap atau pesan "saat panggilan". 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 From: menjalankan fungsinya.
  
• Selain alamat, nama pengirim diindikasikan.
  

Alamat To:

• Harus mengandung email penerima (selain itu menakut-nakuti penerima pesan dan mengganggu 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 dapat memasukkan alamat orang lain dengan nama yang buruk, dan penerima mungkin tersinggung).
  

Persyaratan tajuk email

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

Header From:, Message-ID: dan Date: harus dibentuk langsung dalam skrip untuk mengirim email (dan menurut standar - bersama dengan teks email) dan selalu dalam format yang benar. Jika tidak ada atau tidak terbentuk dengan benar, salah satu server transit dapat menambahkan tajuk 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.


(konfirmasi pendaftaran dalam penyandian aneh)

Persyaratan untuk struktur email

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

Menurut RFC 5322, panjang baris dalam email 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 (ascii 13, ascii 10), yang membutuhkan 2 oktet. Anda perlu memeriksa kebenaran terminator string, karena email sering dikirim menggunakan skrip Unix, dan di Unix, terminator string adalah karakter tunggal - ini adalah kesalahan untuk email. Anda juga harus memeriksa apakah terminator string memecah karakter-karakter yang dikodekan UTF-8: Anda tidak dapat mengizinkan adanya terminator string antara dua oktet dari karakter yang sama, misalnya, simbol Cyrillic. Untuk menghindari situasi seperti itu, perlu untuk memecah teks sebelum membentuk email atau menyandikan teks di base64, base64 biasanya memiliki panjang garis tetap.

Penting untuk memeriksa tanda yang benar dari lampiran dan inline - yaitu, kebenaran pembentukan header "Content-Disposition: inline", jika itu adalah gambar yang ditampilkan di dalam email, atau "Content-Disposition: attachment" jika file terlampir dimaksudkan untuk diunduh.

Struktur email harus sesederhana mungkin: khususnya, tidak boleh ada lebih dari satu bagian multi bagian dari setiap jenis (campuran, alternatif, terkait), dan multi bagian / campuran digunakan hanya jika email berisi lampiran file, multipart / related - if HTML dilengkapi dengan gambar sebaris, multipart / alternatif - di hadapan teks biasa dan bagian HTML. Secara umum, struktur email, dengan tidak adanya lampiran dan gambar sebaris, akan terlihat seperti ini:

multipart / alternatif
- teks / polos
- teks / html

Urutan bagian-bagian ini penting, teks / polos harus SEBELUM teks / html atau multi bagian / terkait. Ini diperlukan agar bagian HTML ditampilkan secara default, dan hanya jika tampilan tidak tersedia karena alasan tertentu, bagian yang biasa ditampilkan.

Jika ada gambar sebaris di email, strukturnya akan terlihat seperti ini:

multipart / alternatif
- teks / polos
- multi bagian / terkait
—— teks / html
—— gambar / ... (gambar sebaris)
—— gambar / ... (gambar sebaris)

Gambar sebaris harus memiliki Content-Disposition: inline dan secara ketat berada di dalam bagian multi bagian / terkait.
Dalam kasus yang paling sulit, ketika ada gambar inline dan file lampiran, email memiliki struktur sebagai berikut:

multi bagian / campuran
- multipart / alternatif
—— teks / polos
—— multi bagian / terkait
——— teks / html
——— gambar / png
——— gambar / png
...
- aplikasi / octet-string (konten-disposisi: lampiran)
- aplikasi / octet-string (konten-disposisi: lampiran)
...
multipart terkait- dan multipart / alternatif-bagian harus ditutup sebelum lampiran, lampiran milik multipart eksternal / bagian campuran)


(pesan pendaftaran dengan struktur bagian yang salah)

Persyaratan URI

URI apa pun (dalam src, atribut href, gaya, dll.) Harus berisi protokol dan nama host (https://example.com/somepath). Kesalahan umum adalah penggunaan tautan relatif (/ somepath) dan kurangnya protokol (//example.com/somepath), yang tidak dapat diterima untuk email, karena di dalamnya, protokol default dapat berupa file:// .

• Setiap layanan dan karakter non-ASCII (khususnya, Cyrillic) di URI harus dikodekan menggunakan persen pengkodean.
  
• Tautan yang disisipkan sebagai teks (yaitu, terlihat oleh pengguna sebagai URL, dan bukan sebagai bagian dari teks) masih harus ditandai dengan tag <> , jika tidak, pengguna tidak akan dapat mengkliknya. Beberapa webmail menandai tautan semacam itu sendiri, tetapi ini bukan perilaku standar. Dalam hal ini, alamat href di dalam A harus cocok dengan teks tautan, jika tidak, filter konten dapat bereaksi terhadap tautan tersebut sebagai upaya untuk menipu pengguna. Ini sangat berharga untuk diperhatikan ketika ada "clickers" yang melacak transisi pengguna dari email.
  
• Lebih baik membatasi diri pada penggunaan protokol http:// , https:// dan mailto:
  
• Dengan persyaratan keamanan tinggi, Anda harus sepenuhnya mengabaikan penggunaan http:// demi https:// .
  
• Port non-standar tidak boleh digunakan (misalnya, example.com : 8080 / somepath), karena port tersebut mungkin tidak dapat diakses oleh pengguna.
  
• Mengklik tautan di dalam bagian HTML tidak boleh mengarah ke perubahan apa pun dalam keadaan aplikasi (berlangganan, berhenti berlangganan, pembatalan pesanan, dll.) Tanpa konfirmasi tambahan oleh pengguna pada halaman, karena beberapa sistem penyaringan konten dapat secara mandiri memverifikasi keamanan transisi semacam itu dengan meminta halaman dengan referensi; aplikasi surat dapat menunjukkan pratinjau halaman dengan tautan di hover, dan browser modern dapat memuat halaman sebelum pengguna mengklik tautan untuk mengurangi waktu buka (dalam aplikasi web umumnya tidak disarankan untuk melakukan tindakan modifikasi apa pun pada DAPATKAN permintaan, semua permintaan modifikasi harus melalui POST atau PUT).
  
• Mengklik tautan di header Daftar-Berhenti Berlangganan, sebaliknya, seharusnya tidak memerlukan tindakan tambahan dari pengguna, karena berhenti berlangganan oleh tautan ini biasanya dilakukan oleh program email atau webmail atas nama pengguna. Juga, ada tajuk baru List-Unsubscribe-Post yang diperkenalkan oleh RFC 8058.
  
• Anda seharusnya tidak mengharapkan pengguna untuk membaca email dan mengikuti tautan di browser yang sama di mana ia memulai tindakan yang mengarah pada pengiriman email (misalnya, mendaftarkan akun). Tautan harus berfungsi di peramban atau perangkat seluler lainnya. Secara khusus, pengguna dapat membuka tautan tanpa diotorisasi, atau diotorisasi dalam akun selain dari yang digunakan untuk mengirim email.
  
• Karena panjang URI bisa dibatasi; Anda tidak boleh menggunakan URI dari tipe 'data:' untuk objek besar. Untuk alasan yang sama, jangan gunakan URI yang terlalu panjang dalam hyperlink.
  
• Anda tidak boleh menggunakan penyingkat tautan eksternal, ini memengaruhi pengiriman email secara negatif. Lebih baik jika semua tautan mengarah ke domain Anda, ini akan mengurangi dampak negatif potensial dari reputasi orang lain pada pengiriman email.
  
• Jangan letakkan gambar eksternal di beberapa layanan publik atau hosting gratis, gunakan layanan hosting yang dapat diandalkan atau CDN dengan kinerja dan reputasi yang baik.
  

(gambar tidak valid dan anchor URI karena spesifikasi protokol yang hilang)

Persyaratan tata letak email

Mengapa begitu sulit untuk membuat email?

Klien email dengan satu atau lain cara menampilkan konten pengguna dalam antarmuka mereka. Berpotensi, ini dapat menyebabkan berbagai masalah keamanan - skrip lintas situs (XSS, skrip Crossite), spoofing antarmuka, clampber DOM, deanonimisasi pengguna / kebocoran informasi (misalnya, alamat IP pengguna atau cookie melalui permintaan eksternal), dll Oleh karena itu, setiap layanan surat dan aplikasi surat memiliki beberapa bentuk perlindungan terhadap setiap kelas serangan. Sayangnya, tidak ada pendekatan tunggal untuk mengatur perlindungan ini. Ini dapat diatur melalui:

• frame terbatas terisolasi,
  
• tag dan / atau atribut filtering,
  
• pembatasan posisi absolut,
  
• larangan atau pembatasan penggunaan gaya blok (yang sangat penting untuk tata letak adaptif),
  
• melarang elemen eksternal secara default (mis. mengunduh gambar eksternal memerlukan izin pengguna) atau menggunakan proxy untuk mengaksesnya,
  
• mengonversi email HTML ke format perantara lainnya (misalnya, Microsoft Exchange / Outlook menggunakan RTF, yang dapat membuatnya sangat sulit untuk menampilkan elemen dengan benar di Outlook menggunakan metode konvensional),
  
• larangan atau pembatasan penggunaan formulir atau elemen individualnya.
  

Surel juga menggunakan elemen-elemen spesifik, seperti gambar sebaris dan cid:// URI cid:// , yang dukungannya mungkin terbatas. Misalnya, Mozilla Thunderbird tidak mendukung cid:// untuk gambar latar belakang.

Bahkan email yang dibentuk dengan benar dapat ditampilkan secara berbeda di antarmuka yang berbeda karena kekhasan penerapannya dan penyaringan konten email.

Jika ada kesalahan dalam format email, perilaku menjadi sepenuhnya tidak dapat diprediksi. Misalnya, klien email mungkin memiliki perilaku berbeda dengan URI yang salah, atau bahwa pemformatan header yang salah ditangani secara berbeda. Juga, deteksi otomatis penyandian teks berfungsi berbeda jika tidak ditentukan atau tidak ditentukan dengan benar. Oleh karena itu, email harus dilihat dalam antarmuka yang berbeda: tampilan email yang benar dalam satu antarmuka tidak berarti bahwa email tersebut disusun dengan benar (pada kenyataannya, bahkan tampilan email yang benar di semua antarmuka tidak menjamin bahwa tidak akan ada masalah dengan tampilan di masa depan).



Perlu memperhatikan hal-hal berikut:

• Periksa teks email untuk konten semantik, tampilan, tidak adanya kesalahan ketik, sintaksis, ejaan, dan kesalahan leksikal.
  
• Periksa kebenaran substitusi data aplikasi dalam templat atau tata letak email.
  
• Periksa kebenaran jumlah, tanggal, angka, barang, dan informasi lainnya, dengan mempertimbangkan ketentuan batas yang diizinkan. Tanggal harus satu tahun (beberapa pengguna memasukkan kotak sangat jarang). Zona waktu harus ada dalam waktu. Alamat harus berisi kota, dan dalam beberapa kasus, perlu untuk menunjukkan negara.
  
• Periksa status operasional semua tautan di email, jika ada.
  
• Dalam email yang dikirim sebelum konfirmasi alamat, termasuk email dengan tautan konfirmasi, seharusnya tidak ada teks yang dikendalikan dari luar, bahkan nama pengguna, jika tidak, mereka dapat digunakan untuk spam (di bidang yang ditampilkan dalam email, misalnya, dalam nama, teks spam dimasukkan dan alamatnya adalah alamat yang ditunjukkan dari korban). Misalnya, jika Anda dapat mengirim teks cabul di alamat pengembang atas nama layanan Anda, maka ada masalah.
  
• Periksa tidak adanya gambar eksternal pada layanan pihak ketiga. Ini dapat memengaruhi pengiriman dan kebocoran informasi tentang pelanggan Anda.
  
• Periksa ketersediaan penghitung untuk pengiriman, pengiriman, membaca email, transisi. Beberapa dari mereka berada di dalam email itu sendiri (misalnya, pixel counter dari membaca email), beberapa dilacak oleh pengirim, tetapi, sebagai suatu peraturan, semua tersedia di panel admin pengirim.
  
• Periksa kebenaran kategori berlangganan dan berhenti berlangganan pengguna untuk kategori ini melalui tautan di email.
  
• Periksa bagaimana email terlihat:
  
  • Versi web surat populer untuk negara yang ditargetkan: "tiga besar" untuk Rusia adalah Mail.Ru, Yandex, Gmail. Anda juga dapat menambahkan Rambler dan Outlook.com;
    
  • Aplikasi seluler dari penyedia email di atas;
    
  • Aplikasi seluler standar menggunakan IMAP, dengan mempertimbangkan platform seluler populer, untuk setidaknya iPhone, Pixel (platform referensi Android), Samsung (yang paling umum untuk Android), MIUI (mengambil tempat kedua di Rusia untuk platform Android);
    
  • Berbagai browser desktop: Chrome, Firefox, Edge, Internet Explorer, Opera, dll.;
    
  • Aplikasi desktop (program email), terutama Thunderbird, Outlook dan Apple Mail, secara opsional The Bat! dan Opera Mail;
    
  • Solusi korporat populer dengan antarmuka web (Exchange, mungkin Roundcube, Communigate, Zimbra, SquirrelMail) - untuk solusi B2B;
    
  • Jangan lupa untuk memeriksa tata letak monitor Retina dan monitor dengan resolusi lebih rendah.
    
• Selama memeriksa dalam setiap kasus, Anda perlu memperhatikan:
  
  • Melewati tajuk otorisasi, SPF / DKIM / DMARC.
    
  • Kecepatan unduh email: harus dimuat dengan cepat, dan tidak memakan waktu.
    
  • Menampilkan email dalam daftar email: avatar, nama pengirim dan subjek yang termasuk dalam cuplikan pesan, apakah kategorinya didefinisikan dengan benar (misalnya, jika urutannya tidak termasuk dalam kategori "jejaring sosial").
    
  • Tata letak email secara keseluruhan: jika tata letak tetap konsisten, adakah kesalahan kata yang salah, dll., Termasuk saat menskala dan mengubah ukuran jendela.
    
  • Font tidak boleh kecil atau sulit dibaca.
    
  • Gambar latar belakang dan warna latar belakang.
    
  • Cocok dengan buku merek.
    
  • Kemudahan melakukan tindakan yang tersirat oleh email. Misalnya, jika email berisi kode konfirmasi atau informasi lain yang mungkin perlu disimpan di suatu tempat, maka itu tidak hanya harus dibaca dengan baik, tetapi juga harus nyaman untuk memilih dan menyalinnya bahkan di antarmuka seluler.
    
  
  
• Pantau ukuran keseluruhan email (termasuk gambar eksternal) dan tidak melebihi nilai wajar. Semakin berat waktu muat, semakin besar kemungkinan seseorang akan memiliki reaksi negatif terhadapnya.
  
• Bahkan email yang belum diubah harus diperiksa secara berkala, karena perubahan dapat terjadi di sisi layanan pos, dan, misalnya, "mengungkapkan" masalah yang sebelumnya tidak terlihat.
  
• Beberapa parameter harus dikontrol dalam semua tes. Misalnya, masalah dengan lolosnya otentikasi DKIM dapat disebabkan oleh masalah dalam infrastruktur (masalah dengan DNS atau pembentukan tanda tangan DKIM, kesalahan sinkronisasi waktu), karena kesalahan dalam program pembangkit (alamat pengirim salah, karakter salah dalam header tidak ada atau wajib Dari, Tanggal, atau header ID-Pesan telah digandakan) dan karena kesalahan konten (terminator baris yang salah, baris terlalu panjang, alamat salah). Pada saat yang sama, email mungkin tidak "mengalahkan", dan masalahnya mungkin tidak muncul di layanan apa pun.
  

Melakukan Split-Test

Riset pemasaran berada di luar cakupan artikel ini, tetapi beberapa poin penting yang secara signifikan mempengaruhi kualitas email harus disebutkan.

The newsletter has a purpose, so it should entail through its quality, not quantity (which is the opposite for spammers). The newsletter must be segmented. When conducting an advertising campaign, you need to know exactly who gets into the segment sample, why they need the offered product and what they want to convey.

For each mailing list, it is necessary to calculate the CTR of the list of emails — this is the ratio of the number of emails read to the total number that has been sent out. In postmaster.mail.ru, you can see indicators for unique users. If the measurement goes through the counter in the email (pixel), then the absolute number of openings is estimated. CTR <10% is a very low indicator, it is undesirable to carry out such mailing. It should strive for a CTR> 30%. For marketing emails, the clickthrough rate of clickthroughs and the percentage of completed actions («sales») on these links are also of great importance. Be sure to monitor complaints (marking the email as spam). Typically, for one-time mailings, a tenth of a percent is a good indicator, for regular ones, a hundredth of a percent. The critical values, after which the mailing is always interpreted as spam, are indicated here: https://help.mail.ru/developers/mailing_rules/technical .

It is necessary to conduct split testing of various distribution options to obtain optimal performance. Just changing the name of the sender and the subject of the email can increase the CTR by several times and significantly reduce the number of complaints. The number of emails should be statistically significant for evaluating the results (for large projects, usually a few thousand). The final version of the email is sent in several stages for additional measurement of indicators and «warming up» — starting with about 10,000 recipients, with an increase of about an order of the day.

The main idea: emails are part of your application, perhaps one of the most complex and problematic. At the same time, this is often a «blind spot» in terms of testing. I hope that I was able to draw your attention to this issue.

I would like to thank Vladimir Dubrovin ( z3apa3a ) and Alena Likhacheva ( s4ever ) for helping me with this article. As well as that, the article utilised sources of Eduard Tyantov ( edT ) and Alexander Purtov ( 4Alexander ).