List-Unsubscribe Nedir? Tek Tıkla Abonelikten Çıkma

List-Unsubscribe, bir e-postanın başlık kısmında yer alan ve alıcı sistemin "abonelikten çık" düğmesini göstermesini sağlayan alandır; List-Unsubscribe-Post ise bu düğmeye basıldığında tek bir HTTPS isteğiyle çıkışı tamamlayan ek alandır. İkisi iletinin gövdesindeki görünür bağlantının yerini tutmaz, onunla birlikte çalışır. Bu bilgiler bülten, kampanya ve bilgilendirme e-postası gönderen blog sahipleri, yayıncılar ve e-ticaret işletmeleri içindir. Bu yazı hukuki tavsiye değildir; izin ve yükümlülükler için yetkili bir uzmana ya da ilgili mevzuata başvurun.

Abonelikten çıkma başlığı neden ayrı bir sinyal

Bir e-postada abonelikten çıkmanın iki ayrı yolu vardır ve ikisi farklı kişilere hizmet eder. Gövdedeki bağlantı, iletiyi okuyan kişiye yöneliktir. Başlıktaki alan ise iletiyi işleyen posta programına ya da posta hizmetine yöneliktir; bu program, iletinin üstünde ya da yanında bir "abonelikten çık" seçeneği çıkarabilir. İkisi aynı sonuca götürmeli, ama birbirinin yerine geçmez.

Gövdedeki bağlantı: okur içindir

Bir okur iletiyi açtığında görmesi gereken şey, alt bilgide açıkça okunabilen bir abonelikten çıkma bağlantısıdır. Gmail'in gönderici yönergeleri, pazarlama ve abonelik iletilerinin tek tıkla abonelikten çıkmayı desteklemesini ve ileti gövdesinde açıkça görünür bir abonelikten çıkma bağlantısı içermesini ister. Yani yönerge, başlığı yeterli saymaz; görünür bağlantı da bulunmalıdır.

Başlık: alıcı sistem içindir

Başlıktaki alan, iletiyi okumadan önce sistemin kendi arayüzünde bir çıkış yolu sunar. RFC 2369 (yeni sekmede açılır), bu alanın amacını şöyle tarif eder: kullanıcıyı listeden doğrudan çıkarmak için kullanılacak komutu belirtmek; belgede komutun tercihen e-posta ile verilmesi gerektiği yazar. RFC 2369 liste komutu başlıklarını yalnızca posta listelerinin üretmesi gerektiğini, son kullanıcıların üretmemesi gerektiğini ve bir iletide her alandan en çok bir tane bulunabileceğini de söyler. Yani aynı iletide birden çok List-Unsubscribe alanı yazmak yanlıştır; birden çok seçenek tek alanın içinde, virgülle ayrılmış olarak yer alır.

Gmail ne istiyor

Gmail gönderici yönergeleri (yeni sekmede açılır), Gmail için tek tıkla abonelikten çıkmayı kurmak üzere iki başlığın birlikte eklenmesini ister: List-Unsubscribe ve List-Unsubscribe-Post. Sayfadaki örneklerde List-Unsubscribe-Post alanının değeri List-Unsubscribe=One-Click biçimindedir ve List-Unsubscribe alanı açılı parantez içinde bir HTTPS adresi taşır. Yönergelerin 1 Şubat 2024'ten itibaren uygulandığı bilgisi sayfada yer alır. Hangi gönderenlerin bu kuralın kapsamına girdiğini, sayfadaki toplu gönderici tanımına bakarak kendiniz kontrol edin; sayfanın bu eşik için başlık ve gövdede kullandığı ifadeler birbirinden küçük farklarla yazılmıştır.

mailto, https ve ikisini birlikte yazmak

List-Unsubscribe alanının değeri, açılı parantez içine alınmış bir ya da daha fazla adrestir. RFC 2369'a göre bu adresler mailto: ya da http: biçimindedir ve posta aktarım sunucularının parantezlerin içine boşluk eklememesi gerekir. Bir alıcı programın, parantezle başlamayan bir alanı yok sayması beklenir; yani sözdizimi hatası, başlığın tümünün işlevsizleşmesine yol açabilir.

