Azami ve/veya asgari boyutları olması gereken bazı nesneler vardır. Her gerçeklenimin nesneleri en azından bu boyutlarda almasının mümkün olması gerekir *ZORUNLU*. Bu boyutlardan daha büyük nesnelerden olabildiğince kaçınılmalıdır *ÖNERİ*. Bununla birlikte, kodlanmış X.400 adresleri [16] gibi sıklıkla daha geniş nesneler gerektiren bazı Genel Ağ posta oluşumları vardır: istemciler bunları aktarmaya çalışabilir *SEÇİMLİK*, fakat onları işleme alamıyacak bir sunucu tarafından reddedilmelerine karşı da hazırlıklı olmalıdır *ZORUNLU*. Azami genişleme olasılığı için, bu nesnelerin uzunluğu ile ilgili bir sınır koymayan gerçeklenim teknikleri kullanılmalıdır.

Bu sınırların aşılmasından dolayı oluşan hatalar yanıt kodları kullanılarak raporlanabilir. Bazı yanıt kodu örnekleri:

500 Satır çok uzun.

veya

501 Yol çok uzun

veya

452 Alıcılar çok fazla (aşağıya bakınız)

ya da

552 Posta verisi çok fazla.

RFC 821 [30] bir hatayı yanlış listelemiştir: RCPT komutlarının miktarıyla ilgili gerçeklenim sınırından dolayı yetersiz kalan bir SMTP sunucusunun hatayı ("Alıcılar çok fazla") '552 yanıt koduyla' bildireceği belirtilmiştir. Doğrusu '452 yanıt koduyla' olacaktır. İstemciler bu durumda bir 552 yanıt kodunu kalıcı değil geçici bir hata durumu olarak ele almalıdır *ÖNERİ*, başarısızlık durumunda aşağıdaki mantık yürütülür.

Belirtimle uyumlu bir SMTP sunucusu bu durumu saptadığında, alıcılar tamponunda en azından 100 başarılı RCPT komutu var demektir. Sunucu iletiyi kabul edebilecekse, en azından 100 adres SMTP istemcisinin kuyruğundan silinmiş olacaktır. 452 yanıtı almış adresleri istemci yeniden aktarmaya çalışırsa, bunların en azından 100 tanesi SMTP sunucusunun alıcılar tamponuna sığabilecektir. Teslim edilecek ne varsa yeniden her aktarma çabasında bu alıcıların en azından 100 tanesinden kurtulmak mümkün olacaktır.

Bir SMTP sunucusunun RCPT komutlarının sayısına bağlı bir gerçeklenim sınırı varsa ve bu sınıra ulaşılmışsa, sunucu 452 yanıt kodunu kullanmalıdır *ZORUNLU* (fakat, istemci yukarıda belirtildiği gibi bir 552 yanıtına karşı da hazırlıklı olmalıdır *ÖNERİ*). Eğer sunucu RCPT komutlarının sayısı ile ilgili kural olarak konmuş bir sınırlamaya (gerçeklenimin desteklediğinden az) göre hareket ediyorsa bir 5XX yanıt kodu da kullanabilir *SEÇİMLİK*. Eğer belli bir ileti gövdesi çok sayıda posta aktarımı ile gönderilmiş olsa bile o ileti için bir toplam alıcı sayısı sınırı uygulanabiliyorsa, böyle bir sınırlama en iyisi olurdu.

Her SMTP istemcisi bir zamanaşımı mekanizması sağlamalıdır *ZORUNLU*. Bu mekanizma posta aktarımının tamamına bir şekilde uygulanabilen bir zamanaşımı değil her komut için ayrı ayrı uygulanabilen zamanaşımları kullanmalıdır *ZORUNLU*. Zamanaşımları, tercihan SMTP kodunu yeniden derlemek gerekmeksizin, yeniden yapılandırılabilir olmalıdır *ÖNERİ*. Bunu gerçeklemek için, her SMTP komutu ve her veri aktarım tamponu için bir zamanlayıcı tahsis edilir. Sonuncusu, aktarımın bütününü kapsayan zamanaşımının ister istemez iletinin boyutuyla orantılı olduğu anlamına gelir.

Meşgul posta röleleme konakları ile gerçekleştirilen kapsamlı deneyimlere dayanarak, komut başına asgari zamanaşımı değerleri şöyle olmalıdır *ÖNERİ*:

Bir SMTP sunucusu göndericiden gelecek bir sonraki komutu en az 5 dakika beklemelidir *ÖNERİ*.

Bir SMTP istemcisinin genel modeli giden postayı aktarmaya çalışan bir veya daha fazla süreçten oluşur. Ortalama bir sistemde, bir iletiyi oluşturan program, hemen aktarılamayıp kuyruğa alınıp belirli aralıklarla tekrar gönderilmeye çalışılmalıyken *ZORUNLU*, giden postanın yeni bir parçasının hemen dikkate alınmasını talep eden bir yönteme sahiptir. Bir posta kuyruğu girdisi iletinin kendisinden başka zarf bilgisini de içerecektir.

