Şanssızlık eseri, Genel Ağ posta protokolleri ile ilgili çeşitlemeler, yaratıcı yorumlar ve açıkça ihlaller ortaya çıkar; bazıları bunların o kadar sık görülmediğini söyler. İyi bir SMTP alıcısı veya rölesi, bozuk bir iletiyi red mi etmeli, hiçbir değişiklik yapmadan geçirmeye mi çalışmalı yoksa başarılı bir teslimat veya yanıt şansını arttırmak için onarmaya mı çalışmalı tartışmaları yapısal ağ postasının ortaya çıkışı ile başladı ve bitecek gibi de görünmemektedir. Red yanlıları onarmaya çalışmanın herzaman yeterli olmadığını ve hatalı iletilerin reddedilmesinin yazılımın tamirinde tek çözüm olduğunu iddia ederler. "Tamir et" veya "ne olursa olsun teslim et" yanlıları ise kullanıcıların postanın eğer olabilirse iletilmesi gerektiğini düşündüklerini ve bu yönde önemli piyasa baskısı olduğunu söyleyip karşı çıkarlar. Uygulamada, bu piyasa baskıları belirli satıcılar için asıl geliştiricilerin tercihlerine bakmaksızın, standartlara kesinlikle uymaya çalışmaktan daha önemli olabilir.
Hatalı biçimlenmiş iletilerle ilgili sorunlar ayrık posta okuma protokollerinin [
3,
26,
5,
21] ortaya çıkışı ile iyice arttı. Bu protokoller SMTP'yi postalama protokolü olarak ve SMTP sunucularını da bu istemci konaklar (sıkça ama aralıklarla Genel Ağ'a bağlanan konaklar) için röleleme sistemleri olarak kullanmayı teşvik etti. Geçmişe baktığımızda, bu istemci makinelerin çoğunun SMTP tarafından varsayılan bazı bilgilere ve mekanizmalara (ve tabii, posta biçimleme protokolüne [
7]) ihtiyaç duyduklarını görürüz. Bazıları zamanı yeterince takip edemedi; bazıları zaman dilimleri kavramından habersizdi; bazıları hala isim ve adreslerini tanımlayamıyor; ve, tabii ki hiçbiri RFC 822'nin kimlik kanıtlamalı adresler kavramının dayandığı öngereklilikleri sağlayamadı.
Bu zayıf SMTP istemcilerine yanıt olarak, artık bir çok SMTP sistemi kendilerine eksik veya yanlış biçimlenmiş olarak teslim edilen iletileri tamamlamaktalar. Bu strateji, sunucu istemciyi tanıdığında veya kimliğini kanıtlamasını istediğinde ve aralarında ön anlaşmalar olduğunda genellikle doğru sayılır. Karşıt olarak, en büyük endişe, kullanıcı veya istemci makinesi hakkında çok az bilgisi olan veya hiç bilgisi olmayan bir röle veya teslimat SMTP sunucusu tarafından uygulanan düzeltmelerle ilgilidir.
Aşağıdaki değişiklikler işlenmekte olan bir iletiye, gerek oluşturucu gerekse SMTP'nin ilk postalama protokolü hedefi olarak kullanıldığı SMTP sunucusu tarafından uygulanabilir *SEÇİMLİK*.
- message-id alanının yokluğu halinde eklenmesi
-
tarih, saat ve zaman dilimi bilgilerinin yokluğu halinde eklenmesi
-
adreslerin doğru FQDN biçimine getirilmesi
Sunucunun istemci hakkında ne kadar az bilgisi olursa, bu değişiklikler o kadar az doğru olur ve düzeltmelerin yapılıp yapılmaması veya nasıl yapılması gerektiği ele alınırken daha fazla dikkat ve tutarlılık gösterilmesi gerekir. Bu değişiklikler ara röleleme işlemi yapan SMTP sunucuları tarafından uygulanmamalıdır *ZORUNLU*.
Her durumda, doğru bilgi sağlayarak düzgün işleyen istemciler, SMTP sunucuları tarafından düzeltmeler bakımından tercih edilirler. Tüm durumlarda, sunucular tarafından yapılan hareketlerin mutlaka belgelenmesi (izleme alanları ve/veya başlık yorumlarında) önerilir.