Çok kiracılı platformlar için gelen e-posta çözümleme webhook'larını yapılandırma

Gelen e-posta çözümleme, ham SMTP akışını API uç noktanıza iletilen yapılandırılmış JSON verisine dönüştürür. İmza doğrulaması yapılmayan webhook çağrıları, sahte isteklerin sisteme sızmasına neden olan yaygın bir güvenlik açığıdır. Doğru yaklaşım, hassas MX yönlendirmesi kurmak ve gelen her paketi HMAC-SHA256 başlıklarıyla doğrulamaktır.

Gelen e-posta işlemenin mimari genel bakışı

Gelen e-posta çözümleme, ham SMTP akışlarını çok kiracılı iletişim merkeziniz için yapılandırılmış webhook yüklerine dönüştürür. Bir alt kiracı alıcısı bir mesaja yanıt verdiğinde, MX kayıtları SMTP oturumunu kenar alım sunucularına yönlendirir. Çözümleme hattı başlıkları, çok parçalı MIME gövdelerini ve ham ekleri çıkararak bunları JSON nesnelerine normalleştirir. Olayları yönlendirmeden önce platform, SPF ve DKIM gibi alan adı kimlik doğrulama kayıtlarını doğrular.

DNS kayıtlarını ve MX yönlendirmesini yapılandırma

Gelen postaları güvenli bir şekilde yönlendirmek, yönetilen her gönderim alan adı için hassas DNS yapılandırması gerektirir. Alt kiracılar, platform alım uç noktalarına işaret eden MX kayıtlarının yanı sıra alan adı mülkiyet kanıtları için standart CNAME doğrulayıcıları sağlamalıdır. Alan adlarını eklerken sistem, canlı trafik alımını etkinleştirmeden önce DNS yayılımını doğrulamak için otomatik doğrulama rutinlerini tetikler. TLS şifrelemesi zorunludur.

Webhook yük tasarımı ve güvenlik doğrulaması

Webhook teslimatının güvenilirliği, belirleyici yük yapılarına ve güçlü uç nokta kimlik doğrulama mekanizmalarına bağlıdır. Her giden webhook, alıcı alt kireciye özel gizli bir anahtar kullanılarak hesaplanan bir HMAC-SHA256 imzası taşır. Alım sunucularınız, sahte istek saldırılarını önlemek için JSON gövdesini işlemeden önce bu imzayı doğrulamalıdır. Yük şeması, gönderen gibi ayrıştırılmış alanları içerir.

Oran sınırlarını ve geri basıncı yönetme

Oran sınırları ve geri basınç mekanizmaları eksikse, yüksek hacimli gelen kampanyalar abone uç noktalarını aşırı yükleyebilir. Platform, sunucu kaynaklarını beklenmedik trafik sellerinden korumak için kiracı başına alım sınırları uygular. Trafik normal eşiklerin üzerine çıktığında sistem, tüketim oranlarını düzeltmek için kontrollü geri basınç uygulayarak kalıcı arabelleklerde kuyruğa alır.

Operasyonel sorun giderme ve gerekli kaynaklar

Webhook teslimat hatalarını teşhis etmek, yapılandırılmış günlük denetimi ve uç nokta kullanılabilirliğinin kesin doğrulamasını gerektirir. Operatörler, başarısız olan olayları yeniden oynatmak, yanıt kodlarını incelemek ve biçimlendirme hataları için ham yükleri gözden geçirmek üzere geliştirici konsolunu kullanır. Operasyonel kurulumunuzu derinleştirmek ve uyumluluğu korumak için temel belgeleri inceleyin.

İlgili yazılar: E-posta pilot haftası: gerçek alıcılardan önce canlı kimlik doğrulama kontrol… · API Pilot Haftası: Canlı Trafikte Anahtarlar ve Webhooklar · pilotten üretime API hız sınırları.

IOSOR ile başlayın

MX’i parse sunucusuna yönlendirin ve kiracı başına paylaşılan sır ile inbound webhook URL oluşturun. 2xx dönmeden önce payload’ı kalıcılaştırın. message-id ile yeniden oynatın ki webhook yeniden denemesi ikinci bilet açmasın. Bir inbound iletinin ledger’da o kiracının kuyruğuna ulaştığını kanıtlayın.

IOSOR özeti

Düşmüş payload ile HTTP 200 sessiz bir başarısızlıktır. Yazıktan sonra ACK, önce değil.

Yapın: önce kalıcılaştırın, sonra 2xx; 5xx’te webhook’u yeniden deneyin. Yapmayın: ayrıştırıcı hâlâ tamponlarken 200’de ACK vermeyin, kiracılar arasında tek webhook sırrı paylaşmayın.