Birden çok adres: tercih sırası soldan sağa

RFC 2369'a göre birden çok alternatif adres, açılı parantezli adreslerin virgülle ayrılmış listesi olarak verilebilir. Adreslerin tercih sırası soldan sağadır; istemci, desteklediği ilk soldaki adresi kullanır ve her komut için yalnızca tek adres kullanır. İlk adres başarısız olursa diğerine geçebilir. Bu yüzden iki adres yazıyorsanız, hangisini öncelikli görmek istiyorsanız onu sola koyun.

mailto neden hâlâ anılır

RFC 2369'un girişinde, e-posta dışındaki protokollere erişimi olmayan kullanıcıları desteklemek için bir mailto: komutunun eklenmesi gerektiği yazar. Belgedeki örnekler bir HTTP adresiyle bir mailto adresini birlikte gösterir, böylece web destekli istemci web seçeneğini, diğerleri e-posta seçeneğini kullanabilir. RFC 8058 ise tek tıkla işlev için listede bir HTTPS adresi bulunmasını zorunlu kılar ve mailto gibi diğer adreslerin de bulunabileceğini söyler.

Kullanıcının onayı

RFC 2369'un güvenlik bölümü, kullanıcının bir komut çalıştırılmadan önce onay verme fırsatı bulunmasını gerekli sayar. Mailto komutlarında istemci, iletiyi göndermeden bir taslak olarak kullanıcıya gösterebilir. Bu ilke, aşağıda anlatılan tek tıkla yöntemde de karşımıza çıkar: alıcı sistem, kullanıcının onayı olmadan POST göndermemelidir.

Tek tıkla POST yöntemi

RFC 8058 (yeni sekmede açılır), iletinin başlık alanlarına dayalı bir "tek tıkla" abonelikten çıkma işlevi tanımlar. Bu belgenin ortaya çıkış nedeni, posta güvenlik yazılımlarının iletideki adresleri otomatik açmasıdır: bir adresin yalnızca GET isteğiyle çıkışı tamamlaması, bir tarayıcı yazılımının yanlışlıkla aboneliği iptal etmesine yol açabilir. Bu nedenle tek tıkla çıkış, POST üzerinden tanımlanmıştır.

İki başlık, tek anahtar

RFC 8058, 3.1 ve 5. bölümlerine göre gönderici ileti içine bir List-Unsubscribe başlığı ve bir List-Unsubscribe-Post başlığı koyar. List-Unsubscribe-Post alanının içeriği tek bir anahtar/değer çifti olmalıdır: List-Unsubscribe=One-Click. 6. bölüm, alanın bu tek çiftle sınırlanma nedenini, saldırganın keyfi form gönderimlerini taklit edememesi olarak açıklar. List-Unsubscribe alanı ise tam bir HTTPS adresi içermelidir; mailto gibi başka adresler de bulunabilir.

DKIM imzası şart

RFC 8058, 4. bölüm: gönderici en az bir geçerli DKIM imzası uygulamalıdır ve List-Unsubscribe ile List-Unsubscribe-Post başlıkları imza tarafından kapsanmalı, yani DKIM imzasının h= listesinde yer almalıdır. İleti bu imzayı taşımıyorsa alıcı, o ileti için tek tıkla çıkış önermemelidir. Bu, DMARC ve DKIM kurulumuyla ilişkilidir: başlıkları imzalayan ayarın doğru yapılması gerekir.

POST isteği ve gövdesi

Alıcı sistem, List-Unsubscribe adresine HTTPS POST gönderir. RFC 8058, 3.2'ye göre istek gövdesinde List-Unsubscribe-Post anahtar/değer çifti bulunur; içerik türünün multipart/form-data olması önerilir (SHOULD), application/x-www-form-urlencoded da olabilir (MAY). Aynı belgeye göre POST hedefi, elle yapılan GET abonelikten çıkış isteğinin hedefiyle aynı adrestir; yani tek adres, hem bir kullanıcı tarayıcıda açtığında çıkış sayfasını hem de POST isteğini karşılayabilir.

Yönlendirme yok, çerez yok

