Ekibinizin yeni bir parola sıfırlama e-postası yayına aldığını varsayın. QA, staging'de onay veriyor: ileti geliyor, bağlantı çalışıyor, şablon doğru görünüyor. Yayından iki gün sonra destek ekibinin önünde bir bilet kuyruğu var. Gmail adresi olanlar e-postanın hiç gelmediğini söylüyor. Birkaç büyük şirketteki kişiler ise e-postanın geldiğini, ama bağlantının ilk tıklayışta "zaten kullanılmış" göründüğünü bildiriyor. Staging ile üretim arasında kodu kimse değiştirmedi ve her test hâlâ geçiyor.
Peki hangi geliştirici test e-posta adresi bunu yakalardı? Hiçbiri tek başına. Yerel bir SMTP yakalayıcı günlük geliştirmeye, sağlayıcınızın sandbox'ı ya da denetlediğiniz bir test alan adı otomatik testlere, gerçek bir harici gelen kutusu ise postanın üretime benzer kurulumunuzdan çıkıp bir yabancının alan adına ulaştığını görmek için yapılan elle denetime uygundur. VookMail gibi geçici bir gelen kutusu, sayfa yüklendiğinde adres hazır olduğu için bu son durumu hiçbir kurulum olmadan karşılar. Büyük posta sağlayıcılarındaki örnek hesaplar da bunların hiçbirinin göremediği kısmı kapsar. Bu rehberin geri kalanı, bu seçenekler arasından seçim yapmayı, hatalar ortaya çıktığında okumayı ve bir yayına ait denetimleri anlatıyor.
O sıfırlama staging'de neden geçti
Staging ile üretim, dağıtım şemasının düşündürdüğü kadar nadiren birbirine benzer ve e-posta, farkları çoğu özellikten daha çok ortaya çıkarır. Bir ileti uygulamanızdan, bir kuyruktan, bir sağlayıcıdan, DNS'ten, alıcının sunucusundan ve alıcının istemcisinden geçer. Staging bunların neredeyse hepsinin farklı bir sürümünü kullanıyor olabilir.
İlk bilete, hiçbir şey almayan Gmail kullanıcılarına bakın. Staging'in aylar önce doğrulanmış bir sağlayıcı alt alan adı üzerinden gönderdiğini, üretimin ise yeniden markalamayla gelen yeni bir From alan adından gönderdiğini varsayalım. Google'ın gönderici yönergeleri tüm göndericilerin SPF ya da DKIM ile kimlik doğrulaması yapmasını şart koşar ve Gmail hata tablosu, kimliği doğrulanmamış posta için 5.7.26 kodunu listeler. Kendi alan adınızdaki dahili bir QA posta kutusu aynı iletiyi geçirebilir, çünkü kendi sunucunuz kendi aktarıcınıza güvenebilir. Test hiçbir zaman başarısız olamazdı.
İkinci biletin, "zaten kullanılmış" bağlantısının nedeni farklı. Kurumsal güvenlik ağ geçitleri, gelen postadaki bağlantıları kişi görmeden önce taramak için çoğunlukla açar. Bağlantınız jetonu düz bir GET isteğiyle kullanıma sokuyorsa tarayıcı onu tüketir ve çalışan ölü bir bağlantıya tıklar. Kendi şirketiniz tesadüfen bir tane kullanmıyorsa, sizin hiçbir staging posta kutunuz o tarayıcıyı çalıştırmaz.
Bu iki hata aynı yerden görülemez. Biri, sizin işletmediğiniz bir alıcı sisteme gerçek teslimat gerektirir. Öteki, bağlantının davranışında bir değişiklik gerektirir ve bunu bir test değil bir kod incelemesi daha kolay yakalar. Katmanlı testin gerekçesi budur: her adres türü tek bir soruyu yanıtlar ve ötekilerde sessiz kalır.
| Staging ile üretim arasında sık değişen şey | Neyi gizleyebilir |
|---|---|
Gönderen alan adı ve From adresi | Eksik ya da hizalanmamış SPF ve DKIM |
| Sağlayıcı hesabı ya da alt hesabı | Sandbox modu, gönderim limitleri, farklı bir IP itibarı |
| Alıcılar | Size güvenen dahili alan adları ve kötü adresleri gizleyen izin listeleri |
| Tıklama izleme | Bozulan yeniden yazılmış bağlantılar ya da geçerli sertifikası olmayan bir izleme alan adı |
| Hacim | Yalnızca yük altında ısıran kuyruklar ve hız sınırları |
| Bastırma listeleri | Bir kez geri sekmiş ve artık sessizce atlanan üretim adresleri |
| Temel URL ayarları | Yanlış sunucuyu gösteren bağlantılar |
Hangi adres hangi soruyu yanıtlar
Seçenekler şunlar; her biri gerçekten yanıtlayabildiği soruyla birlikte.
Yerel bir yakalayıcı: "uygulamam ne üretti?"
Bir SMTP yakalayıcı, uygulamanızın gönderdiği her şeyi kabul eder ve hiçbir şey teslim etmeden bir web sayfasında gösterir. Mailpit popüler bir açık kaynak seçenektir. Varsayılan olarak SMTP için 1025 numaralı bağlantı noktasını dinler ve web arayüzünü 8025'te sunar; bu yüzden geliştirme ayarlarınızı localhost:1025 adresine yöneltir ve http://localhost:8025 adresini açarsınız. Nodemailer'in Ethereal'ı, barındırılan sahte bir SMTP hizmetiyle benzer bir fikirdir. Yakalayıcı hızlı ve özeldir; gerçek bir kişiye ulaşma riski olmadan herhangi bir adrese göndermenize izin verir. DNS, kimlik doğrulama ya da filtreleme hakkında da bir şey söylemez, çünkü internetten hiçbir şey geçmez.
Bir çatının test yardımcısı: "kodum doğru postayı istedi mi?"
Çoğu çatı (framework), bir test çalışması sırasında giden postayı bellekte kaydedebilir. Laravel'de Mail::fake() var, Django iletileri django.core.mail.outbox içinde toplar ve Rails'de ActionMailer::Base.deliveries vardır. Bunları, bir işin doğru alıcı ve jetonla bir kez tetiklendiğini doğrulamak için kullanın. Alabileceğiniz en hızlı geri bildirimdir ve dış dünyadan yakalayıcıdan da daha azını test eder.
Bir sağlayıcının test modu: "entegrasyonum çalışıyor mu?"
Sağlayıcılar burada farklı türde yardım sunar ve farklar önemlidir. Amazon SES'in success@simulator.amazonses.com, bounce@simulator.amazonses.com ve complaint@simulator.amazonses.com gibi adreslerle bir posta kutusu simülatörü vardır; bu adresler itibarınıza zarar vermeden o sonuçları üretir. Yeni bir SES hesabı da yalnızca doğrulanmış adreslere gönderebildiği bir sandbox'ta başlar. SendGrid'in mail_settings.sandbox_mode.enable ile ayarlanan sandbox modu, isteğinizi teslim etmeden doğrular. Postmark aynı amaçla POSTMARK_API_TEST jetonunu kabul eder. Bunlar API hataları ile geri sekme ve şikâyet webhook'ları için iyidir; postanın birine ulaştığını göstermez. Bu özellikler değiştiği için kendi sağlayıcınızın güncel belgelerine bakın.
Sahip olduğunuz bir test alan adı: "tam akış tekrar tekrar çalışıyor mu?"
Otomatik uçtan uca testler için denetlediğiniz bir alan adı ya da alt alan adı kurun; tüm postayı yakalayan bir posta kutusu ya da gelen bir webhook ile test kodunuz postayı bir API üzerinden okuyabilsin. Kurması biraz çaba ister, ama özel ve kararlıdır ve başka birinin web sitesine bağlı değildir. Sahibi olmadığınız alan adlarında adres uydurmayın. Birinin testuser@gmail.com adresi olabilir ve gönderdiğiniz şeyi o alır. RFC 2606, belgelerin ve test verilerinin işaret edebileceği güvenli bir yer olsun diye example.com ile .test ve .example üst düzey adlarını ayırır. Bu adlar posta alamaz; bu da onları test verileri için doğru, teslimat testleri için işe yaramaz yapar.
Gerçek bir harici geçici gelen kutusu: "bir yabancının alan adı bunu alır mı?"
Geçici bir gelen kutusunun yerini hak ettiği yer burası. Denetlemediğiniz ve izin listesi tutmadığınız bir alan adındaki gerçek bir posta kutusudur. İletinizin MX kaydını bulması, bir SMTP bağlantısı kurması ve kabul edilmesi gerekir. VookMail'de alan adlarının MX kayıtları, iletiyi alıp HTTPS üzerinden ileten bir posta teslim sağlayıcısını gösterir. Taze bir adres aynı zamanda geçmiş olmaması demektir: eski ileti yok, bastırma listenizde daha önce geri sekme yok, filtre yok. Bu da "yeni bir adresle kayıt oldum ve hiçbir şey gelmedi" durumunu yeniden üretmenin hızlı bir yolu yapar. Geliştirici olmayanlar için de yararlıdır. Bir tasarımcı ya da ürün yöneticisi, araçlarınıza erişimi olmadan yeni bir kullanıcının ne aldığını okuyabilir.
Büyük posta sağlayıcılarında örnek hesaplar: "nereye düşüyor?"
Bir alan adında teslim edilen ileti, başka bir alan adındaki spam klasörü hakkında hiçbir şey söylemez. Kullanıcılarınızın gerçekten kullandığı sağlayıcılarda küçük bir gerçek hesap kümesi tutun ve önemli şablon ya da alan adı değişikliklerinden önce yerleşimi kontrol edin. Sonra bir yayından sonra geri sekme ve şikâyet sayılarını izleyin. Postanız bir spam sorunu gibi görünüyorsa, bunu ilk bu hesaplarda görürsünüz.
| Yaklaşım | İnternetten geçer mi | Kurulum | Otomasyon | İçerik gizliliği | En uygun aşama |
|---|---|---|---|---|---|
| Çatı test yardımcısı | Hayır | Yok | Mükemmel | Süreç içinde kalır | Birim ve özellik testleri |
| Yerel SMTP yakalayıcı | Hayır | Düşük | İyi | Yerelde kalır | Geliştirme |
| Sağlayıcı test modu | Genellikle hayır | Düşük | İyi | Sağlayıcıda kalır | Entegrasyon testleri |
| Kendi test alan adınız | Evet | Orta ile yüksek | İyi | Siz denetlersiniz | CI uçtan uca, staging |
| Geçici gelen kutusu | Evet | Yok | Önerilmez | Herkese açık sayın | Elle QA ve yayın öncesi denetimler |
| Örnek hesaplar | Evet | Orta | Sınırlı | Orta | Yerleşim denetimleri |
Geçici gelen kutusuyla elle bir çalıştırma
Staging ya da üretim öncesi bir ortamdaki kayıt akışından tekrarlanabilir bir geçiş şöyle. Bir kez öğrendiğinizde yaklaşık on dakika sürmeli.
- Ortamın, kimlik bilgileri dışında üretimle aynı sağlayıcı yapılandırmasını kullandığını ve yalnızca uydurma veri içerdiğini doğrulayın. Aksi hâlde bunu yazın, çünkü çıkarabileceğiniz sonuçları sınırlar.
- VookMail'i açın ve Yeni'ye basın. Testi kodlayan bir kullanıcı adı yazın, örneğin
email-signup-03-x7, 30'dan fazla alan adından birini seçin ve oka basın. İletide hassas olabilecek bir şey varsa sarı Rastgele düğmesini kullanın, çünkü bir adresi bilen ya da tahmin eden herkes o gelen kutusunu açabilir. - Kopyala'ya basın ve uydurma profil verileriyle yeni bir kullanıcı olarak kayıt olun.
- Gönderdiğiniz zamanı ve iletinin göründüğü zamanı not edin. Gelen kutusu birkaç saniyede bir bakar; bu yüzden dakikalarca süren bir boşluk kuyruğunuzu ya da sağlayıcınızı işaret eder. Emin olmak isterseniz Yenile'ye basın.
- İletiyi yeni bir kullanıcı gibi okuyun: gönderici adı, konu, önizleme metni, gövde, düğme, düz bağlantı, alt bilgi. VookMail algılanan kodları ve onay bağlantılarını iletinin üstünde gösterir; bu, kodunuzun ve bağlantınızın kolayca seçilip seçilmediğine dair kabaca bir denetimdir.
- Görseller kapalıyken bakın. VookMail siz izin verene kadar görselleri kapalı tutar ve gizli izleme piksellerini kaldırır. İleti o durumda anlamsızsa, bazı kullanıcılarınız da aynısını görüyordur. Yine de açılma izlemenizi değerlendirmek için bu gelen kutusunu kullanmayın, çünkü pikseller tetiklenmez.
- QR düğmesine basın, adresi bir test telefonuyla taratın ve gerçek bir cihazda gerçek bağlantıya dokunmak için aynı gelen kutusunu orada açın; özellikle evrensel bağlantılar (universal links) ya da uygulama bağlantıları kullanıyorsanız.
- Doğrulamayı tamamlayın ve hesap durumunun olması gerektiği gibi değiştiğini onaylayın.
- Aşağıdaki kontrol listesindeki olumsuz durumları çalıştırın: bağlantıyı yeniden kullanın, süresinin dolmasını bekleyin, yeniden gönderme isteyin.
- Kanıtınızı kaydedin: ekran görüntüleri, zaman damgaları ve kullanılan adres. İletiler yaklaşık bir gün sonra silinir; bu yüzden gelecek hafta yazılan bir hata raporunun gösterecek bir şeyi olmaz.
- Sürecinizin gerektirdiği hâlde Sil'e basın ve test hesabını kaldırın.
Aynı tarayıcıda birkaç adres tutulabilir; bu yüzden bir davet eden ve davet edilen ya da bir e-posta değişikliğinin eski ve yeni adresleri aynı anda açık olabilir. Testinizde dosya eklerseniz, VookMail'in .exe gibi yaygın program dosyalarını reddettiğini ve arşivlerde bir uyarı gösterdiğini unutmayın; yani orada reddedilen bir ek sizin tarafınızda bir hata olmayabilir.
Bir hatayı okumak
"E-posta hiç gelmedi", yaklaşık altı yerden herhangi birindeki bir belirtiyi tarif eder ve ekipler yanlış yerden başlayarak saatler kaybeder. Kodunuzdan dışarıya doğru yol boyunca ilerleyin ve iletiyi artık göremediğiniz ilk yerde durun.
- Uygulama denedi mi? Uygulama günlüğünde gönderim girişimini ve herhangi bir istisnayı arayın. Hiç oluşturulmamış bir işe bakın; genellikle bir koşul ya da özellik bayrağı yanlış olduğu için.
- İşçi çalıştı mı? Takılmış, başarısız ya da yeniden denenmiş işlere bakın. Bir dağıtımdan sonra yeniden başlatılmamış bir kuyruk işçisi eski kodu çalıştırabilir ve bir yeniden deneme politikası kopya gönderebilir.
- Sağlayıcı kabul etti mi? Alıcıyı ya da
Message-IDdeğerini sağlayıcınızın etkinlik günlüğünde arayın. Kabul edildi, ertelendi, geri sekti ve düşürüldü dört ayrı hikâyedir. - Bastırıldı mı? O adres daha önce geri sekmiş ya da şikâyet almışsa, birçok sağlayıcı gelecekteki gönderimleri sessizce atlar. Bu, eski bir adresi yeniden kullanan test edenleri çoğu zaman yakalar.
- Alıcı sunucu ne dedi? Sağlayıcı günlükleri genellikle SMTP yanıtını gösterir ve bu metin tüm incelemedeki en yararlı satırdır.
- DNS doğru mu? Gerçek gönderen alan adı için SPF, DKIM ve DMARC'ı kontrol edin.
- Orada ama gizli mi? Spam klasörleri, sekmeler ve istemci filtreleri en sona kalır; bir örnek hesap size gösterebildiğinde.
SMTP yanıtı size ne söylüyor
RFC 5321 uyarınca 4 ile başlayan bir yanıt geçici bir hatadır ve gönderen daha sonra yeniden denemelidir. 5 ile başlayan bir yanıt kalıcıdır. RFC 3463'teki geliştirilmiş durum kodları bundan sonra ayrıntı ekler. Uydurma bir günlük satırı, yalnızca biçimin bir örneği olarak şöyle görünebilir:
Yalnızca örnek: to=user@gmail.example status=bounced reply="550 5.7.26 unauthenticated sender"
Soldan sağa okuyun. 5, yeniden denemelerin yardımcı olmayacağı anlamına gelir. 5.7 ailesi güvenlik ya da politika ile ilgilidir; bu sizi alıcının adresinden uzağa, DNS'e ve imzalamaya yönlendirir. Aşağıdaki tablo, yaygın kalıplar için bir başlangıç noktası verir.
| Gördüğünüz | En olası katman | İlk bakılacak yer |
|---|---|---|
| Sağlayıcı günlüğünde hiçbir şey yok | Uygulama ya da kuyruk | Uygulama günlükleri ve başarısız işler |
| Sağlayıcı "dropped" ya da "suppressed" diyor | Sağlayıcının bastırma listesi | Test adresini kaldırın ya da yenisini kullanın |
| API başarı döndürüyor ama hiçbir şey gönderildi diye kaydedilmiyor | Sandbox modu hâlâ açık | O ortam için sağlayıcı ayarları |
5.1.1 ya da benzeri | Alıcı adresi | Yazım hataları ve adresi değiştiren form doğrulaması |
Gmail'de 5.7.26 | Kimlik doğrulama | SPF, DKIM ve From alan adıyla hizalama |
Bir süre sonra geçen 4xx ertelemeleri | Alıcı sizi yavaşlatıyor | Hacim, itibar ya da yeni bir gönderen IP |
| Harici bir gelen kutusunda teslim edildi, Gmail'de yok | Alıcının politikası ya da filtrelemesi | Örnek hesaplar ve Google'ın gönderici yönergeleri |
| Geliyor ama bağlantı "zaten kullanılmış" diyor | Bağlantıyı önceden getiren tarayıcı | Jetonları GET ile değil POST ile kullanıma sokun |
| Bağlantı bir güvenlik uyarısına çıkıyor | Tıklama izleme alan adı | İzleme alt alan adındaki sertifika |
| İki kez geliyor | Yeniden deneme mantığı | İş tekrarlanabilirliği (idempotency) ve yeniden denemeleri tetikleyen zaman aşımları |
| Çok geç geliyor | Kuyruk | İşçi kapasitesi ve sıfırlama postasının toplu postayla aynı kuyruğu paylaşıp paylaşmadığı |
Son satır, ek bir cümleyi hak eden bir tasarım noktasıdır. Parola sıfırlamaları bir bülten gönderimiyle aynı kuyruğu paylaşıyorsa onun arkasında bekler. İşlemsel postaya kendi kuyruğunu, mümkünse kendi alt alan adını ve gönderim akışını verin; böylece bir pazarlama sorunu bir girişi geciktirmez.
Aramayı kısaltan komutlar
Bunların çoğunu terminalinizden çıkmadan kontrol edebilirsiniz. Bu örneklerde örnek adları kendi adlarınızla değiştirin.
dig +short MX example.combir alan adının postayı nerede aldığını gösterir. Boş bir yanıt daha yakından bakmayı gerektirir; çünkü RFC 5321 göndericilerin bir adres kaydına geri dönmesine izin verir,0 .yanıtı ise RFC 7505 uyarınca bir boş MX'tir (null MX) ve alan adının hiç posta kabul etmediği anlamına gelir.dig +short TXT example.comdiğer metin kayıtları arasında SPF kaydını gösterir.dig +short TXT selector._domainkey.example.combir DKIM anahtarını gösterir. Gerçek seçiciyi iletininDKIM-Signaturebaşlığındakis=değerinden alın.dig +short TXT _dmarc.example.comDMARC politikasını gösterir.openssl s_client -starttls smtp -connect smtp.example.com:587aktarıcınıza ulaşabildiğinizi denetler ve sertifikasını gösterir. Burada bir hata, içerikle ilgili herhangi bir şeyden çok önce bir güvenlik duvarı ya da TLS sorunu demektir.swaks --to qa@example.test --from app@example.test --server localhost:1025elle basit bir ileti gönderir. Uygulamanızı atlar; böylece sorunun kodunuza mı yoksa yola mı ait olduğunu anlayabilirsiniz.
Başlık düzeyindeki kanıt için en güvenilir görünüm, büyük bir sağlayıcıda denetlediğiniz bir posta kutusudur. Gmail'de iletiyi açın, üç nokta menüsünü kullanın ve en üstte SPF, DKIM ve DMARC sonuçlarını listeleyen Orijinali göster'i seçin. Bir alıcının "geçti" demesinin bir başkasınınkini garanti etmediğini aklınızda tutun.
Her akışta nelere bakılmalı
"Geldi mi?" ilk sorudur ve genellikle en az ilginç olanıdır. Bundan sonra her akışın kendine ait ters gitme yolları var.
Parola sıfırlama
OWASP Forgot Password Cheat Sheet, burada üzerine inşa edilecek referanstır. Hesap var olsa da olmasa da tutarlı bir ileti, tek tip sürede dönen yanıtlar, rastgele, uzun, güvenli saklanan ve tek kullanımlık jetonlar ve sıfırlama sayfasında Referrer-Policy: no-referrer ister.
- İstek sayfası kayıtlı ve kayıtsız adresler için aynı iletiyi gösterir ve yaklaşık aynı sürede döner. Bilinmeyen adresler için anlık bir yanıt, ifade kadar bilgi sızdırır.
- Bağlantı bir kez çalışır. İkinci kez açtığınızda başka bir istek yapma yoluyla birlikte net bir açıklama alırsınız.
- Yeni bir sıfırlama istemek eski bağlantıları geçersiz kılar ya da tasarımınız bilerek aksini söyler.
- Süre dolumu sunucu tarafından uygulanır ve beklenerek ya da bir test ortamında saat değiştirilerek test edilmiştir.
- Başarılı bir sıfırlama bir onay e-postası gönderir ve diğer oturumlar politikanıza göre ele alınır.
- Bağlantıyı açmak kendi başına hiçbir şeyi değiştirmez. Jeton form gönderildiğinde kullanıma sokulur.
- Sıfırlama sayfası URL'sini üçüncü taraf analitiğe ya da hata izlemeye göndermez.
- Hız sınırları IP başına olduğu kadar hesap başına da uygulanır; böylece kimse bir yabancının gelen kutusunu dolduramaz.
- Büyük küçük harf karışık ya da artı işareti içeren adresler basit olanlarla aynı çalışır.
Kayıt doğrulaması
- Bir kayıt bir ileti gönderir; iş yeniden denendiğinde de.
- Bağlantı ya da kod bir kez çalışır ve süresi dolmuş bağlantı sayfası ileriye bir yol sunar.
- Yeniden gönderme ya önceki jetonu geçersiz kılar ya da tasarlandığı gibi onunla birlikte var olur ve hız sınırlıdır.
- Doğrulanmamış hesapların tam olarak amaçladığınız kısıtlamaları vardır.
- Kayıtlı bir adresle yeniden kayıt olmak, ürününüz bunu hassas sayıyorsa, anonim bir ziyaretçiye hesabın var olduğunu söylemez. Yaygın bir kalıp, bunun yerine mevcut sahibine e-posta göndermektir.
- Bağlantı doğru ortama işaret eder. Üretime bağlanan bir staging iletisi er geç üretim verisini değiştirir.
Giriş kodları ve sihirli bağlantılar
- Kodlar yeterince uzundur, hızla sona erer ve bir deneme sınırı vardır.
- Sihirli bağlantılar bir düğmeli açılış sayfası gösterir ve o POST üzerinde kullanıma sokulur; böylece bir tarayıcının GET'i zarar vermez.
- Bağlantıyı başka bir cihazda açmak tasarımınızın söylediğini yapar ve kullanıcı ne olduğunu anlayabilir.
- Konu satırı yalnızca bunun kabul edilebilir olduğuna karar verdiyseniz bir kod taşır, çünkü bildirimler onu kilit ekranlarında gösterir.
E-posta adresi değişikliği
- Onay yeni adrese gider ve onaylanana kadar hiçbir şey değişmez.
- Eski adrese bir bildirim gider; böylece gerçek sahip yetkisiz bir değişikliğe tepki verebilir.
- Bekleyen sıfırlama jetonları değişiklikten sonra çalışmayı bırakır.
- İki geçici gelen kutusu bunu elle çalıştırmayı hızlandırır.
Davetler, makbuzlar ve bildirimler
- Hesabı olmayan birine gelen bir davet, tasarlandığı gibi adresi önceden doldurulmuş ya da kilitli bir kayda götürür. Süresi dolmuş ya da iptal edilmiş bir davet bunu söyler.
- Bir davet, tasarımınız izin vermedikçe farklı bir hesap tarafından kabul edilemez.
- Makbuzlar kullanıcının yerel ayarı için doğru tutarları, para birimlerini, tarihleri ve saat dilimlerini gösterir; ekler anlamlı adlara sahiptir ve düzgün açılır.
- Tercih değişiklikleri bir sonraki gönderimde etkili olur.
- Zorunlu olmayan postanın çalışan bir abonelikten çıkması vardır; hesap ve güvenlik postası ise net biçimde ayrıdır. Bülten yığılması makalemiz bunun okuyucu tarafından nasıl göründüğünü gösteriyor.
- Desteklenen her dil için çevrilmiş şablonlar vardır; gerekli yerde doğru sağdan sola yerleşimle ve konuda çevrilmemiş parça olmadan.
Jeton kodunu gözden geçirmek
Bir gelen kutusu üzerinden test etmek davranışı gösterir. Kısa bir kod incelemesi, hiçbir gelen kutusunun size göstermeyeceği tasarım kusurlarını yakalar. Sıfırlama, doğrulama ve sihirli bağlantıların arkasındaki kodu okurken şunlara bakın.
- Rastgelelik kaynağı. Python'da
secrets.token_urlsafe(32), Node'dacrypto.randomBytes(32)ya da PHP'derandom_bytes(32)gibi kriptografik olarak güvenli bir üreteç olmalıdır. Bir zaman damgası, artan bir kimlik ya da e-postanın bir özeti kabul edilemez. - Uzunluk. Bağlantı jetonları genellikle en az 128 bit rastgelelik taşır. Altı haneli bir kod yalnızca sıkı süre dolumu ve deneme sınırıyla uygundur.
- Saklama. Jetonun bir özetini (hash) saklayın; böylece bir veri tabanı sızıntısı çalışan sıfırlama bağlantıları dağıtmaz.
- Karşılaştırma. Gizli değerleri doğrudan karşılaştırdığınız yerde
hmac.compare_digest,hash_equalsya dacrypto.timingSafeEqualgibi sabit zamanlı bir işlev kullanın. - Amaç. Bir doğrulama jetonu sıfırlama jetonu olarak çalışmamalı ve bir hesabın jetonu başka bir hesap için çalışmamalıdır.
- Süre dolumu. Süre dolum zamanını sunucu tutar; bu yüzden bağlantıyı düzenleyerek değiştirilemez.
- Geçersiz kılma. Jetonun kullanılması, başka bir yoldan parola değişikliği ya da e-posta değişikliği, bekleyen tüm jetonları iptal etmelidir.
- Günlükleme. Jeton içeren tam URL'ler uygulama günlüklerine, analitik olaylarına ya da hata izleyicilere ulaşmamalıdır. HTTP erişim günlüklerinize de bakın.
Başlıklar ve kimlik doğrulama
Uygulamanızın ne ürettiğini görmek için ham kaynağı bir yakalayıcıda, sağlayıcının ve ağın ne eklediğini görmek için büyük bir sağlayıcıda denetlediğiniz bir posta kutusunda açın.
| Başlık ya da öğe | Neyi doğrulamalı |
|---|---|
From | Sahibi olduğunuz ve kimliğini doğruladığınız bir alan adında doğru marka adı |
Reply-To | İzlenen bir posta kutusu ya da bilerek atlanmış |
Return-Path | Geri sekme alan adı; DMARC için SPF'e güveniyorsanız alan adınızla hizalı |
DKIM-Signature | Mevcut, From alan adıyla hizalanan bir d= alan adıyla |
Message-ID | Mevcut ve benzersiz; sağlayıcı günlüklerinde izleme anahtarınız |
Content-Type | Hem HTML hem düz metin bölümleri olan multipart/alternative |
List-Unsubscribe, List-Unsubscribe-Post | Toplu ve pazarlama postasında mevcut, RFC 8058 uyarınca tek tıkla abonelikten çıkmayı destekler |
Auto-Submitted | Yanıt döngülerini önlemeye yardım etmek için RFC 3834'te tanımlandığı gibi otomatik postada auto-generated |
Yeni bir gönderen alan adını yayına almadan önce denetlenecek bazı kurallar. Bir SPF değerlendirmesi on DNS aramasını aşamaz (RFC 7208) ve kaydınıza bir tedarikçi daha ekledikten sonra sınırı aşmak başarısız olmanın kolay bir yoludur. DKIM, sağlayıcının seçici kaydının yayımlanmış ve doğrulanıyor olmasını ister. DMARC, From alan adınızda bir kayıt ister; genellikle raporlar açık olarak p=none ile başlar ve hizalama onaylandıktan sonra sıkılaştırılır.
Hacim de kuralları değiştirir. Google'ın yönergeleri, bir göndericiyi kişisel Gmail hesaplarına günde yaklaşık 5.000 ileti noktasında toplu sayar ve toplu göndericiler SPF, DKIM ve DMARC'a, promosyon postasında tek tıkla abonelikten çıkmaya ve %0,3'ün altında tutulan kullanıcı bildirimli spam oranına ihtiyaç duyar; önerilen hedef %0,1'dir. Diğer sağlayıcıların kendi kuralları var. Örneğin Amazon SES, %5 geri sekme oranında ya da %0,1 şikâyet oranında bir hesabı incelemeye alır. Bunlar değiştiği için etrafında plan yapmadan önce güncel rakamları sağlayıcınızın belgelerinden okuyun.
Adres işleme ve doğrulama
Formlar, insanların fark ettiğinden daha sık geçerli adresleri reddeder ve yukarı akıştaki bir doğrulama hatası tam olarak bir teslimat hatası gibi görünebilir. Kendinizinkini şunlarla test edin.
| Girdi | Beklenen işleme | Yaygın hata |
|---|---|---|
user+tag@example.com | Kabul et | Bir düzenli ifade artı işaretini reddeder |
User@Example.COM | Kabul et ve alan adını büyük küçük harfe duyarsız say | Yalnızca harf büyüklüğüyle ayrılan yinelenen hesaplar |
o'brien@example.com | Kabul et | Reddedilir ya da kaçışlanmazsa bir sorguyu veya şablonu bozar |
first.last@sub.example.co.uk | Kabul et | Doğrulama alan adında tek nokta olduğunu varsayar |
| Baştaki ya da sondaki boşluklar | Önce kırp | Doğru yapıştırmada "Geçersiz e-posta" |
| Çok uzun bir adres | Yerel kısım için 64 ve toplam için 254 karakter uygula | Kısa bir veri tabanı sütunu onu sessizce keser |
| Uluslararasılaştırılmış alan adları ve adresler | Net bir iletiyle tutarlı biçimde kabul et ya da reddet | Kodlamada ya da günlüklemede bir çökme |
| Posta yolu olmayan bir alan adı | Uyar ya da reddet | Hiçbir zaman doğrulanamayacak bir hesap |
Formda gevşek doğrulayın, sonra adresin çalıştığını onay e-postasının kanıtlamasına izin verin. Sıkı bir düzenli ifade gerçek kullanıcıları kaybettirir ve bir posta kutusunun var olup olmadığı hakkında çok az şey söyler.
Ürününüz üretimde tek kullanımlık alan adlarını reddediyorsa, QA sürecinizin staging'de yine de bir geçiş yoluna ihtiyacı var. Seçenekler arasında üretim dışında test alan adlarından oluşan bir izin listesi, test ortamlarında denetimi kapatan bir bayrak ya da kendi test alan adınız bulunur. Testi kolaylaştırmak için üretim kuralını zayıflatmayın. Ve o kurala sahip olup olmayacağınıza karar veriyorsanız, web sitelerinin tek kullanımlık e-postayı neden engellediği yazımız maliyet ve yararları bir sahibin gözünden ortaya koyuyor.
Nasıl görüntüleniyor
Görüntüleme, bir tasarımcının incelemesinin en çok yardımcı olduğu yerdir ve gerçek istemcilerde gerçek iletilere ihtiyaç duyar.
- Düz metin bölümü iyi okunur ve tam bağlantıyı içerir. "Aşağıdaki düğmeye tıklayın" orada işe yaramaz.
- Koyu mod logoları görünür bırakır ve kontrastı korur. VookMail'in koyu modu var, bu bir başlangıçtır; asıl test ise kullanıcılarınızın tercih ettiği istemcilerdir.
- Görseller engelliyken çağrı yine de gerçek bir metin bağlantısı ya da HTML düğmesidir.
- Düğmeler dokunmak için yeterince büyüktür ve uzun URL'ler bir telefon yerleşimini bozmaz.
- Önizleme metni bilerek yazılmıştır; şablondan kalma ifade yoktur.
- Başlıklar anlamsaldır, kontrast yeterlidir, bağlantı metni açıklayıcıdır ve HTML'de bir dil özniteliği vardır.
- Eksik veri "Merhaba {first_name}" ya da "Merhaba ," üretmez.
- İleti boyutu, Gmail'in uzun iletileri kestiği yaygın olarak bildirilen yaklaşık 102 KB'nin epey altında kalır. Kesme, alt bilginizi ve gövdedeki abonelikten çıkma bağlantısını gizleyebilir.
Kazalara karşı korkuluklar
Utandırıcı e-posta olayları çoğunlukla yapılandırma hatalarıdır: gerçek müşterilere ulaşan staging postası, test anahtarıyla çalışan üretim, localhost adresine giden bağlantılar. Birkaç ayar çoğunu önler.
Her ortam için ayrı kimlik bilgileri tutun; ortam değişkenlerinde ya da bir gizli anahtar yöneticisinde. Üretim dışında bir alıcı izin listesi kullanın; böylece posta gönderici yalnızca onaylı test alan adlarına teslim eder, geri kalan her şeyi yönlendirir ya da düşürür. Her bağlantıyı APP_URL gibi tek bir ayardan oluşturun; böylece şablonlarda sabit kodlanmış sunucu olmaz. Üretim dışı konuları [STAGING] gibi bir önekle başlatın ki yanlış yönlendirilmiş bir ileti, alan kişiye belli olsun.
Üretim verisini staging'e kopyalıyorsanız, herhangi bir posta işçisi başlamadan önce her gerçek adresi sentetik bir adresle değiştirin. Sıra önemlidir, çünkü önce başlayan bir işçi zamanlanmış postayı hemen işlemeye başlayabilir. Ve her ortam için sandbox modunu bilinçli olarak izleyin. Üretimin hâlâ sandbox'ta olduğu bir yayın klasiktir: API başarı döndürür, günlükler temiz görünür ve hiçbir posta çıkmaz.
Otomatik paketler denetlediğiniz altyapıda kalmalı
Herkese açık bir geçici gelen kutusu CI için yanlış bağımlılıktır. Başkasının web sayfasını kazımak kırılgandır ve derlemeleriniz kodunuzla ilgisiz nedenlerle başarısız olur. Ayrıca test trafiğinizi işletmediğiniz bir hizmete yerleştirir. Oradaki iletileri adresi bilen herkes okuyabilir; bu yüzden otomatik hiçbir şey onlara bağlı olmamalıdır.
Makul bir düzen şöyle görünür. Çatı yardımcıları doğru postanın istendiğini doğrular. Test yığınınızdaki bir Mailpit konteyneri gerçek iletiyi alır ve testiniz onu Mailpit'in HTTP API'si (GET /api/v1/messages) üzerinden okur, bağlantıyı çıkarır ve izler. Sağlayıcının test modu webhook'ları ve hata işlemeyi sınar. Kendi test alan adınızdaki gecelik bir iş gerçek sağlayıcı üzerinden gönderir ve sonucu bir gelen webhook ile okur; böylece gerçek teslimatın hâlâ çalıştığına dair günlük bir sinyal alırsınız.
Geçici posta, testin insani kısımlarına aittir: hızlıca taze bir kimliğe ihtiyaç duyduğunuz keşif oturumları, yayın öncesi bir duman testi, bir kullanıcının bildirimini yeniden üretmek, metin ve tasarım incelemeleri ve telefonda test. Sonuncusu için QR düğmesi ya da Google Play veya Huawei AppGallery üzerindeki uygulama gelen kutusunu bir test cihazına getirir. Uygulamanız kuruluyken bağlantıların onu açtığını, kurulu değilken çalışan bir web sayfasına döndüğünü ve uygulamanın yeni bir oturum açmayı gerektirmeden doğrulanmış durumu fark ettiğini kontrol edin.
Devir teslimden sağ çıkan bir test senaryosu
Tutarlı test senaryolarını her yayında tekrarlamak ve test edenler arasında aktarmak daha kolaydır. Bu örnek, önemli olma eğiliminde olan alanları içeriyor.
| Alan | Örnek |
|---|---|
| Test kimliği | EMAIL-RESET-03 |
| Akış | Parola sıfırlama, jetonun yeniden kullanımı |
| Ön koşullar | Staging'de taze bir geçici adresli, doğrulanmış test hesabı |
| Adımlar | Bir sıfırlama isteyin, bağlantıyı açın, yeni bir parola belirleyin, aynı bağlantıyı yeniden açın |
| Beklenen sonuç | İkinci kullanım bağlantının artık geçerli olmadığını açıklar ve yeni bir istek önerir |
| Kanıt | Ekran görüntüleri, varsa Message-ID, zaman damgaları, kullanılan adres |
| Ortam | Staging derleme numarası ve posta yapılandırması |
Test kimliğini kullanıcı adına koymak, email-reset-03-x7 örneğindeki gibi, her gelen kutusunu senaryosuna bağlar ve iki test edenin aynı adreste çakışmasını önler. Kısa rastgele sonek oradadır, çünkü adı tahmin eden herkes bir gelen kutusunu açabilir.
Herkese açık bir gelen kutusuna neler gönderilmemeli
Her geçici gelen kutusunu, adresi bilen herkesin okuyabileceği biçimde ele alın ve ona göre test edin.
- Yalnızca sentetik veri gönderin: sahte adlar, sahte siparişler, sahte adresler. Gerçek müşteri verisi oraya ait değildir ve faaliyet gösterdiğiniz yere bağlı olarak göndermek sizin için hukuki bir sorun da yaratabilir.
- Asla API anahtarları, veri tabanı kimlik bilgileri ya da gerçek sistemlere yönetici davetleri göndermeyin.
- Test hesaplarını, özellikle ayrıcalıklı olanları düzenli silin. Herkese açık bir gelen kutusuna bağlı bir yönetici test kullanıcısı, başkası o gelen kutusunu açıp sıfırlama isterse bir giriş yoludur. Adres temizlendikten sonra size ayrılmış olmadığı için bu risk testten sonra da sürer.
- Geçici bir adresi asla gerçek bir üretim hesabının ya da şirketinizin güvendiği bir üçüncü taraf hizmetin sahibi olarak kullanmayın.
- Saklama süresini bilin. İletiler ve ekler yaklaşık bir gün sonra gider ve ayrıntılar gizlilik politikasında.
Kendi ürününüzü test etmek, tek kullanımlık e-postanın en net meşru kullanımlarından biridir. Öyle kalmasını sağlayın: sahibi olduğunuz ya da test etme yetkiniz bulunan sistemleri test edin. Geçici gelen kutularını başka şirketlerin hizmetlerinde koşullarına aykırı hesap oluşturmak, deneme sürümleri toplamak ya da başkasının kayıt formuna yük testi yapmak için kullanmayın. Kullanım koşulları kabul edilebilir kullanımı kapsıyor ve metodoloji sayfası hizmetin nasıl çalıştığını açıklıyor. VookMail, PAYATE ücretsiz araçlar ağının bir parçasıdır.
Yayından önce
- Gerçek üretim gönderen alan adı için SPF, DKIM ve DMARC doğrulanmış,
Fromalan adı hizalanmış. - Üretim posta göndericisi üretim kimlik bilgileriyle çalışıyor, sandbox modu kapalı, gerçek bir iletiyle doğrulanmış.
- Kayıt doğrulaması taze bir harici adreste alındı, bağlantı bir kez kullanıldı, süre dolumu test edildi.
- Parola sıfırlama uçtan uca test edildi; bilinmeyen adresler için aynı yanıtlar ve onay iletisi dahil.
- Sıfırlama ve sihirli bağlantı jetonları bir form gönderimiyle kullanıma sokuluyor; böylece bir tarayıcının GET'i onları tüketmiyor.
- E-posta değişikliği hem yeni hem eski adrese gönderiyor.
- Tüm bağlantılar, tıklama izlemeyle yeniden yazılanlar dahil, HTTPS üzerinden üretim sunucusuna işaret ediyor.
- İşlemsel posta, en azından kuyruğunda, toplu postadan ayrılmış.
- HTML ve düz metin ikisi de mevcut ve okunabilir; koyu mod ve engellenmiş görseller kontrol edilmiş.
- Alan adı ya da şablon önemli ölçüde değiştiyse örnek hesaplarda bir yerleşim denetimi.
- Zorunlu olmayan postada çalışan abonelikten çıkma ve çevrilmiş şablonlar gözden geçirilmiş.
- Kanıt yayın biletine eklenmiş; geri sekme ve şikâyet sayıları, lansmandan sonra birinin izleyeceği bir panoda.
Geliştiricilerin bu konuda sorduğu sorular
Gerçek bir gelen kutusu postamı kabul etti. Gmail'de güvende miyim?
Hayır. Bir alan adına teslimat, iletinizin çıktığını, bir yol bulduğunu ve orada kabul edildiğini gösterir. Gmail kendi kimlik doğrulama kurallarını ve filtrelemesini uygular, diğer her büyük sağlayıcı da öyle. Bu soru için örnek hesapları ve Google'ın Postmaster Tools'unu kullanın.
Aynı test adresini yeniden kullanabilir miyim?
Bir oturum içinde kullanabilirsiniz, ama taze bir adres size daha temiz bir test verir. Eski adresler bastırma girdileri ve eski iletiler biriktirir ve geçici bir hizmette gelen kutusu zaten yaklaşık bir gün sonra temizlenir.
Posta yakalayıcıma geliyor ama dışarıya gelmiyor. Nereden başlamalıyım?
Yakalayıcı, uygulamanızın bir ileti ürettiğini gösterir ve ötesini göstermez; bu yüzden sağlayıcının etkinlik günlüğüyle başlayın. Çoğu zaman cevap bir sandbox ayarı, bir bastırma girdisi, yanlış kimlik bilgileri ya da kimlik doğrulamayı adıyla anan bir SMTP reddidir.
Bir sıfırlama bağlantısı ne kadar süre geçerli kalmalı?
Zararı sınırlayacak kadar kısa ve yavaş postanın ulaşmasına yetecek kadar uzun. Birçok ekip 15 dakika ile bir saat arasında bir yerde karar kılar, ama bu riskinize ve postanızın ne kadar hızlı teslim edildiğine bağlıdır ve kullanıcılarınızın postası denetiminizin ötesinde gecikebilir. Ne seçerseniz seçin, süresi dolmuş durumu test edin ve insanlara sonra ne yapacaklarını söyleyin.