[ Başlıklar ve teslimat hataları ]

List-Unsubscribe ve List-Unsubscribe-Post başlıkları

Liste yönetimi bağlantısını imzalı tek tıklamayla abonelikten çıkma mekanizmasından ayırın ve gerçek alıcıların aboneliğini iptal etmeden test edin.

EmailAuth araştırma ekibi tarafından · 3 dakikalık okuma

[ Anahtar noktalar ]

  • Liste yönetimi bağlantısını imzalı tek tıklamayla abonelikten çıkma mekanizmasından ayırın ve gerçek alıcıların aboneliğini iptal etmeden test edin.
  • Başlık sözdizimi, geçerli bir kapsayan imza ve yetkili uç nokta davranışı üç ayrı bulgudur; hiçbiri diğerinin yerini tutmaz.
Bu sayfada

İleti gövdesinde bir abonelikten çıkma bağlantısı, List-Unsubscribe başlık ve tek tıklama mekanizması birbiriyle ilişkili ancak farklı özelliklerdir. Tanılama, gönderenin gerçekte hangi mekanizmayı yaydığını ve gerekli imzalı başlıkların mevcut olup olmadığını belirlemelidir. Yalnızca kaynakta aboneliği iptal etme kelimesinin görülmesi, tek tıklamayla çalışan bir uygulama oluşturmaz.

İki alanı birlikte okuyun

RFC 2369 List-Unsubscribe listeden ayrılmak için URL'leri içeren bir liste komut alanı olarak tanımlar. Mailto veya HTTPS gibi yöntemleri tanımlayabilir. RFC 8058 tek tıklama mekanizması için List-Unsubscribe-Post ekler. İkincisi, List-Unsubscribe =Tek Tıklama değerini, List-Unsubscribe bir HTTPS URI'si ile kullanır. Mailto seçeneği tek başına RFC 8058 HTTPS mekanizması değildir. RFC 2369 bölüm 3.2, RFC 8058 bölüm 3.

Tek tıklamayla alıcı, belirtilen abonelikten çıkma değerini içeren bir HTTPS POST gönderir. Bir URL'yi denetlemeye yönelik rutin bir GET, RFC 8058 abonelikten çıkma eylemini kendisi gerçekleştirmemelidir. Bu ayrım önemlidir çünkü bağlantı tarayıcıları, bir kişinin listeden ayrılmaya niyeti olmadan URL'leri getirebilir. Tanılama incelemesini yetkisiz bir abonelik değişikliğine dönüştürmeyin.

İmza gereksinimini kontrol edin

RFC 8058 geçerli bir DKIM imzası Hem List-Unsubscribe hem de List-Unsubscribe-Post kapsar. Bir imzanın h= listesinde iki alan adını bulmak yararlı bir yapısal kontroldür ancak imzanın doğrulandığını kanıtlamaz.

Gerçek bir doğrulama için orijinal imzalı mesajı saklayın. Çoklu imzalar ve yinelenen başlık alanları dikkatli seçim gerektirir; saf bir alt dize araması, ilgisiz bir imzayı gereksinimi karşılayan bir imzayla karıştırabilir. İmza kapsamını, kriptografik doğrulamayı ve uç nokta davranışını ayrı kontroller olarak tutun.

Kontrollü bir örnek kullanın

Doğru iki başlık değerine sahip varsayımsal bir mesaj düşünün. Geçerli olan tek imza Kimden ve Konuyu kapsar ancak abonelikten çıkma alanlarını kapsamaz. İkinci imza her iki alanı da listeliyor ancak doğrulama başarısız oluyor. Bu mesajda hem DKIM kaynağında bir yerde geçiş ve görünür kapsama alanı vardır, ancak her iki imza da birleşik RFC 8058 gerekliliğini karşılamamaktadır.

Bir sonraki adım, onaylanmış bir gönderen değişikliği aracılığıyla, iki alanı hem doğrulayan hem de kapsayan bir imzayı tanımlamak veya oluşturmaktır. Bu öğretim örneği için hiçbir imza doğrulanmadı veya abonelik değiştirilmedi. Daha sonra doğrulanan bir kapsam imzası bile HTTPS uç nokta davranışını ve sonraki gönderim engellemeyi test edilmemiş halde bırakacaktır.

Yetkili bir uçtan uca test için özel bir test aboneliği ve gönderenin desteklediği test ortamını kullanın. Geçerli bir imzayı doğrulayın, amaçlanan POST'u gönderin ve hizmetin kendi kanıtı aracılığıyla test aboneliğinin durumunu onaylayın. RFC 8058 HTTPS yönlendirmelerini yasaklar ve çerezleri, HTTP yetkilendirmesini ve diğer istek içeriğini POST'tan hariç tutar. Alıcı, göndermeden önce kullanıcının onayını almalıdır. Herhangi bir yönlendirme veya oturum açma gereksinimini tıklamak yerine kusur olarak kaydedin; uç noktanın aboneliği iptal etme işlemini ek etkileşim olmadan tamamlaması gerekir.

Abone tanımlayıcılarını koruyun

Abonelikten çıkma URL'leri genellikle alıcıya özel bir belirteç içerir. Tam URL'yi, söz konusu kişinin aboneliğini değiştirme potansiyeline sahip olarak değerlendirin. Genel teşhis kopyasındaki belirteci çıkarın veya değiştirin, dokunulmamış mesajı özel olarak koruyun ve canlı URL'yi genel destek taleplerine veya otomatik getiricilere yapıştırmayın.