RFC 8058, 3.1: gönderici HTTPS yönlendirmesi döndürmemelidir (MUST NOT), çünkü yönlendirilen POST isteklerinin sıklıkla GET'e dönüştürüldüğü görülmüştür. Aynı bölüm, POST isteğinin çerez, HTTP yetkilendirmesi ya da başka bir bağlam bilgisi içermemesi gerektiğini söyler. 6. bölüm bunu, sunucunun isteği önceki web isteklerine bağlayamaması olarak açıklar. Sonuç olarak abonelikten çıkma adresi, oturum açmış olmayı ya da çerezi gerektiremez; hangi aboneyi çıkaracağını yalnızca adresin içindeki bilgiden anlamalıdır.

Adrese gömülecek belirteç

RFC 8058, adresin taklit edilmesi zor ya da "opak" bir bileşen içermesini önerir (SHOULD) ve sunucunun bunu doğrulamasını önerir. Belge, iletiye erişimi olan herkesin alıcıyı abonelikten çıkarabileceğini güvenlik bölümünde açıkça not eder; bunun mevcut List-Unsubscribe kullanımında da geçerli olduğunu ekler. Ayrıca çıkış isteğinin bir adresin geçerli olduğunu açığa çıkarabileceğini ve adres yoklamada kullanılabileceğini söyler. Bu nedenle adreste e-posta adresini düz metin olarak değil, tahmin edilemeyen bir belirteç taşımak ve yanıtta adresi doğrulayan ya da yalanlayan ayrıntılar vermemek iyi bir uygulamadır. Bu uygulama önerisidir; belge yalnızca belirteç bulunmasını önerir.

Gövdedeki görünür bağlantı ile uyum

Başlıkta tek tıkla çıkış kurmak, gövdedeki bağlantıyı gereksiz kılmaz. Gmail yönergesi iki şeyi birlikte ister: tek tıkla çıkışı destekleyen başlıklar ve ileti gövdesinde açıkça görünür bir bağlantı. İki yolun uyumu, kullanıcının nereden çıktığından bağımsız olarak aynı sonuca ulaşması demektir.

Aynı kayıt, aynı sonuç

Başlıktaki adres ve gövdedeki bağlantı, aynı abonelik kaydını aynı biçimde kapatmalıdır. RFC 8058, POST hedefinin elle yapılan GET çıkış isteğinin hedefiyle aynı olduğunu söylediği için sunucu tarafında tek bir işleyici yeterlidir. Pratikte iki ayrı akış kurmak, birinde çıkışı kaydedip diğerinde unutmak gibi tutarsızlık riski doğurur.

Aynı adresin GET davranışı

RFC 8058 tek tıkla davranışı yalnızca POST için tanımlar ve aynı adrese gelen GET isteğinin nasıl işleneceğini belirtmez. Bölüm 1'de posta güvenlik yazılımlarının başlıklardaki adresleri otomatik açtığı belirtilir. Uygulama önerisi: gövdedeki bağlantıya gelen GET isteğinde çıkışı hemen tamamlamak yerine, kullanıcıya kısa bir onay sayfası gösterin; böylece bir tarayıcı yazılımının yanlışlıkla aboneliği kapatması önlenir. Bu bir öneridir; belge GET için bir kural koymaz.

Karar kuralı: hangi biçimi yazmalıyım?

1. Gmail adreslerine gönderiyor ve yönergelerin kapsamına girdiğinizden emin değilseniz: görünür bağlantıyı koyun, List-Unsubscribe-Post ve HTTPS adresini ekleyin ve imzaya dahil edin.
2. Gönderim aracınız başlıkları kendisi ekliyorsa: elle ekleme yapmayın; aracın ayarında tek tıkla çıkışın açık olduğunu ve imzaya dahil edildiğini doğrulayın.
3. Kendi kodunuzla gönderiyorsanız: önce HTTPS uç noktasını, belirteci ve DKIM imzasını kurun; sonra başlıkları ekleyin.
4. Bir mailto yedeği istiyorsanız: onu HTTPS adresinin sağına koyun; böylece tercih sırası HTTPS'in lehine kalır.
5. Başlık eklemeden önce çıkış adresinin yönlendirme ve oturum gerektirmediğini test edin.

