Alıcı sunucu tüm ileti kimlik doğrulamasını değerlendirmeden önce ileti boyutu reddi gerçekleşebilir. Ayrıca bir yukarı akış sunucusunun bir mesajı kabul etmesinden sonra da görünebilir ve daha sonraki bir atlama daha küçük bir sınır uygular. Her kalıcı reddi bir sorun olarak ele almak yerine, reddeden şerbetçiotundaki boyut durumunu teşhis edin. SPF, DKIM veya DMARC kusur.
Boyutu politika ve depolamadan ayırt etme
RFC 3463 X.3.4'ü alıcı sistem için çok büyük bir mesaj olarak, X.2.3'ü ise posta kutusu için yönetim sınırını aşan bir mesaj uzunluğu olarak tanımlar. Bunlar X.2.2 posta kutusunun dolu olmasından farklıdır. Ürünler kendi limitlerini, birimlerini ve açıklayıcı ifadelerini ekleyebileceği için teşhisin tamamını okuyun. Genel bir “552” etiketi tek başına tam olarak yapılandırılmış kısıtlamayı oluşturmaz. RFC 3463 bölümleri 3.3 ve 3.4.
Kimlik doğrulama başarısızlıkları, mesaj sekizli sayısından ziyade kimlikler, imzalar veya politikayla ilgilidir. Boyutun küçültülmesi bir DKIM onarımı değildir; İmzalı içeriğin değiştirilmesi imzayı geçersiz kılabilir, dolayısıyla yetkili bir değiştirmenin normal imzalama iş akışından geçmesi gerekir. Bunun tersine, SPF başka bir IP'ye yetki vermek, alıcının izin verilen mesaj boyutunu artırmaz. Bağımsız kanıtlar her ikisinin de başarısız olduğunu göstermediği sürece iki araştırmayı ayrı tutun.
Reklamı yapılan SIZE özelliğini doğru şekilde okuyun
SMTP SIZE uzantısı, bir sunucunun desteğinin ve isteğe bağlı olarak kendi alanında maksimum mesaj boyutunun reklamını yapmasına olanak tanır. EHLO cevap. Destekleyici bir müşteri, tahmini bir boyut sağlayabilir. POSTA, mesajın tamamını iletmeden önce reddetmeye izin verir. Sayı olmadan BOYUT, sabit maksimum bilgi taşımaz; SIZE 0 açıkça sabit bir maksimumun yürürlükte olmadığını gösterir. İkisi de kabulü garanti etmez. Daha sonraki işlemler ve diğer şerbetçiotu hala kısıtlamalar getirebilir. RFC 1870 bölüm 3 ve 4.
RFC 1870 BOYUTU için, CRLF satır sonları, başlıklar, MIME yapısı ve kodlanmış içerik dahil olmak üzere mesaj sekizlilerini sayın, ancak VERİ sonlandırma noktasını ve ekstra nokta doldurma baytlarını hariç tutun. Yalnızca ek dosyayı saymayın. Base64 kodlaması ikili verileri genişletir ve satır sonları ve çevresindeki mesaj parçaları daha fazla bayt ekler. Görmek RFC 2045 bölüm 6.8. Sağlayıcı arayüzleri yuvarlatılmış birimleri farklı şekilde görüntüleyebilir. Açıklanamayan iki "MB" etiketini karşılaştırmak yerine, ölçülen sekizlileri ve tam olarak bildirilen veya belgelenen limiti kaydedin.
Kontrollü varyantları karşılaştırın
Yalnızca boyutla ilgili içerik açısından farklılık gösteren iki yetkili varyant oluşturun. Her sonucun daha küçük ve daha büyük serileştirilmiş boyutlarını ve SMTP aşamasını koruyun. Açıklayıcı bir çift, aynı kısa açıklayıcı metni içerebilir; büyük bir ekin yerini onaylanmış erişim kontrollü bir dosya bağlantısı alabilir. Bir dosya bağlantısının gizli materyal için uygun olduğunu veya alıcının erişime sahip olduğunu varsaymayın.
RFC 5321 bölüm 4.5.3.1 .7, başlıklar dahil en az 64K sekizli mesaj boyutunun desteklenmesini gerektirir. Aşağıdaki 100.000 oktetlik sınır, bu protokol minimumunun üzerindedir ve önerilen bir sağlayıcı ayarı değildir.
Varsayımsal bir aritmetik kontrolü için, aynı uç noktanın BOYUT 100000 reklamı yaptığını varsayalım. 115.900 sekizli olduğu varsayılan bir mesaj, bu sınırı 15.900 sekizli aşıyor; varsayılan 20.100 oktetlik değişim bunun 79.900 oktet altındadır. İlki MAIL FROM adresinden reddedilebilir; ikincisi daha ileri işlemlere uygundur ancak kabul edilmesi garanti edilmez. Bu sayılar, ölçümler veya yürütülen SMTP sonuçları değil, icat edilmiştir. Herhangi bir sağlayıcının bağlantı tavanını tanımlamazlar.
İlgili en dar kısıtlamayı onarın
Reddetme sisteminin sahibine, boyutun kasıtlı bir hizmet sınırı mı yoksa organizasyon tarafından kontrol edilen bir ayar mı olduğunu sorun. İş ihtiyacı daha küçük bir dosyayla karşılanabiliyorsa tüm posta sistemi genelinde sınırları yükseltmek yerine bu yolu kullanın. Bir limit değişikliğine izin veriliyorsa, bunu uygulamadan önce kaynak tüketimini, kötü amaçlı yazılım taramasını ve aşağı yönde uyumluluğu göz önünde bulundurun.
Kalıcı olarak reddedilen aynı içeriği değiştirmeden tekrar denemeyin. Orijinalin başka bir durakta veya başka bir alıcı için kabul edilmediğini doğrulayın, ardından onaylanmış değiştirmeyi önceki girişimle açık bir ilişki kurarak gönderin. Kendi mesajını ve kuyruk tanımlayıcılarını koruyun. Yeni bir mesaj, kullanıcı bunu aynı ek olarak görse bile yeni bir teslimat olayıdır.
Ölçülen mesaj boyutu, belirlenen reddetme limiti ve düzeltilen girişimin sonucu ile kapatın. Bağlantılı içeriğe gelen kutusu yerleşimini ve alıcı erişimini ayrı kontroller olarak bırakın.
Sınırı geçici çözümden ayırın
- Ölçme: yalnızca eki değil, SIZE tanımını kullanarak seri hale getirilmiş iletinin tamamını sayın.
- Bul: reddeden atlama noktasını, komut aşamasını, teşhis ve geçerli limiti yakalayın.
- Onarım: Onaylanmış daha küçük bir mesaj veya erişim kontrollü dağıtım yöntemi seçin.
- Yeniden kontrol edin: değiştirme boyutunu ve alıcı başına sonucu kaydedin; her alt limitin eşleştiğini varsaymayın.
- Kapat: Alıcı erişimini SMTP kabulünden ayrı olarak onaylayın.