Belli bir hedef için bir çaba başarısız olduktan sonra çabayı yinelemek için bir süre beklenmelidir *ZORUNLU*. Genelde, yineleme aralığı en azından 30 dakika olmalıdır *ÖNERİ*; bununla birlikte, SMTP istemcisi teslimat yapılmaması için sebep saptayabildiği zaman, daha karmaşık ve değişken stratejilerin yararı olacaktır.

İleti aktarılana veya gönderici vazgeçene kadar yineleme devam eder; vazgeçme süresinin genelde en azından 4-5 gün olması gerekir. Yineleme algoritmasının bağımsız değişkenleri yapılandırılabilir olmalıdır *ZORUNLU*.

Bir istemci kuyruklu posta öğelerini salt tekrar göndermeye çalışmaktan çok, ulaşamadığı konakların ve ilgili bağlantı zamanaşımlarının bir listesini tutması gerekir *ÖNERİ*.

Deneyimler bu başarısızlıkların genellikle geçici olduğunu (hedef sistem ya da bağlantı çökmüştür), kuyruktaki iletiyi göndermek için ilk saatte iki, daha sonra ise iki veya üç saatte bir bağlantı kurmaya çalışmak şeklinde bir kuralın lehte olacağını göstermiştir.

SMTP istemcisi, SMTP sunucusu ile anlaşarak kuyruklama gecikmesini kısaltabilir. Örneğin, posta belli bir adresten alınmışsa, posta onu hemen gönderebilecek konak için kuyruğa alınmış gibi ele alınabilir. Bu prensibin uygulaması, çoğu durumda, ETRN [9] gibi apaçık bir "kuyruktakileri hemen gönder" işlevi için gereksinimi ortadan kaldırabilir.

Strateji, çok sayıda adresin her konak başına özkaynak kullanımını (teslimat zamanı gibi) eniyileme gereğinin bir sonucu olarak böyle değiştirilmiş olabilir.

Bir SMTP istemcisinin erişilemeyen hedef konakların her biri için dev bir ileti kuyruğu olabilir. Bu iletilerin tümü her yineleme döngüsünde yineleniyorsa, Genel Ağ'a haddinden fazla yük bindirebilir ve gönderen sistem uzun bir süre boyunca engellenebilir. Bir SMTP istemcisinin, bir teslimat çabasının başarısız olacağını, aynı konak için kuyruklanmış iletilerin düzinelerce hatta yüzlercesinin tekrar tekrar yinelenmesi halinde bağlantı başına bırakın bir kaç dakikalık sadece tek bir dakikalık zamanaşımının bile çok büyük bir gecikmeyle sonuçlanacağını saptayabileceğine dikkat ediniz.

Aynı zamanda, SMTP istemcileri sunuculardan gelen olumsuz yanıtları arabelleğe alırken büyük dikkat sarfetmelidir *ÖNERİ*. Çok uç bir durumda, aynı SMTP bağlantısı sırasında EHLO komutu defalarca kullanılmışsa, sunucudan farklı yanıtlar dönebilir. Daha manidar olarak, MAIL komutuna verilen 5yz yanıtları arabelleğe alınmamalıdır *ZORUNLU*.

Bir posta iletisi çok sayıda alıcıya teslim edilecekse ve bunlardan bir kısmı tek bir SMTP sunucusundaysa, bu sunucuya iletinin sadece tek bir kopyası aktarılmalıdır *ÖNERİ*. Yani, SMTP istemcisi böyle bir komut dizisi yerine:

MAIL, RCPT, DATA, ..., MAIL, RCPT, DATA

böyle bir komut dizisini kullanmalıdır:

MAIL, RCPT, RCPT,... RCPT, DATA.

Yine de, çok fazla adres varsa, MAIL komutu başına RCPT komutu sayısına bir sınırlama getirilebilir *SEÇİMLİK*. Bu verimli özelliğin gerçeklenmesi kesinlikle önerilmektedir.

Benzer şekilde, teslimatlarda tam zamanındalığın sağlanması için, SMTP istemcisi aynı anda çok sayıda giden posta aktarımını destekleyebilir *SEÇİMLİK*. Bununla birlikte, bütün kaynakların postaya tahsis edilmesinden korunmayı sağlayacak bir sınırlama uygun olabilir.

SMTP sunucusu her zaman SMTP portunu dinlemeyi sürdürmeye çalışmalıdır *ÖNERİ*. Bu, SMTP için gelen çok sayıda TCP bağlantısının desteklenmesini gerektirir. Bazı sınırlar konulabilir *SEÇİMLİK*, fakat aynı anda birden fazla SMTP aktarımını kabul edemeyen sunucular bu belirtimin amacıyla uyumlu değildir.

Yukarıda bahsedildiği gibi SMTP sunucu postayı belli bir konak adresinden almaktayken bu konak adresi için bekleyen bir postayı yineleyebilmek için kendi SMTP kuyruklama mekanizmasını etkinleştirebilir.