Test ve izleme

Başlıkları yazmak yetmez; ileti alıcıya ulaştığında doğru görünmeleri gerekir. Bir gönderim sağlayıcısı üzerinden yolladığınız iletide başlıklar sağlayıcı tarafından değiştirilmiş, yeniden sıralanmış ya da imzaya katılmamış olabilir. Bu yüzden testi gönderdiğiniz ileti üzerinde değil, alıcıya ulaşan ileti üzerinde yapın.

Örnek senaryo: haftalık teknoloji özeti bülteni

Örnek senaryo: haftalık teknoloji özeti gönderen bir yayıncı, bülten aracında tek tıkla çıkışı açıyor ve test iletisini kendi posta kutusuna gönderiyor. İletinin ham başlıklarında List-Unsubscribe alanında bir HTTPS adresi görüyor, ama List-Unsubscribe-Post alanı yok. Aracın belgesinde bu özelliğin ayrı bir ayarla açıldığını fark edip ayarı etkinleştiriyor ve testi yineliyor. Bu kez iki alan da var; DKIM imzasının h= listesinde List-Unsubscribe-Post eksik olduğunu görünce gönderim sağlayıcısının imzalanacak başlık listesini genişletiyor. Son testte iki alan da imzalı ve düğme alıcı arayüzünde çıkıyor.

Test kontrol listesi

• İletide tek bir List-Unsubscribe ve tek bir List-Unsubscribe-Post alanı var.
• List-Unsubscribe-Post değeri yalnızca List-Unsubscribe=One-Click.
• List-Unsubscribe alanında bir HTTPS adresi bulunuyor, açılı parantezler doğru.
• Her iki başlık da DKIM imzasının h= listesinde.
• HTTPS adresi yönlendirme yapmıyor.
• Çerezsiz bir POST isteği abonelik kaydını kapatıyor.
• Gövdedeki görünür bağlantı aynı kaydı kapatıyor.
• Çıkış sonrasında aynı adrese pazarlama iletisi gitmiyor.

İzlemede neye bakılır

Çıkış taleplerinin işlenmesi bir kez kurulup unutulacak bir iş değildir. Gönderim sağlayıcısını, bülten aracını ya da ileti şablonunu değiştirdiğinizde başlık testini yineleyin. Çıkış isteklerinin sunucu günlüklerinde başarısız yanıt (4xx ve 5xx) üretip üretmediğine bakın; başarısız bir POST, alıcının "çıkış yapıldı" sandığı ama kaydın hâlâ açık kaldığı anlamına gelebilir. Bu, aboneye gereksiz ileti göndermenin bir yoludur ve bülten itibarı açısından zararlıdır.

Abonelik izninin alınması ve iptallerin kaydı ayrı bir konudur; izin tarafını ticari elektronik ileti izni ve KVKK yazısında bulabilirsiniz.

İzlemede ek tablolar

Sponsor ya da iş ortağı e-postalarını kendi listenizden gönderiyorsanız, onların çıkış bağlantısının sizin listenizin çıkışına bağlanması gerekir; sponsorlu bir ileti için bildirimin nasıl yapılacağına sponsorlu içerik etiketleme yazısı bakabilirsiniz. Medya kitiniz iletişim bilgisi veriyorsa, o adrese yazanların yanıtının abonelikten çıkma talebine dönüşmesi durumunda bu talebin de işleneceğinden emin olun; bu konuda medya kiti hazırlama rehberi iletişim bölümü için bir başlangıç sağlar.

Çıkış başlığıyla ilgili yaygın hatalar

Aşağıdaki hataların hepsi RFC 8058'deki veya Gmail yönergesindeki bir kuraldan ya da uyarıdan çıkar. Hiçbiri belirli bir sonucu garanti ettiği anlamına gelmez; ama her biri alıcı sistemde çıkış düğmesinin görünmemesine ya da çalışmamasına neden olabilir.

Başlık hataları

