2.3. Terminoloji

Özgün İngilizce metindeki "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" ve "OPTIONAL" anahtar sözcüklerinin yerine kullanılan Türkçe karşılıklar ve bunlarla belgede karşılaşıldığında nasıl yorumlanmaları gerektiği aşağıda açıklanmıştır. Dilimizde fiillerin çekimleri için ayrı birer sözcük bulunmadığından bunların geçtiği cümleler aşağıdaki gibi imlenmiştir.

*ZORUNLU*

Bu imleme özgün metindeki MUST, REQUIRED veya SHALL terimlerinin yerine kullanılmıştır ve belirtimdeki bahse konu niteliğin mutlaka gerçeklenmesi gereken bir nitelik olduğunu belirtir.

*YASAK*

Bu imleme özgün metindeki MUST NOT veya SHALL NOT terimlerinin yerine kullanılmak için tasarlanmış ama yerine *ZORUNLU* imi kullanılmıştır (olumsuz cümleyi olumlamaması için) ve belirtimdeki bahse konu niteliğin kesinlikle gerçeklenmemesi gereken bir nitelik olduğunu belirtir.

*ÖNERİ*

Bu imleme özgün metindeki SHOULD veya RECOMMENDED terimlerinin yerine kullanılmıştır ve belli durumlarda belli bir öğenin yoksayılmasını gerektiren geçerli sebeplerin elbette varolabileceği ancak farklı bir rota seçmeden önce tüm olasılıkların anlaşılması ve ağırlıklarının dikkatle gözden geçirilmesinin de gerekliliğini belirtir.

*ÖNERİLMEZ*

Bu imleme özgün metindeki SHOULD NOT veya NOT RECOMMENDED terimlerinin yerine kullanılmak için tasarlanmış ama yerine *ÖNERİ* imi kullanılmıştır (olumsuz cümleyi olumlamaması için) ve belli bir davranışın kabul edilebilir hatta yararlı olduğu belli durumlarla ilgili geçerli sebeplerin tabii ki varolabileceği ancak bahse konu davranış gerçeklenmeden önce tüm olasılıkların anlaşılması ve ağırlıklarının dikkatle gözden geçirilmesinin de gerekliliğini belirtir.

*SEÇİMLİK*

Bu imleme özgün metindeki MAY veya OPTIONAL terimlerinin yerine kullanılmıştır ve belirtimdeki bahse konu niteliğin gerçeklenmesinin gerçekten isteğe bağlı olduğunu belirtir. Bir üretici belli bir seçeneği pazar onu istiyor diye ya da başka bir üreticinin bu seçeneği sağlamayan bir ürününe üstün olması için ürününde bulundurmayı isteyebilir. Belli bir seçeneği içermeyen bir gerçeklenimin aynı seçeneği içeren bir gerçeklenimle, hatta işlevselliği azaltarak olsa bile, birarada çalışabilmeye hazır olması gerekir *ZORUNLU*. Aynı minvalde, belli bir seçeneği içeren bir gerçeklenimin de aynı seçeneği içermeyen bir gerçeklenimle birarada çalışabilmeye hazır olması gerekir *ZORUNLU* (tabii ki seçeneği sağlayan özellik için değil).

2.3.1. Posta Nesneleri

SMTP posta nesnesi aktarır. Bir posta nesnesi ise bir zarf ve zarfın içindekilerden oluşur.