Açık bir kontrol listesiyle kapatın: alanlar mevcut, doğru sözdizimi, imzayı kapsayan doğrulandı ve yetkili uç nokta testi tamamlandı veya yapılmadı. Sağlayıcının toplu gönderen uygunluğu ve abonelikten çıkma arayüzü ekranı ayrı ürün sorularıdır. Standart düzeydeki başlık denetimi, herhangi bir posta kutusu sağlayıcısının belirli bir düğmeyi görüntüleyeceğini garanti etmez.

Her katmanı bağımsız olarak raporlayın

Başlıklar mevcut ancak imza doğrulaması mevcut değilse, yalnızca yapısal bir bulguyu bildirin. Doğrulama başarılı olursa ancak yetkili uç nokta testi gerçekleşmediyse davranışı test edilmeden bırakın. Tam nihai numuneyi ve bir sonraki katman için gereken kanıtları kaydedin.

[ Götürmek ]

Liste yönetimi bağlantısını imzalı tek tıklamayla abonelikten çıkma mekanizmasından ayırın ve gerçek alıcıların aboneliğini iptal etmeden test edin.

[ Role göre ]

Bu sizin için ne anlama geliyor?

Sonraki pratik adımlar için rolünüzü seçin.

BT / Posta Yöneticisi

Her katmanı ayrı ayrı doğrulayın

Başlık sözdizimi yalnızca ilk kontroldür.

Sonraki adımlar

  1. Her iki imzalı alanı da doğrulayın.
  2. Kaplama imzasını tanımlayın.
  3. POST davranışını yetkilendirmeyle test edin.

CISO / SecOps

Yanlışlıkla abonelik işlemlerini önleyin

Eylem URL'leri gelişigüzel getirilmemeli veya paylaşılmamalıdır.

Sonraki adımlar

  1. Alıcı belirteçlerini koruyun.
  2. Kontrollü test hesaplarını kullanın.
  3. Uç nokta test kapsamını kaydedin.

Kurucu / Teknik Olmayan

Listeden ayrılmayı güvenilir hale getirin

Görünür bir bağlantı ve kimliği doğrulanmış tek tıklamalı akış, farklı kullanıcı yollarına hizmet eder.

Sonraki adımlar

  1. Abonelikten çıkma sahibi atayın.
  2. Test aboneliklerini kullanın.
  3. Desteklenmeyen arayüz vaatlerinden kaçının.

[ SSS ]

Sık sorulan sorular

Gövde bağlantısı tek tıklamalı başlıklarla aynı mıdır?

Hayır. Bunlar ayrı mekanizmalardır ve ayrı ayrı değerlendirilmeleri gerekir.

RFC 8058 için mailto tek başına yeterli midir?

Hayır. Tek tıklama mekanizması bir HTTPS URI'si gerektirir.

List-Unsubscribe-Post hangi değer aittir?

List-Unsubscribe=One-Click.

Abonelikten çıkma başlıklarının her ikisinin de imzalanması gerekir mi?

Evet. RFC 8058 her ikisini de kapsayan geçerli bir DKIM imzası gerektirir.

h= kapsamı tek başına uygunluğu kanıtlar mı?

Hayır. İmza geçerliliği ve uç nokta davranışı da önemlidir.

URL'yi açmak birinin aboneliğini iptal etmeli mi?

GET, RFC 8058 abonelikten çıkma POST'u değildir. Denetim sırasında gerçek değişiklikleri tetiklemeyin.

Abonelikten çıkma işlemi gerçekten yürütüldü mü?

Hayır. Bu makale, yürütülen bir abonelikten çıkma işlemi değil, varsayımsal bir imza seçimi örneği ve yetkili bir test planı sağlar.

Abonelikten çıkma URL'sinin tamamı hassas olabilir mi?

Evet. Alıcıya özel bir eylem belirteci içerebilir ve buna göre ele alınmalıdır.

[ Kaynaklar ]

Kaynaklar

  1. RFC 2369 : Posta Listesi Komut Alanları

    Bölümler §3.2

  2. RFC 8058 : Tek Tıklamayla Abonelikten Çıkma

    Bölümler §3.1 · §3.2 · §4 · §5 · §6

  3. RFC 6376 : DKIM İmzaları

    Bölümler §3.5 · §5.4 · §6.1

[ Sözlük ]

Sözlük

Tek tıklamayla abonelikten çıkma
HTTPS POST aracılığıyla abonelikten çıkma isteğinde bulunan RFC 8058 imzalı başlık mekanizması.
Başlık imzalama kapsamı
DKIM imzasının h= listesine dahil edilen başlık alanları.
Eylem jetonu
Belirli bir değişikliğe izin verebilecek bir URL veya istekteki değer.

Kurumsal menşe

Neden en iyi finans kurumları ve hükümetler e-posta güvenlik kontrol panellerini kullanımdan kaldırdı.

Geleneksel e-posta kimlik doğrulama platformları size bir gösterge tablosu satar ve mühendislerinizden bu işi yapmalarını ister. Riskli ortamlarda, manuel gözetim, gecikmeli uygulama, konfigürasyon kayması ve izlenmeyen gölge alanlar anlamına gelir.

EmailAuth aracılı e-posta kaynak platformudur. Temsilcilerimiz uyguluyor p=reject, üçüncü taraf gönderenleri uyumlu tutun ve alan adlarınızı tam sürüme taşıyın RFC 9989 döngüdeki insan tarafından denetlenebilirliğe sahip yeni DMARC standardı uyumluluğu.

Hükümetler Büyük işletmeler 1. Seviye finans kurumları

SaaS · Özel kiracılık · Şirket içi hava boşluklu · BYOK şifrelemesi

Bilgi Bankası