• Aynı iletide birden çok List-Unsubscribe alanı yazmak. RFC 2369'a göre ileti başına en çok bir tane olmalıdır.
• Açılı parantez dışına adres yazmak ya da parantezin içine boşluk koymak.
• List-Unsubscribe-Post değerine ek anahtarlar eklemek.
• Tek tıkla çıkış için HTTP adresi kullanmak; RFC 8058 bir HTTPS adresi ister.
• Başlıkları DKIM imzasının dışında bırakmak.

Uç nokta hataları

• Çıkış adresinin başka bir adrese yönlendirmesi; RFC 8058 yönlendirme döndürülmemesini şart koşar.
• POST isteğinde çerez ya da yetkilendirme beklemek.
• Adreste tahmin edilebilir bir sayı ya da düz e-posta adresi taşımak ve sunucuda doğrulamamak.
• Çıkışı yalnızca GET ile mümkün kılmak; tek tıkla çıkış için POST gerekir.

Süreç hataları

• Başlıkları test etmeden gönderim sağlayıcısını değiştirmek.
• Gövdedeki görünür bağlantıyı kaldırıp yalnızca başlığa güvenmek; Gmail yönergesi ikisini birlikte ister.
• Çıkış kayıtlarını ayrı bir listede tutup ana gönderim listesine yansıtmamak.

Hazır hizmet mi, kendi kod mu

Başlığı kimin ürettiği, işin nerede bittiğini belirler. İki yol arasındaki fark, sorumluluğun kimde olduğudur; kuralların kendisi değişmez.

Bülten hizmeti kullanıyorsanız

Bir bülten ya da e-posta kampanyası hizmeti kullanıyorsanız başlıkların üretilmesi, çıkış adresinin barındırılması ve kaydın kapatılması hizmete bağlı olarak hizmetin işi olabilir. Sizin işiniz, hizmetin ayarında tek tıkla çıkış seçeneğini bulmak, gönderim alan adınızın DKIM imzasının hizmet tarafından atıldığını doğrulamak ve test iletisinin ham başlıklarını incelemektir. Hizmetin belgesinde tek tıkla çıkış hakkında bir ifade yoksa, bunu varsaymayın; destek kanalından yazılı olarak sorun. RFC ve Gmail sayfası belirli bir hizmetin ne yaptığını anlatmaz.

Kendi kodunuzla gönderiyorsanız

Kendi sunucunuzdan gönderim yapıyorsanız uç noktayı siz yazarsınız. Uygulama önerisi olarak sunucu tarafında şu davranışları kurun. Adresteki belirteçten aboneyi bulun ve belirteç geçersizse hata yanıtı verin. POST isteğini aldığınızda aboneliği kapatın ve başarılı bir yanıt dönün. Aynı belirteçle ikinci bir POST geldiğinde de hata değil, başarılı yanıt verin; çünkü alıcı sistem isteği yinelemiş olabilir ve kayıt zaten kapalıdır. Yanıt gövdesinde abonenin adresini göstermeyin. Yönlendirme yapmayın ve çerez beklemeyin. Bu davranışların yönlendirme ile çerez dışındakileri RFC'den değil, genel uygulama deneyiminden gelen önerilerdir.

Hangi yol size uygun

Çıkıştan sonra kayıt ve bastırma

Teknik akış, abonelik kaydı kapatıldığında biter ama uygulamada asıl iş kaydın gönderim sistemine yansımasıdır. Çıkış yapan bir kişinin bir sonraki kampanyada yeniden listede çıkması, hem alıcı hem de itibarınız için zararlıdır.

Çıkış listesini tek kaynaktan yönetin

Uygulama önerisi: abonelikten çıkan adresleri bir bastırma listesinde toplayın ve tüm gönderim akışları gönderimden önce bu listeye baksın. Bülten, kampanya ve yeniden ilgi çekme iletileri gibi birden çok akış varsa, her birinin ayrı bir liste kullanmaması gerekir. Hangi iletilerin çıkıştan etkilendiği, işin niteliğine ve yürürlükteki kurallara bağlıdır; bu bir hukuki değerlendirme meselesidir ve burada yargıya varılmaz.

Çıkış taleplerini sayın