SMTP zarfı ardarda uygulanan SMTP protokol birimleriyle gönderilir (SMTP Yordamları: Bir Bakış bölümünde açıklanmıştır). Zarf, bir tasarlayıcı adresi (hatalar ona raporlanır), en az bir tane alıcı adresi ve isteğe bağlı protokol eklenti bileşenlerinden oluşur. Geçmişte, gönderici adresini belirten komutun (RCPT TO) çeşitli şekilleri, hemen bakıverme gibi başka teslimat kiplerini belirtmekte kullanılırdı; bu kullanım şekilleri artık önerilmememektedir (RFC 821'in Önerilmeyen Özellikleri ve “Postalamayıp Gönderivermek” bölümlerine bakınız).

SMTP içeriği, SMTP DATA protokolü biriminde gönderilir ve iki kısımdan oluşur: başlıklar ve gövde. Eğer içerik diğer çağdaş standartlarla uyumluysa, başlıklar, ileti biçimi belirtimindeki [32] gibi bir isim/değer çiftleri listesi şeklinde olur; gövde ise, eğer yapılandırılmışsa, MIME'ye [12] uygun olarak tanımlanmıştır. İçerik metinsel bir doğaya sahip olup, US-ASCII karakter kümesi [1] kullanılarak oluşturulur. SMTP eklentileri ("8BITMIME" [20] gibi) içerik gövdesi açısından bu sınırlamaları esnetebildiğinden, içerik başlıkları daima US-ASCII karakter kümesi kullanılarak kodlanır. US-ASCII karakter kümesi dışındaki başlık değerlerini US-ASCII karakter kümesini kullanarak ifade edebilmek için bir MIME eklentisi [23] olarak bir algoritma tanımlanmıştır.

2.3.2. Göndericiler ve Alıcılar

RFC 821'de SMTP aktarımının taraflarını oluşturan iki konak "SMTP-gönderici" ve "SMTP-alıcı" olarak açıklanmıştı. Bu belgede şu an ki endüstri terminolojisini yansıtmak için bu kullanım değiştirilmiş olup, bunlardan bahsedilirken sırasıyla "SMTP istemcisi" (bazan sadece "istemci") ve "SMTP sunucusu" (veya sadece "sunucu") terimleri kullanılmıştır. Belirtilen konağın bir röle olması durumunda, konak hem sunucu hem istemci olarak davranabildiğinden yapılana açıklık getirmek amacıyla hala "alıcı" ve "gönderici" terminolojisi de kullanılmaktadır.

2.3.3. Posta Aracıları ve İleti Depoları

Ek posta sistemi terminolojisi RFC 821 yayınlandıktan sonra yaygın duruma geldi ve uygun düştükçe de bu belirtimde kullanıldı. Kısmen, SMTP sunucuları ve istemcileri bir posta aktarım hizmeti sağlamaları nedeniyle "Posta Aktarım Aracıları" (MTA - Mail Transfer Agent) gibi davranırlar. "Posta Kullanıcı Aracıları" (MUA veya UA - Mail User Agent) ise postanın kaynakları ve hedefleri olarak düşünülürler. Kaynakta, MUA'lar bir kullanıcıdan aktarılmış olan postayı toplarlar ve bir MTA'ya bırakırlar; nihai ("teslimatçı") MTA'lar ise postayı bir MUA'ya bırakan aracılar olarak (veya en azından örneğin iletiyi bir "ileti deposu"na emanet eden bir posta aktarma sorumlusu olarak) düşünülür. Bununla birlikte, bu terimler başka yerlerde en azından görünürde oldukça kesin tanımlıymış gibi kullanılmasına rağmen MUA'lar ve MTA'lar arasında varolduğu öngörülen sınır çizgisi, Genel Ağ postasıyla ilgili kabullere/standartlara uyan ortak pratiklere genellikle tam olarak uymaz. Dolayısıyla okuyucu, bu terimlerin geçtiği diğer yerlerde yapılan öngörülere bağlı olarak kavramlar arasında sıkı ilişkiler ve sorumluluklar olduğu sonucunu kolayca çıkarmamalıdır.

2.3.4. Konak

Bu belirtimin amacına uygun olarak, bir konak Genel Ağ'a (veya bazı durumlarda, özel bir TCP/IP ağına) bağlı ve SMTP protokolünü destekleyen bir bilgisayar sistemidir. Konaklar isimleriyle bilinirler (bkz: "Alan"; hemen aşağıda...); sayısal adreslerle tanımlamaktan artık vazgeçilmiştir.

2.3.5. Alan

Bir alan (veya alan adı) noktalarla ayrılmış bileşenlerden oluşur. Bu bileşenlerde (DNS terminolojisinde [22] "yaftalar") SMTP'nin amacına uygun olarak sadece ASCII karakter kümesindeki [1] harfler, rakamlar ve tire işaretleri kullanılabilir. Alan isimleri konakların ve alan adı hiyerarşisindeki diğer öğelerin isimleri olarak kullanılırlar. Örneğin, bir alan, bir rumuza (bir CNAME kaydı) atıf yapabileceği gibi bir konak ismini göstermek yerine postayı teslim almakta kullanılan posta aktarımcı (MX) yaftasına da atıf yapabilir. [22] ve bu belirtimin Adres Çözümleme ve Posta Yönetimi bölümüne bakınız.

Alan adı bu belgede ve [22] belgesinde açıklandığı gibi bir bütündür ve tamamen nitelikli bir isimdir (İngilizce "Fully-Qualified Domain Name", kısaca "FQDN" olarak bilinir). FQDN biçiminde olmayan bir alan adı bir yerel rumuzdan başka birşey değildir. Yerel rumuzlar herhangi bir SMTP aktarımında görünmemelidir *ZORUNLU*.

2.3.6. Tampon ve Durum Tablosu

SMTP oturumları, mevcut durumun ortak bir görünümünü her iki tarafında dikkatle sürdürmesi bakımından durumsaldır. Bu belgede, bu durumu sunucu üstündeki bir sanal "tampon" ve bir "durum tablosu"na göre modelleyeceğiz. Bu durum aynı zamanda bir istemci tarafından da örneğin "tamponu temizle" veya "durum tablosunu sıfırla" şeklinde, tampondaki bilginin iptal edilmesinin ve önceki durumlardan birine dönülmesinin sağlanması biçiminde kullanılabilir.

2.3.7. Satırlar

SMTP komutları ile bir hizmet eklentisi tarafından değiştirilmedikçe ileti verisi "satırlar" halinde aktarılır. Satırlar, ASCII karakterlerinden sırayla "CR" (onaltılık kodu: 0D) ve "LF" (onaltılık kodu: 0A) ile biten sıfır veya daha fazla veri karakterinden oluşur. Bu satır sonlandırma dizgesini bu belgede <CRLF> biçiminde kullanacağız. Uyumlu gerçeklenimlerin bir satır sonlandırıcı olarak başka bir karakter dizisi üretmemeleri veya bunları tanımamaları gerekir *ZORUNLU*. Satır uzunluğu ile ilgili sınırlar konusunda sunucular zorlayıcı olabilir *ÖNERİ* (Boyutlar ve Zamanaşımları bölümüne bakınız).

Ek olarak, "CR" ve "LF" karakterlerinin metin içinde "çıplak" olarak (yani diğeri olmaksızın) görünmesinin, posta sistemini bir araç olarak kullanan posta gerçeklenimleri ve uygulamalarında yolaçtığı sorunlarla ilgili uzun bir geçmiş vardır. SMTP istemci gerçeklenimleri, satır sonlandırıcı olarak kullanmak dışında, bu karakterleri aktarmamalıdır *ZORUNLU* ve yukarıda değinildiği gibi sadece bir <CRLF> dizgesi olarak aktarmalıdır *ZORUNLU*.

2.3.8. Oluşturucu, Teslimatçı, Röle ve Ağ geçidi Sistemler

Bu belirtim, SMTP sistemlerinin dört türü arasında elektronik posta aktarımında oynadıkları rollere göre bir ayrıma gider. "Oluşturucu" sistem (bazan SMTP oluşturucu da denir) postayı Genel Ağ'a veya daha da genel olarak bir aktarım hizmeti ortamına salan sistemdir. "Teslimatçı" SMTP sistemi, postayı bir aktarım hizmeti ortamından alıp ya bir posta kullanıcısı aracısına aktarır ya da posta kullanıcı aracısının bir ara uğrayıp alacağını umduğu bir ileti deposuna emanet eder. "Röle" SMTP sistemi (genellikle sadece "röle" denir), postayı bir SMTP istemcisinden alır ve izleme bilgisi eklemek dışında ileti verisine dokunmaksızın, tekrar rölelenmek veya teslim edilmek üzere başka bir SMTP sunucusuna aktarır. "Ağ geçidi" SMTP sistemi (genellikle sadece "ağ geçidi" denir) ise, bir aktarım ortamındaki bir istemci sistemden postayı alır ve başka bir aktarım ortamındaki bir sunucu sisteme aktarır.

Protokollerin veya iletilerin anlambilimsel yapılarının aralarındaki, bir ağ geçidinin her iki tarafındaki aktarım ortamlarındaki farklarından dolayı, SMTP röleleme sistemleri söz konusu olduğunda izin verilmeyen ileti dönüşümlerinin ağ geçidi sisteminde uygulanması gerekebilir. Bu belirtimin amaçları gereği, adresleri yeniden yazan güvenlik duvarları, her iki tarafında da SMTP kullanılıyor olsa bile, ağ geçitleri olarak ele alınırsa daha iyi olur [11].

2.3.9. İleti İçeriği ve Posta Verisi

DATA komutundan sonra kabul edilmiş ama veri sonu belirtecinden önce aktarılmış olan malzemeyi betimlemek için "ileti içeriği" ve "posta verisi" terimleri bu belgede birbirlerinin yerine kullanılmıştır. İleti içeriği ileti başlıklarını ve "yapılandırılmış olması olası" ileti gövdesini içerir. MIME belirtimi [12] yapılandırılmış ileti gövdeleri ile ilgili standart mekanizmaları sağlar.

2.3.10. Posta Kutuları ve Adresler

Bu belirtimdeki kullanımına göre, bir "adres" postanın gönderileceği kullanıcıyı veya postanın emanet edileceği yeri betimleyen bir karakter dizisidir. "Posta kutusu" terimi ise, bu emanet yerini ifade eder. Bu iki terim, postanın bırakılacağı yer (posta kutusu) ile teslim alacak kullanıcı (adres) arasındaki farkın önemli olması dışında, genel olarak birbirlerinin yerlerine kullanılırlar. Bir adres normalde kullanıcı ve alan belirtimlerinden oluşur. Standart posta kutusu isimlendirme uzlaşımı "yerel-kısım@alan" biçiminde tanımlanmıştır: çağdaş kullanım basit "kullanıcı isimlerinden" çok daha geniş bir uygulama kümesine izin verir. Bu sebeple ve ara konakların aktarımı eniyilemeye çalışmak adına değişiklik yapmaları sebebiyle ortaya çıkan sorunların uzun bir geçmişe sahip olmasından dolayı, yerel-kısmın, sadece adresin alan parçasında belirtilen konak tarafından atanan ve yorumlanan anlamsal biçimde olması/kalması gerekir *ZORUNLU*.

2.3.11. Yanıt

Bir SMTP yanıtı, bir komuta cevap olarak aktarım kanalı üzerinden alıcıdan göndericiye gönderilen bir (olumlu veya olumsuz) alındıdır. Bir yanıtın genel biçimi (başarı veya başarısızlık belirten) bir sayısal tamamlama kodu ile başlayan bir metin dizgesidir. Kodlar programlar tarafından kullanılmak için, metin ise normal olarak insan kullanıcılar için tasarlanmıştır. En son çalışmada [34] ek ve daha özel tamamlama kodları da dahil olmak üzere yanıt dizgelerinin böyle bir yapılandırması belirlenmiştir.