Çıkış sayısını ölçmek, bültenin sağlığı hakkında bilgi verir. Hangi bültenden, hangi kampanyadan sonra çıkışların arttığını görmek içerik ve sıklık kararlarına yol gösterebilir. Bunun için kampanya etiketleme düzeni kurmak istiyorsanız UTM ve Search Console ile raporlama yazısındaki etiketleme mantığı bir başlangıç olabilir. Çıkış bağlantısına etiket eklerken, adresin RFC 8058 kuralları uyarınca yönlendirmesiz kalması gerektiğini unutmayın; etiket sorgu parametresi olarak eklenebilir, yönlendirme olarak değil.

Gmail dışındaki alıcılar

Gmail'in gönderici yönergeleri ve RFC'ler, diğer posta hizmetlerinin bu başlıkları nasıl gösterdiğini ya da hangi koşullarla tek tıkla çıkış düğmesi sunduğunu anlatmaz; bunun için ilgili hizmetlerin güncel belgelerine bakın. RFC 8058, alıcı sistemin tek tıkla çıkış önermesi için iletide geçerli DKIM imzası bulunmasını öngördüğünden, imzayı doğru kurmak her alıcı için ortak ön koşuldur.

Çıkış deneyimini kısa tutun

Görünür bağlantıya tıklayan okur, çıkışı tamamlamak için kısa bir onay sayfasında tek eylem yapmalıdır. Uzun anketler, giriş zorunluluğu ya da birden çok adım bu kısalığı bozar. Anket isteyecekseniz, çıkış tamamlandıktan sonra isteğe bağlı bir adım olarak sunun. Bu bir öneridir; Gmail yönergesi anket konusunda bir ifade içermez, ama hedefi çıkışı kolaylaştırmaktır.

Baştan sona kurulum sırası

Parçaları tek tek anlamak kolaydır; zor olan, doğru sırayla kurmaktır. Aşağıdaki sıra, bir sonraki adımın ancak önceki adım doğrulandığında başlamasını öngörür.

Altı adımlı sıra

1. DKIM imzasının alan adınız için çalıştığını doğrulayın. Başlıkları imzalamak, imzanın var olmasına bağlıdır.
2. Çıkış uç noktasını kurun: HTTPS, yönlendirmesiz, çerezsiz, belirteçli.
3. Uç noktayı elle iki kez çağırarak aynı belirteçle ikinci çağrıda da başarılı yanıt aldığınızı doğrulayın.
4. List-Unsubscribe alanına HTTPS adresini, istiyorsanız sağına mailto adresini ekleyin; List-Unsubscribe-Post alanını yalnızca List-Unsubscribe=One-Click değeriyle ekleyin.
5. İmzalanan başlık listesine iki başlığı da ekleyin.
6. Test iletisi gönderin, ham başlıkları, imza listesini ve alıcı arayüzünü kontrol edin.

Örnek senaryo: online kurs bülteni

Örnek senaryo: bir online kurs yayıncısı bülten aracını değiştiriyor. Eski araç başlıkları kendiliğinden ekliyordu; yeni araçta bu ayar varsayılan olarak kapalı. Yayıncı geçişten önce test iletisinin ham başlıklarına bakıyor, List-Unsubscribe alanı yok. Aracın belgesinde ilgili ayarı bulup açıyor ve test iletisini yeniden gönderiyor. Bu kez List-Unsubscribe var, ama List-Unsubscribe-Post yok; destek kanalına yazıp özelliğin ayrı bir eklentiyle sunulduğunu öğreniyor. Yayıncı, geçişi tek tıkla çıkış hazır olana kadar erteliyor; çünkü eski araçta çalışan davranışın yeni araçta kaybolması, gönderici yönergelerine uyumu da bozabilir.

Hangi aşamada neyi kaydetmeli

Her aşamada bir not tutun: hangi başlık değeri yazıldı, imza listesi neydi, test iletisi hangi adrese gitti ve çıkış kaydı gerçekten kapandı mı. Bu notlar, sağlayıcı değiştirdiğinizde ya da bir hata ortaya çıktığında ilk bakılacak yerdir. Başlık değişikliği küçük görünür, ama bir yazım hatası alıcı arayüzünde düğmenin görünmemesine yol açabilir; bu da fark edilmeden günlerce sürebilir.

Kısa terimler tablosu

Tabloda ilk üç satır RFC 8058 ve Gmail yönergesindeki tanımlardan, son iki satır ise uygulama dilinden gelir. Bu ayrımı akılda tutmak, hangi kuralın zorunlu, hangisinin önerilen olduğunu birbirinden ayırmanıza yardım eder.

Sık Sorulan Sorular

List-Unsubscribe nedir?

List-Unsubscribe, e-postanın başlık kısmındaki bir alandır ve alıcı sisteme aboneliğin hangi adres ya da e-posta komutuyla sonlandırılacağını söyler. Değer, açılı parantez içindeki mailto veya http adreslerinden oluşur ve birden çok adres virgülle ayrılır. RFC 2369'a göre bir iletide her alandan en çok bir tane bulunabilir.

List-Unsubscribe-Post ne işe yarar?

List-Unsubscribe-Post alanı, alıcı sisteme çıkış adresine tek bir HTTPS POST isteği göndermesini bildirir. Alanın değeri yalnızca List-Unsubscribe=One-Click olmalıdır. RFC 8058'e göre bu alanla birlikte List-Unsubscribe alanında bir HTTPS adresi bulunmalı ve iki başlık da DKIM imzasıyla kapsanmalıdır.

Gövdedeki abonelikten çıkma bağlantısını kaldırıp yalnızca başlık kullanabilir miyim?

Gmail gönderici yönergeleri hem tek tıkla çıkışı destekleyen başlıkları hem de ileti gövdesinde açıkça görünür bir çıkış bağlantısını ister. Bu nedenle başlık, görünür bağlantının yerine geçmez. İkisinin aynı abonelik kaydını kapatması gerekir.

Çıkış adresi yönlendirme yapabilir mi?

Hayır. RFC 8058, 3.1 bölümü göndericinin HTTPS yönlendirmesi döndürmemesini şart koşar; çünkü yönlendirilen POST isteklerinin sıklıkla GET'e dönüştürüldüğü görülmüştür. Adres, POST isteğini çerez ya da yetkilendirme olmadan doğrudan karşılamalıdır.

Bu konuda hukuki bir yükümlülük var mı?

Bu soru yasal bir değerlendirme gerektirir ve hukuki tavsiye değildir; yazıdaki içerik yalnızca başlık alanlarının ve Gmail yönergelerinin teknik tanımıdır. İzin ve iptal yükümlülükleri için ilgili mevzuata ve bir uzmana başvurun; gönderici yönergeleri ise ayrı bir platform kuralıdır ve yasal bir hüküm yerine geçmez.

Başlıkların doğru çalıştığını nasıl anlarım?

Gönderdiğiniz bir test iletisinin alıcıya ulaşan ham başlıklarını inceleyin. Tek bir List-Unsubscribe ve tek bir List-Unsubscribe-Post alanı, bir HTTPS adresi ve DKIM imzasının h= listesinde iki başlığın bulunduğunu doğrulayın. Ardından çerezsiz bir POST isteğiyle adresi sınayın ve gövdedeki bağlantıyla aynı kaydın kapandığını görün.

Sonuç

Çıkış başlığını doğru kurmak üç şeye bağlıdır: başlık sözdiziminin RFC 2369 ve RFC 8058'e uyması, HTTPS uç noktasının yönlendirmesiz ve çerezsiz çalışması ve gövdedeki görünür bağlantıyla aynı kaydı kapatması. Başlık eklemek yeterli değildir; alıcıya ulaşan iletide DKIM imzasının iki başlığı da kapsadığını test etmek gerekir. Gönderici yönergeleri değişebilir; uygulamadan önce Gmail sayfasının güncel halini kontrol edin. Bu yazı hukuki tavsiye değildir.

Bülteninizi ve içeriklerinizi daha geniş bir okur kitlesine ulaştırmak istiyorsanız Akua Adforce'ta tanıtım yazısı ilanlarını inceleyebilirsiniz; kapsam ve koşullar ürün sayfasında yazılıdır.