← rfc/
╔══════════════════════════════════════════════════════════════════════════╗
RFC 724 · mail

ARPA Ağ Mesajlarının Biçimi İçin Önerilen Resmî Standart

Yazar
NIC #37435
Kurum
Tarih
12 Mayıs 1977
Durum
Network Working Group Yorum Talebi
Kanal
mail/

RFC 724

NIC #37435
12 Mayıs 1977

ARPA Ağ Mesajlarının Biçimi İçin Önerilen Resmî Standart

yazan

Ken Pogran, MIT-LCS/CSR (Pogran at MIT-Multics)
John Vittal, BBN (Vittal at BBN-TENEXA)
Dave Crocker, RAND-ISD (DCrocker at Rand-Unix)
Austin Henderson, BBN (Henderson at BBN-TENEXD)

Önsöz

ARPA'nın Bilgisayar Destekli İnsan İletişimi Komitesi (CAHCOM), günümüzde Ağ üzerindeki çeşitli mesaj hizmeti alt sistemlerinin ihtiyaçlarını yeterli biçimde karşılayacak şekilde ARPA Network posta başlıklarının biçimi için resmî bir standart yayımlamak istemektedir. Bu RFC'nin yazarları, bu yeni standardı geliştirme görevi verilen CAHCOM alt komitesini oluşturmaktadır; bu belge, konu hakkındaki mevcut düşüncelerimizi ve belirli bir öneriyi sunmaktadır.

Bu belge aşağıdaki şekilde düzenlenmiştir: Öncelikle, ARPA Network "posta" veya "mesaj" hizmeti olarak bilinen yapının gelişim tarihini ve bize göre en acil olan meseleleri—bugün çözümü bulunmayan ve mesaj alt sistemlerinin daha fazla gelişmesini engelleyen sorunları—sunuyoruz. Ardından yeni ARPA Network Mesaj Başlığı standardının teknik tanımını sunuyoruz. Bunu bir Referanslar bölümü izlemektedir.

Temelde, Request for Comments (RFC) 561, "Standardizing Network Mail Headers" ve RFC 680, "Message Transmission Protocol" için bir revizyon öneriyoruz. Bu revizyon, önceki söz diziminin bazı bölümlerini kaldırmakta ve yoğunlaştırmakta, ayrıca ağ adresi tanımlamasına birkaç özellik eklemektedir. Özellikle, alıcı olarak posta kutularından ziyade kişilere odaklanıyor ve saklanan adres listelerine başvurulmasına izin veriyoruz. Bu söz diziminin çoğu kullanıcının acil ihtiyaçlarını karşılamak için yeterli yetenekler sağlayacağını ve dolayısıyla geliştiricilere yeni bir posta iletim protokolünü "doğru şekilde" geliştirmek için yeterli hareket alanı vereceğini bekliyoruz. Ağ topluluğunda bu tür bir standart söz dizimi lehine yeterli uzlaşma bulunduğuna ve bu nedenle şu anda benimsenmesinin mümkün olduğuna inanıyoruz.

Bu önerilen standardın durumunu açıkça belirtmek isteriz: CAHCOM Yürütme Komitesi, mesaj hizmetleri alanında ARPANET standartlarını belirleyen kuruluş olarak Message Service Committee'nin yerini almıştır. Bu CAHCOM alt komitesinin önerisinin, nihai biçimine ulaştığında, CAHCOM tarafından bir ARPANET standardı olarak kabul edilmesi beklenmektedir. Bu standardın mümkün olan en iyi hale gelmesi amacıyla, bu öneriyi bir RFC olarak dağıtıyoruz.

Her türlü yorum ve eleştiriyi bu RFC'nin yazarlarından herhangi birine 15 Haziran 1977 tarihine kadar gönderiniz. Standardın 1 Eylül 1977 tarihinde resmî olarak kabul edilmesi ve ana bilgisayarların bu söz dizimini 1 Ocak 1978 tarihine kadar kabul etmesi planlanmaktadır.

İçindekiler

I. ARPANET Mesaj Standartlarıyla İlgili Sorunlar

II. ARPA Ağ Mesajlarının Biçimi İçin Standart

III. Referanslar

Ek

I. ARPANET Mesaj Standartlarıyla İlgili Sorunlar

A. Arka Plan ve Tarihçe

Günümüzde ARPA Network "posta" veya "mesaj" hizmeti, iletim mekanizması olarak File Transfer Protocol'ün iki özel komutunu kullanmaktadır. FTP yapısı içinden bakıldığında, başlık ve metin dâhil olmak üzere tüm mesaj, FTP MAIL ve MLFL komutları için veri niteliğindedir. Bu olanak File Transfer Protocol'e sonradan eklenmiştir; ayrı bir posta iletim protokolü tanımlanana kadar kullanılmak üzere geçici bir çözüm olarak düşünülmüştür. Böyle bir protokolün çeşitli sürümleri önerilmiştir, ancak henüz hiçbiri genel kabul görmemiştir. Bu arada, özgün geçici olanak üzerinde iyileştirmeler yapma girişimleri olmuştur.

Çeşitli ana bilgisayar sistemlerinde (özellikle TENEX) mesaj hizmeti alt sistemleri gelişip gelen mesajların temel düzeyde ayrıştırılması yapılmaya başlanınca, bu FTP komutları kullanılarak ana bilgisayarlar arasında iletilen mesajların başlıklarının biçim ve içeriğinin standartlaştırılmasının arzu edilir olduğu açık hale gelmiştir. Bu amaçla, geçici bir komite RFC 561'i yazmış ve standart bir mesaj başlığı biçimi önermiştir. Komite resmî değildi, bu nedenle bir standart koyma yetkisine sahip değildi; yalnızca öneride bulunabilirdi. Ancak önerdiği standart acil bir ihtiyacı yeterli şekilde karşılamış ve genel olarak benimsenmiştir.

Birkaç önemli nokta belirtilmelidir:

  1. RFC 561 bir mesaj başlığı kavramını tanımlamış ve bunu mesajın gerçek metninden ayıran söz dizimini belirtmiştir.
  2. En açık ve en acil ihtiyaç duyulan başlık öğeleri için standart bir biçim önermiştir: "From:", "Date:", ve "Subject:".
  3. Diğer tüm başlık öğeleri için genel bir standart söz dizimi kullanılmasını önermiştir.
  4. RFC 561 bugün hâlâ gayriresmî bir standarttır ve yararlılığı nedeniyle çoğu kişi tarafından uygulanmaktadır.
  5. Söz dizimi, insanların metni özel mesaj işleme sistemlerinin yardımı olmadan kolayca okuyabilmesini sağlamak üzere tasarlanmıştır.

Mesaj hizmetleri daha gelişmiş hâle geldikçe, RFC 561'in "miscellaneous" kategorisindeki belirli başlık öğelerine olan ihtiyaç arttı: özellikle "To:" ve "cc:" farklı mesaj hizmetleri tarafından üretilmeye ve tanınmaya başlandı. Ancak bu öğelerin içeriğinin söz dizimi için belirli bir standart yoktu. TENEX üzerindeki mesaj hizmeti alt sistemleri bu öğeler için belirli bir biçim geliştirdi; Ağ üzerindeki mesajların çoğu diğer ana bilgisayar türlerinden ziyade TENEX ana bilgisayarlarından kaynaklandığından, bu alanlar için TENEX biçimi kısa sürede fiilî bir standart hâline geldi. TENEX üzerindeki mesaj hizmeti alt sistemleri, bu alanların TENEX tarafından üretilen biçimde olmasını bekleyerek onları ayrıştırmaya başladı.

Diğer ana bilgisayarlardaki mesaj hizmeti alt sistemleri—örneğin Multics—bu alanlar için başka biçimler denemeye başladı; çünkü bunlar için bir standart yoktu. Ancak kısa süre sonra TENEX mesaj hizmeti alt sistemlerinin kullanıcılarından, "standart olmayan" mesaj başlıklarının fiilî "standart" söz dizimine göre ayrıştırılamadığına dair şikâyetler almaya başladılar.

RFC 561 yayımlandıktan sonra kullanılmaya başlanan ek başlık alanlarını standartlaştırma girişiminde bulunma zamanının geldiğini fark eden ARPA'nın Message Service Committee'si, 1975 yılında RFC 561'in gözden geçirilmiş bir sürümünü geliştirmek üzere küçük bir gruba görev verdi. Bu yeni sürüm, bu ek mesaj başlığı alanlarının söz dizimini tanımlayacaktı. Bu küçük grup hakkında birkaç nokta belirtilmelidir: birincisi, TENEX odaklıydılar; istedikleri mesaj başlığı öğelerinin işlevselliği, TENEX mesaj alt sistemlerinde zaten mevcut olan bir başlık öğesinin işlevselliğiyle örtüştüğünde, TENEX mesaj alt sistemlerinin kullandığı söz dizimini benimsediler. İkincisi, TENEX mesaj alt sistemlerinde bulunmayan ek başlık öğelerini Message Service Committee'nin tartışmalarına dayandırdılar. Üçüncüsü, bir belgenin Network RFC olarak yayımlanma prosedürüne aşina değillerdi.

Bu grubun ürettiği ve RFC 680, "Message Transmission Protocol" olarak adlandırılan belge yalnızca sınırlı bir dağıtıma sahip oldu. Başlığı yanıltıcı olduğu için durum daha da karıştı; çünkü belge ARPA Network ana bilgisayarları arasında mesaj iletimi için bir protokol değil, standart File Transfer Protocol aracılığıyla iletilen mesajların biçimi için bir standarttı. Message Service Committee dâhil bazıları, RFC 680'in bir Network Standardı hâline geldiğine inandı. Bu tam olarak doğru değildi; çünkü hiçbir zaman uygun şekilde dağıtılmamış ve hiç kimse tarafından bir yorum isteği belgesinden kabul edilmiş resmî bir ARPA Network standart belgesine dönüştürülmek üzere "resmî onay" almamıştı.

Belgenin durumuna ilişkin bu karışıklığı yansıtan bir gerçek de, belgenin şu anda "resmî" ARPANET Protocol Handbook içinde yer almasıdır, ancak çoğu kullanıcı ve mesaj sistemi uygulayıcısı bunun farkında değildir.

Tüm eksikliklerine rağmen RFC 680, tıpkı kendisinden önce RFC 561'in yaptığı gibi gerekli bir hizmet sunmuştur. Gerekli olduğu bir dönemde ek mesaj başlığı öğelerini tanımlamıştır. Ne yazık ki, grup başkalarından fikir ve katkı istemediği için tanım yeterli bir topluluk ihtiyacı kümesine yeterince yanıt vermemiştir. Ayrıca belgenin yayımlanma biçimi—ya da yayımlanmama biçimi—çok daha iyi olabilirdi.

RFC 680'i almamış mesaj işleme alt sistemi uygulayıcıları kendi yollarına gitmeye devam etti ve bunu yapmakta haklı olduklarını düşündüler; RFC 680'i bir standart olarak kabul edenler ise, kendilerine göre kendine özgü mesaj hizmeti alt sistemleri geliştiren "sapkın" uygulayıcılara şikâyet etmekte ve onları eleştirmekte haklı olduklarını düşündüler.

Belki de geçici posta olanaklarının doğası gereği, kullanıcılar yakın zamana kadar sistemi hayal güçlerinin sınırlarına kadar zorlamaya çalışmadılar. Ancak günümüzde birkaç farklı site "geçici" posta olanağını tasarlandığından daha fazla amaç için ve hem birbirleriyle hem de bu olanağın özgün amacıyla uyumsuz şekillerde kullanmaktadır. Posta alt sistemi uygulayıcılarından giderek daha fazla, kendine özgü ana bilgisayarlardan gelen postaların işlenmesini sağlamaları istenmektedir. Ayrıca RFC 680'in söz dizimi içinde makul şekilde tanımlanamayacak kadar yararlı olan birkaç çok belirgin özelliğin bulunduğu da açık hâle gelmiştir.

B. Konular ve Sonuçlar

İlk bakışta, günümüzdeki biraz kaotik durumun çözümünün mevcut "geçici" posta olanaklarını derhâl terk edip gerçek bir posta iletim protokolünü benimsemekle sağlanabileceği düşünülebilir. Bunun şu anda uygun olmayacağına güçlü biçimde inanıyoruz; çünkü bugün Ağ topluluğu içinde tam ve yeterli bir posta iletim protokolünün nasıl tanımlanacağı ve uygulanacağı konusunda genel bir anlayış bulunmadığını düşünüyoruz. Bununla birlikte, Ağ topluluğu içinde nihayet bu soruna ciddi biçimde yönelme yönünde güçlü bir kararlılık oluştuğuna inanıyoruz ("geçici" posta iletim olanağının tanımlanıp geliştirilmesi sırasında böyle bir durum yoktu).

Posta protokolü sorununa doğrudan yönelen girişimler şu ana kadar en az iki posta iletim protokolü önerisi ortaya çıkarmıştır. Neden bu protokollerden biri hemen benimsenmesin? Genel olarak, deneysel Ağ yazılımlarının yeterince tasarlanmış ve tamamen çalışır durumda kabul edilme eğiliminin erken ortaya çıktığını düşünüyoruz. Genellikle önerilen sistem veya protokol, daha önce mevcut olandan o kadar daha iyi olur ki deneysel niteliği göz ardı edilir ve düzgün biçimde gelişip olgunlaşma fırsatı bulamadan kullanıma sokulur. Bu olgunun Ağ posta sistemini hâlihazırda etkilediğinden daha fazla etkilememesi konusunda oldukça kaygılıyız.

ARPA Topluluğunda RFC 561 ve 680'de belirtilen söz dizimini anlayan posta sistemlerine sahip birkaç site olduğu doğru olsa da, ayrıca bazı diğer sitelerdeki posta üreten programların sağladığı bazı "standart dışı" söz dizimlerini de destekleseler bile, çoğu posta sistemi alınan mesajların içeriğinin büyük bölümünü ayrıştırmaz. Burada belirtilen söz dizimi değerlendirilirken önemli bir husus şudur: insanlara gönderilen mesajlar insanlar tarafından kolayca okunabilmelidir. Çirkin fakat söz dizimi açısından uygun bir biçimi okunması kolay bir hâle dönüştürebilen ayrıştırıcılar, günümüz mesaj sistemlerinde kuraldan çok istisnadır. Ayrıca mevcut "standart dışı" söz diziminde yapılacak değişiklikler en aza indirilmeli, böylece mevcut yazılımlarda yalnızca küçük değişiklikler gerektirme şartının kabul edilme olasılığı artırılmalıdır.

Bu söz dizimi ile aşağıdaki mekanizmaları sunuyoruz:

  1. Posta sistemi kullanıcıları tek bir makinede veya birden fazla makinede birden fazla posta kutusuna sahip olabilir ve bunların tümü aynı şekilde ele alınır; bir kullanıcının varsayılan posta kutusu doğrudan giriş adıyla ilişkili olmak zorunda değildir.

  2. Bir kişi için gönderilen posta, tek bir varsayılan posta kutusundan farklı bir yere yönlendirilebilir.

  3. Adlandırılmış gruplar hem bireylerden hem de (muhtemelen) diğer adlandırılmış gruplardan oluşabilir (yani gruplar içinde iç içe yapı mümkündür).

  4. Adres listeleri başka, saklanmış listelere referanslar içerebilir. Saklanan listenin elle veya otomatik olarak alınabilmesini sağlamak için listeyi getirmeye yarayan tam yol belirtilebilir.

  5. Adres listeleri standart ARPANET mesaj sistemi üzerinden erişilemeyen adreslere referanslar içerebilir. Örneğin ABD posta sistemi adresleri belirtilebilir. Bu tür adreslerin elbette ARPANET sistemi tarafından göz ardı edilmesi beklenir; ancak bazı siteler bu bilgiyi kullanmak için hizmetler sağlayabilir (örneğin mesajın bir kopyasını otomatik olarak bir satır yazıcısına göndererek Posta sistemi üzerinden iletime hazırlamak).

  6. Parantez içi açıklamalar veya yorumlar bazı başlık öğeleri içinde yer alabilir ve söz dizimi açısından bu şekilde tanınabilir.

I. ARPANET Mesaj Standartlarıyla İlgili Sorunlar

B. Konular ve Sonuçlar

  1. Alınan mesajlar, kullanıcıya sunulmadan önce bir programın mesajı (veya bir bölümünü) ayrıştırmasına gerek kalmadan insanlar tarafından okunabilecek durumdadır; ancak aynı zamanda bir ayrıştırma programının kullanıcıya sunulan materyalin görünümünü ve içeriğini değiştirmesine imkân verecek yeterli resmî söz dizimi de vardır. Mesaj görüntüleme yazılımı mesajın görünümü üzerinde önemli ölçüde denetim uygulayabilse de, bir mesajın gerçek biçiminin insanlar için HOŞ okunur olması tamamen mesajı oluşturan programın sorumluluğundadır.

Kimlik doğrulama için herhangi bir mekanizma sağlanmamıştır; çünkü Ağ posta güvenliğini uygulamaya koyacak mekanizmalar sunmamaktadır. Bununla birlikte söz dizimi "doğruluk" kavramının bir yönünü ele alır: geçerli bir ağ adresi olduğu iddia edilen bir adres ile yalnızca insan katılımcıların rahatlığı için eklenmiş serbest metin arasında bir ayrım yapılır.

C. Mesaj Bölümleri

Farklı mesaj bölümlerinin oynadığı roller konusunda bazı karışıklıklar olmuştur. Einar Stefferud, zarf, mektup başlığı ve mektup içeriği bakış açısının kullanılmasını önermiştir. Mesajlar içinde yapılandırılmış bölümlerin bulunması ayrıca "başlıklar" kavramına da başvurulmasını gerektirir.

Bilgisayar tabanlı mesaj sistemlerinde insan kullanıcılar genellikle "zarflarla" karşılaşmaz; bunlar çoğu zaman mesajın teslim edilmesi için katılan sistem(ler) tarafından otomatik olarak oluşturulur. Örneğin TENEX üzerinde zarf, iletilmeyi bekleyen mesajı içeren dosyanın adıdır. FTP sunucuları için ise MAIL veya MLFL komut satırının veri kısmıdır. Bazı sistemler zaman damgası ve çıkış yapılan ana bilgisayar adı gibi "zarf benzeri" bilgileri mesaj başlığına ekler.

Kâğıt tabanlı iletişimlerde başlıklar hem mesaj gövdesinden önce (örneğin "To:" ve "From:") hem de sonra (örneğin "cc:" ve "enclosure:") yer alır. Bu standart içinde tüm başlıklar mesaj gövdesinden önce yer alır; ancak yerel mesaj görüntüleme programları bu sıralamayı değiştirmeyi tercih edebilir.

Wayne Hathaway, ARPANET ileti biçiminin antetlerin belirtilmesini desteklemediğine dikkat çekmiştir; çünkü bunlar bir tür kurumsal halkla ilişkiler sembolüdür. Ancak bazı kendine özgü özellikler, özel alan adlarının seçilmesi yoluyla desteklenmektedir.

Genel olarak, bir iletinin başlık bölümünün, iletinin yaşamı boyunca çeşitli roller üstlendiğini ve Stefferud tarafından önerilen üç işlevin her birine farklı biçimlerde katıldığını anlamak önemlidir.

D. Standardın Benimsenmesi

Bu standardın belirlenmesinin ilk aşamalarında, mevcut standarttan bu yeni standarda geçiş sırasında yaşanabilecek sorunlar hakkında büyük ölçüde endişe dile getirilmiştir. Bizce asıl sorun, MEVCUT RESMÎ BİR STANDARDIN OLMADIĞININ fark edilmemesidir. Yeterince çok sistem, yeterince örtüşen davranışlara sahiptir ve bu durum mevcut posta ortamının çalışmasına olanak tanır; ancak bu hiçbir şekilde bir standart oluşturmaz.

Gerçekte, önerilen standardın getirdiği yeni gereksinimlerin, sistem davranışlarındaki mevcut çeşitlilikten kaynaklanan belirsizliklere kıyasla daha az karmaşıklık içerdiğine güçlü biçimde inanıyoruz.

II. ARPA Ağ Mesajlarının Biçimi için Standart

Bu standart, ARPANET Request for Comments numara 561, "Standardizing Network Mail Headers", ve 680, "Message Transmission Protocol" belgelerinde belirtilen gayriresmî standartların yerini alır. Bu belgede genel bir çerçeve tanımlanmaktadır. Ardından biçimsel söz dizimi belirtilir ve bunu anlam bilgisine ilişkin bir tartışma izler. Son olarak bir dizi örnek verilir.

Bu tanım, kesinlikle ARPANET üzerindeki ana bilgisayarlar arasında aktarılacak olan şeyin ne olduğunu tanımlamak amacıyla hazırlanmıştır. Ağ üzerindeki sistemlerin hangi özellikleri desteklemesi gerektiğini veya ileti oluşturma ya da okuma programlarının kullanıcı arayüzlerini belirlemeyi AMAÇLAMAZ.

Tanımın neyi zorunlu kıldığı ile neye izin verdiği arasında bir ayrım yapılmalıdır. Örneğin bir boşluk karakteri <space> ile satır sonu karakteri <crlf> arasında eşdeğerlikler tanımlanmıştır. Bu eşdeğerlikler hem biçimsel tanımı kolaylaştırır hem de iletiler için RESMÎ anlam bilgisinin ne olduğunu gösterir. Belirli uygulamalar, tanımın zorunlu kılmadığı ek ayrımları korumak isteyebilir.

A. Çerçeve

ARPANET ortamının dışında da birçok ileti sistemi bulunduğundan ve bunun yanında ağın içinde de çeşitli sistemler yer aldığından, bu standardın genel çerçevesini ve bunun sonucunda ortaya çıkan yetenekleri ve sınırlamaları değerlendirmek yararlı olabilir.

İletilerin metin satırlarından oluşması beklenir. Bu aşamada çizimlerin, faksimilenin, konuşmanın veya yapılandırılmış metnin kodlanması için özel bir düzenleme yapılmamıştır.

Veri sıkıştırma ya da iletim/depolama verimliliği konularına önemli bir dikkat verilmemiştir. Aslında standart, kullanılan bit sayısı konusunda oldukça serbesttir. Örneğin alan adları kısa özel kodlar yerine serbest metin olarak belirtilmiştir.

Genel bir "memo" çerçevesi kullanılır. Yani bir ileti, katı bir biçimde düzenlenmiş bazı bilgilerden oluşur ve bunun ardından metin olan ve biçimi bu belgede belirtilmeyen iletinin ana bölümü gelir. Katı biçimde düzenlenmiş ("header") bölümündeki bazı alanların söz dizimi bu tanımda belirlenmiştir; başlık alanlarından bazıları tüm iletilerde bulunmak zorundadır. Bu belgede belirtilen alanlara ek olarak başka alanların da yaygın kullanım kazanması beklenmektedir. Kullanıcı tanımlı başlık alanları, sistemlerin işlevselliklerini genişletmelerine olanak tanırken aynı zamanda ortak bir çerçevenin korunmasını sağlar. Yaklaşımımız TELNET protokolününkine benzer; kendisini (isteğe bağlı olarak) genişletmeye olanak sağlayan bir mekanizma içeren temel bir standart tanımlıyoruz. Bu genişletmeler için tanımların yayımlanmasını bu belgenin yazarları düzenleyecektir.

Böyle bir çerçeve, belgenin "tonu"nu ve görünümünü ciddi biçimde sınırlar ve esas olarak çoğu kurum içi iletişim ile nispeten yapılandırılmış kurumlar arası iletişim için kullanışlıdır. Daha gelişmiş bir ortam, bilgilerin çoklu yazı tipi, çoklu renk ve çok boyutlu biçimde kodlanmasına izin verebilir. Çoğu tek makine tabanlı ileti sisteminde olduğu gibi daha sınırlı bir ortam ise alan ekleme yeteneğini ve belirli alanların dahil edilmesine ilişkin kararları daha sıkı şekilde sınırlar. Kâğıt tabanlı iletişimle karşılaştırıldığında, bir iletinin ALICISININ iletinin görünümü üzerinde olağanüstü derecede kontrol uygulayabildiğini belirtmek ilginçtir. Alıcıların sahip olduğu gerçek kontrol miktarı, kullandıkları ileti sistemlerinin yeteneklerine bağlıdır.

B. Sözdizimi

Bu sözdizimi dört bölüm halinde verilmiştir. İlk bölüm, sonraki bölümlerde açıklanan daha üst düzey çözümleyiciye veri sağlayan temel düzeyde bir sözcüksel çözümleyiciyi tanımlar. İkinci bölüm, iletiler ve standart başlık alanları için genel bir sözdizimi sunar. Üçüncü bölüm adreslerin sözdizimini belirtir. Son bölüm ise diğer bölümleri destekleyen bazı genel sözdizimi kurallarını tanımlar.

1. İletilerin Sözcüksel Analizi

a. Genel Tanım

Bir ileti, başlıklardan ve isteğe bağlı olarak bir gövdeden (yani <message-text>) oluşur. <message-text> bölümü yalnızca bir ASCII karakterleri dizisidir; başlıklardan boş bir satır ile (yani <crlf> öncesinde hiçbir şey bulunmayan bir satır) ayrılır.

1) Başlıkların katlanması ve açılması

Her başlık öğesi, tek bir mantıksal uzun ASCII karakter satırı olarak görülebilir. Kolaylık sağlamak için bu kavramsal yapı birden fazla satırlık bir gösterime bölünebilir (yani "katlanabilir"). Genel kural şudur: <linear-white-space> karakterlerinin bulunabileceği her yerde bunun yerine hemen ardından EN AZ bir <linear-white-space> karakteri gelen bir <crlf> ekleyebilirsiniz. Böylece aşağıdaki tek satır

To:  "Joe Dokes & J. Harvey" <ddd at Host>, JJV at BBN

şu şekilde gösterilebilir

To:  "Joe Dokes & J. Harvey" <ddd at Host>,
     JJV at BBN

ve

To:  "Joe Dokes & J. Harvey"
                 <ddd at Host>,
 JJV at BBN

ve

To:  "Joe Dokes
 & J. Harvey" <ddd at Host>, JJV at BBN

Bir başlık alanının bu katlanmış çok satırlı gösteriminden tek satırlık gösterimine geçme sürecine "unfolding" (açma) denir. Açma işlemi, hemen ardından bir <linear-white-space-char> gelen <crlf> dizisinin <linear-white-space-char> ile eşdeğer kabul edilmesiyle gerçekleştirilir.

2) Başlık alanlarının yapısı

Başlık alanları açıldıktan sonra, bunların bir <field-name> ardından : (iki nokta) ve ardından bir <field-body> bileşiminden oluştuğu düşünülebilir. <field-name> yazdırılabilir ASCII karakterlerinden (yani ondalık değeri 33 ile 126 arasında olan karakterler) ve <linear-white-space> karakterlerinden oluşmalıdır. <field-body> ise herhangi bir ASCII karakterinden oluşabilir (<cr> ve <lf> hariç; bunlar açma işlemi sırasında kaldırılmıştır).

Bazı başlık alanları, bazı sistemlerin ayrıştırmak isteyebileceği içsel bir sözdizimine göre yorumlanabilir. Bu alanlara structured fields denir. Tarih ve adres içeren alanlar buna örnektir. Konu alanı gibi diğer alanlar ise yalnızca tek satırlık metin olarak değerlendirilir.

3) Alan adları

<field-name> oluşturmayı ve okumayı kolaylaştırmak için uygun yerlerde <linear-white-space> karakterlerinin serbestçe eklenmesine izin verilir. Bu <linear-white-space> karakterlerinin açık sözdizimiyle <field-name> tanımını karmaşıklaştırmak yerine, basit bir "sözcüksel" çözümleyicinin varlığı varsayılır. Bu çözümleyici, <field-name> oluşturan açılmış metni <linear-white-space> karakterleriyle ayrılmış <atom> dizisi olarak yeniden yorumlar. Alan adı, bu atomların tek bir ASCII boşluk karakteriyle ayrıldığı bir dizi olarak uygun biçimde temsil edilebilir.

4) Alan gövdeleri

Yapılandırılmış alanların oluşturulmasını ve okunmasını kolaylaştırmak için uygun yerlerde <linear-white-space> karakterlerinin serbestçe eklenmesine izin verilir. Bu karakterlerin açık sözdizimiyle yapılandırılmış alan tanımlarını karmaşıklaştırmak yerine, başka bir basit "sözcüksel" çözümleyicinin varlığı varsayılır. Bu çözümleyici, alan gövdesini oluşturan açılmış metni sözcüksel sembollerden oluşan bir dizi olarak yorumlar. Bunlar şunları içerir:

İlk üç sembol kendi kendini sınırlar. Atomlar ise bu özelliğe sahip değildir; bu nedenle kendi kendini sınırlayan semboller ve <linear-white-space> ile sınırlandırılır.

Örneğin bir adres alanının katlanmış gövdesi

":sysmail"@ Some-Host,
Muhammed(I am the greatest)Ali at WBA

şu sözcüksel semboller ve türler olarak analiz edilir:

":sysmail" — quoted string
@ — special
Some-Host — atom
, — special
Muhammed — atom
(I am the greatest) — comment
Ali — atom
at — atom
WBA — atom

b. Biçimsel Tanım

<field>           ::= <field-name> ":" <field-body>

<field-name>      ::= <atom>
                   |  <atom> <field-name>

<field-body>      ::= <field-body-contents>
                   |  <field-body-contents> <crlf>
                      <linear-white-space-char>
                      <field-body>

II. İletilerin Biçimi için Standart

B. Sözdizimi

1. Sözcüksel Analiz

<field-body-contents> ::= <aşağıdaki bölümlerde tanımlandığı
                          üzere <field-body>'yi oluşturan
                          TELNET ASCII karakterleri ve
                          <atom>, <quoted-string>, <text-line>
                          ve <specials> belirteçlerinin
                          birleşimlerinden oluşur>

<atom> ::= <bir veya daha fazla TELNET ASCII
           alfa-sayısal veya grafik karakter
           dizisi; tüm kontrol karakterleri
           (ondalık değeri 33'ten küçük veya
           127'ye eşit olan karakterler) ve
           <delimiters> hariç>

<quoted-string> ::= <çift tırnak işareti ("), ondalık 34>
                    <bir veya daha fazla TELNET
                    ASCII karakterinden oluşan
                    dizi; burada ardışık iki
                    tırnak tek bir tırnak olarak
                    yorumlanır ve dizgenin
                    parçası sayılır> <">

<text-line> ::= <bir veya daha fazla TELNET
                ASCII karakterinden oluşan
                dizi; <cr> ve <lf> hariç>

<message-text> ::= <sıfır veya daha fazla TELNET
                   ASCII karakterinden oluşan
                   dizi>

<delimiters> ::= <specials> | <comment>
               | <linear-white-space> | <crlf>

<specials> ::= "(" | ")" | "<" | ">"
             | "@" | "," | ";" | ":" | <">

<comment> ::= "(" <TELNET ASCII karakterleri,
               <crlf> hariç> ")"

<linear-white-space> ::= <linear-white-space-char>
                       | <linear-white-space-char>
                         <linear-white-space>

<linear-white-space-char> ::= <space> | <horizontal-tab>

<space> ::= <TELNET ASCII space (ondalık 32)>
<tab>   ::= <TELNET ASCII tab (ondalık 9)>

<cr>    ::= <TELNET ASCII carriage return (ondalık 13)>
<lf>    ::= <TELNET ASCII line feed (ondalık 10)>

<crlf>  ::= <TELNET ASCII carriage return/line feed
            (ondalık 13 ardından ondalık 10)>

c. Açıklamalar

1) Yorumlar

Yorumlar yalnızca yapılandırılmış alanların <field-body> bölümleri içinde görünebilir. Bir yorum, tırnaklı bir dizge içinde olmayan ve eşleşen parantezler içinde bulunan herhangi bir TELNET ASCII karakterleri kümesidir; parantezler iç içe olabilir, yani bir yorum dizgesinde sol parantez varsa buna karşılık gelen bir sağ parantez de bulunmalıdır.

Yorumlar, "resmî" adresin parçası olmadıkları için MAIL veya MLFL komutunun bir parçası olarak FTP sunucusuna aktarılmaz.

2) "White space"

Yapılandırılmış alanlarda birden fazla doğrusal boşluk TELNET ASCII karakterinin (<tab> ve <space>) tek bir boşluk olarak ele alındığını ve herhangi bir sembolün etrafında serbestçe bulunabileceğini unutmayın. Tüm başlık alanlarında en az bir <space> yalnızca katlanmış satırların başında zorunludur.

Posta gönderme (yani başlık üretme) programlarını yazanlar, <tab> TELNET ASCII karakterlerinin başka bir ağ ana bilgisayarındaki metnin görünümü üzerindeki etkisinin ağ genelinde tanımlanmış bir karşılığı olmadığını bilmelidir. Bu nedenle ileti başlıklarında <tab> kullanımı izin verilmiş olsa da önerilmez.

İleti içeriklerinin TELNET NVT kurallarına uygun olması gerektiğini unutmayın (örneğin <cr> tek başına kullanılacaksa ardından ya <lf> gelerek <crlf> oluşturmalı ya da <null> gelmelidir).

3) Tırnaklı dizgeler

İzin verilen yerlerde (yani yapılandırılmış alanlarda), tırnaklı dizgeler tek bir sembol olarak ele alınır (yani sözdizimsel olarak <atom> ile eşdeğerdir). Ancak tırnaklı dizgeler birden fazla satıra "katlanacaksa", katlama sözdizimi kurallarına uyulmalıdır (bkz. II.B.1.a.1 ve aşağıda II.B.1.c.6).

Resmî anlam bilgisinin tırnaklı dizgeler içinde <crlf> ile karşılaşmadığını unutmayın; ancak bazı ayrıştırma programları bunların varlığını kaydetmek isteyebilir.

II. İletilerin Biçimi için Standart

B. Sözdizimi

1. Sözcüksel Analiz

4) Parantezleme karakterleri

İyi biçimde iç içe yerleştirilmiş olması gereken iki tür parantez vardır:

5) Bazı özel <atom>ların büyük/küçük harf bağımsızlığı

Tüm posta okuma programları, bazı <atom>ların büyük ve küçük harflerin herhangi bir birleşimiyle gösterilebileceğini varsaymalıdır. Bunlar şunlardır:

Örneğin <field-name> değerleri From, FROM, from ve hatta FroM aynı şekilde ele alınmalıdır.

Bu tanım düzeyinde büyük/küçük harfin diğer <word>ler ve <text-line>lar için önemli olduğunu unutmayın. Ayrıca II.C.1.a.4 bölümüne de bakın.

6) Uzun satırların katlanması

Her başlık öğesi (iletinin alanı) alan adı ve gövdesinden oluşan tek bir satırda temsil edilebilir ve ayrıştırıcının gördüğü de budur. Okunabilirlik için uzun başlık öğelerinin <field-body> kısmının gerçek başlıkta birden fazla satıra katlanması önerilir.

7) Backspace karakterleri

Backspace TELNET ASCII karakterleri (ASCII BS, ondalık 8) <text-line> ve <quoted-string> içinde üstüne yazma etkisi oluşturmak için bulunabilir. Ancak <text-line> veya <quoted-string> başlangıcının sol tarafında üstüne yazma etkisi oluşturacak şekilde backspace kullanımı yasaktır.

II. İletilerin Biçimi için Standart

B. Sözdizimi

2. İletiler

2. İLETİLERİN GENEL SÖZDİZİMİ

NOT: Sözdizimi, <required-headers> içindeki öğelerin belirli bir sırada bulunması ve diğer tüm başlık öğelerinden önce gelmesi gerektiğini gösterir. Gerçekte başlık alanlarının belirli bir sırada bulunması zorunlu değildir. Zorunlu başlık öğeleri benzersiz olmalıdır (tam olarak bir kez bulunmalıdır).

Bu belirtim, çoğu isteğe bağlı alanın birden fazla kez bulunmasına izin verir. Ancak bu tür çoklu kullanımların nasıl yorumlanacağı burada belirtilmemiştir.

<message> ::= <headers>
            | <headers> <crlf> <message-text>

<headers> ::= <required-headers>
            | <required-headers> <optional-headers>

<required-headers> ::= <date-field> <originator>

<originator> ::= <mach-from-field>
               | <mach-from-list> <sender-field>
               | <mach-from-field> <reply-to-field>
               | <any-from-field> <sender-field>
                 <reply-to-field>

<date-field>      ::= "Date" ":" <date-time>
<mach-from-field> ::= "From" ":" <mach-addr-item>
<mach-from-list>  ::= "From" ":" <mach-addr-list>
<any-from-field>  ::= "From" ":" <address-list>
<sender-field>    ::= "Sender" ":" <host-phrase>
<reply-to-field>  ::= "Reply-To" ":" <mach-addr-list>

<optional-headers> ::= <optional-header-field>
                     | <optional-headers>
                       <optional-header-field>

<optional-header-field> ::= <addressee-field>
                          | <extension-field>

<addressee-field> ::= "To"  ":" <address-list>
                    | "cc"  ":" <address-list>
                    | "bcc" ":" <address-list>
                    | "Fcc" ":" <path-list>

<extension-field> ::= "In-Reply-To" ":" <reference-list>
                    | "Keywords"    ":" <phrase-list>
                    | "Message-Id"  ":" <mach-host-phrase>
                    | "References"  ":" <reference-list>
                    | "Subject"     ":" <text-line>
                    | "Comments"    ":" <text-line>
                    | <user-defined-field>

II. İleti Biçimi Standardı

B. Sözdizimi

2. İletiler

<user-defined-field> ::= <bu belirtimde tanımlanmamış
                         bir <field-name>'e sahip bir <field>>

Çeşitli alanların gövdeleri için aşağıdaki sözdizimi, her alan gövdesini tek bir uzun karakter dizisi (veya satır) olarak tanımlıyormuş gibi düşünülmelidir. Sözcüksel Analiz bölümü (Bölüm II.B.1), bu tür uzun dizilerin gerçek iletilen mesaj içinde birden fazla satır üzerinde nasıl gösterilebileceğini belirtmiştir.

3. Genel Alıcı Öğelerinin Sözdizimi

<mach-addr-list> ::= <mach-addr-item>
                   | <mach-addr-item> "," <address-list>

<address-list> ::= <null>
                 | <address-item>
                 | <address-item> "," <address-list>

<address-item> ::= <mach-addr-item>
                 | <group-name> ":" <address-list> ";"
                 | <any-name>
                 | <path>

<mach-addr-item> ::= <mailbox>
                   | <phrase> "<" <mailbox-list> ">"

<group-name> ::= <phrase>
<any-name>   ::= <quoted-string>

<mailbox-list> ::= <mailbox>
                 | <mailbox> "," <mailbox-list>

<mailbox> ::= <host-phrase>

<path> ::= ":" "File" ":" <path-name>

<path-name> ::= <path-item>
              | "<" <path-list> ">"

<path-list> ::= <path-item>
              | <path-item> "," <path-list>

<path-item> ::= <host-phrase>

II. İleti Biçimi Standardı

B. Sözdizimi

4. Destekleyici Yapılar

4. DESTEKLEYİCİ SÖZDİZİMİ

<reference-list> ::= <null>
                   | <reference-item>
                   | <reference-item> "," <reference-list>

<reference-item> ::= <phrase>
                   | <mach-host-phrase>

<mach-host-phrase> ::= "<" <host-phrase> ">"

<host-phrase> ::= <phrase> <host-indicator>

<host-indicator> ::= <at-indicator> <host-name>

<at-indicator> ::= "at" | "@"

<host-name> ::= <atom>
              | <decimal host address>

II. İleti Biçimi Standardı

B. Sözdizimi

4. Destekleyici Yapılar

<date-time>       ::=   <day> <date> <time>

<day>             ::=   <null>
                     |  <day-of-week> ","

<day-of-week>     ::=   "Monday"    | "Mon"
                     |  "Tuesday"   | "Tue"
                     |  "Wednesday" | "Wed"
                     |  "Thursday"  | "Thu"
                     |  "Friday"    | "Fri"
                     |  "Saturday"  | "Sat"
                     |  "Sunday"    | "Sun"

<date>            ::=   <string-date>
                     |  <slash-date>

<string-date>     ::=   <day-of-month> <string-month> <4-digit-year>

<slash-date>      ::=   <numeric-month> "/" <date-of-month> "/" <2-digit-year>

<numeric-month>   ::=   <one or two decimal digits>

<day-of-month>    ::=   <one or two decimal digits>

<string-month>    ::=   "January"   | "Jan"
                     |  "February"  | "Feb"
                     |  "March"     | "Mar"
                     |  "April"     | "Apr"
                     |  "May"
                     |  "June"      | "Jun"
                     |  "July"      | "Jul"
                     |  "August"    | "Aug"
                     |  "September" | "Sep"
                     |  "October"   | "Oct"
                     |  "November"  | "Nov"
                     |  "December"  | "Dec"

<4-digit-year>    ::=   <four decimal digits>

<2-digit-year>    ::=   <two decimal digits>

<time>            ::=   <24-hour-time> "-" <time-zone>

<24-hour-time>    ::=   <hour> <minute>

<hour>            ::=   <two decimal digits>

<minute>          ::=   <two decimal digits>

<time-zone>       ::=   "GMT" | "Z"   | "GDT"
                     |  "AST" | "ADT"
                     |  "EST" | "EDT" | "CST" | "CDT"
                     |  "MST" | "MDT" | "PST" | "PDT"
                     |  "YST" | "YDT" | "HST" | "HDT"

<phrase>          ::=   <word>
                     |  <word> <phrase>

<phrase-list>     ::=   <null>
                     |  <phrase>
                     |  <phrase> "," <phrase-list>

<word>            ::=   <atom>
                     |  <quoted-string>

C. Anlamsal Yapı

1. Adres Alanları

a. Genel

  1. <path> yapıları, ARPANET üzerinde depolanmış bir adres listesini içeren bir konuma başvurmak için kullanılır. <phrase> bölümü, başvurulan ana bilgisayarın bir dosyaya çözümleyebileceği metni içermelidir. Bu standart bir protokol değildir ve bu nedenle verinin dosyadan nasıl alınacağını belirlemez. Bununla birlikte aşağıdaki gereksinimler belirtilmiştir:

Bu mekanizmanın, programların bu tür listeleri otomatik olarak almasına olanak sağlaması amaçlanmıştır.

Bir <path> yapısının yorumlanması aşağıda verilmiştir. Bu açıklama belirli bir uygulama şemasını ima etmek amacıyla değil, <path> kavramının anlaşılmasına yardımcı olmak için dahil edilmiştir:

  1. Bir <mailbox> içindeki <phrase> bölümünün, alıcı FTP sunucusunun izin verdiği her şey olabileceği kabul edilir (örneğin TENEX sistemleri şu anda "P. D. Q. Bach" biçimindeki adresleri anlamaz, ancak başka bir sistem anlayabilir).

Bir <mailbox> kavramsal bir varlıktır ve mutlaka dosya depolamayla ilgili olmak zorunda değildir. Örneğin bazı siteler postayı satır yazıcılarında yazdırmayı ve çıktıyı alıcının masasına ulaştırmayı tercih edebilir.

Bir kullanıcının birden fazla posta kutusu olabilir. <mach-addr-item> için ikinci alternatifin (<phrase> "<" <mailbox-list> ">") kullanılması, iletinin bir kopyasının listelenen her posta kutusuna gönderileceğini belirtir.

  1. <any-name> "word" türünde herhangi bir diziyi içerebilir. <address-item> olarak kullanılan bu sözcük dizisi, standart olmayan (örneğin ağ dışı) adreslere başvuruyu kolaylaştırmak için kullanılır. Böyle bir adres, ABD Posta Servisi tarafından kabul edilen bir adres olabilir.

  2. Bir <host-phrase> içindeki <host-name>, bir Ağ ana bilgisayarının resmi adı olmalıdır veya o ana bilgisayarın ağ adresini gösteren ondalık bir sayı olmalıdır. Sayıların kullanımı güçlü biçimde önerilmez ve yalnızca yerel ana bilgisayar adı tablolarını atlatma gereksiniminin zaman zaman ortaya çıkması nedeniyle izin verilir.

Bir <host-phrase> içindeki <phrase>, yalnızca belirtilen ana bilgisayar için anlamlı olacak şekilde tasarlanmıştır. Diğer tüm ana bilgisayarlar için <phrase> sabit bir karakter dizisi olarak değerlendirilir. <phrase> üzerinde otomatik olarak büyük/küçük harf dönüşümü yapılmamalıdır. <phrase> yerel ana bilgisayarın posta gönderme programına aktarılır; gerekirse bu <phrase> üzerinde harf dönüşümü yaparak postayı teslim etmek, hedef ana bilgisayarın posta alma (dağıtım) programının sorumluluğundadır.

b. Gönderen Alanları

Uyarı: Standart, From, Sender ve Reply-to alanlarıyla mümkün olan tüm kombinasyonların yalnızca bir alt kümesine izin verir. Bu sınırlama bilinçlidir; izin verilen alternatifler dikkatle seçilmiş olup bu standardın amaçları için yeterlidir.

  1. From:

Bu alan, bu iletinin gönderilmesini isteyen kişi(ler)in kimliğini içerir. İleti oluşturma süreci varsayılan olarak bu alanı, iletiyi giren kullanıcıyı gösteren tek bir makine adresi olacak şekilde ayarlamalıdır; yalnızca ve yalnızca bu şekilde yapıldığında "Sender:" alanının bulunması zorunlu değildir.

  1. Sender:

Bu alan, iletinin gönderilmesini gerçekleştiren kişinin kimliğini içerir. Eğer "From:" alanıyla aynıysa mesaj başlığında bulunması zorunlu değildir.

<sender-field-body> bir <phrase> içerir ve bunun standart bir <address-item> yerine bir kullanıcıyı temsil etmesi gerekir; bunun nedeni alanın, postanın gönderilmesinden sorumlu kişiyi belirtmesi beklentisidir ve yalnızca postanın gönderildiği posta kutusunun adını içermesi değildir. Örneğin paylaşılan bir giriş adı durumunda yalnızca adın kendisi yeterli olmaz. <phrase> (kullanıcı) bir sistem varlığıdır, genelleştirilmiş bir kişi referansı değildir.

  1. Reply-to:

Bu alan, yanıtların gönderileceği herhangi bir posta kutusunu belirtmek için genel bir mekanizma sağlar. Bu özelliğin üç farklı kullanım biçimi ayırt edilebilir.

İlk durumda yazar(lar) düzenli makine tabanlı posta kutularına sahip olmayabilir ve bu nedenle alternatif bir makine adresi belirtmek isteyebilir.

İkinci durumda bir yazar, ek kişilerin yanıtların farkında olmasını veya yanıtlar için sorumluluk almasını isteyebilir; yanıt verenler cevaplarını "Reply-to:" posta kutularına göndermelidir.

Daha ilginç bir durum ise metin mesajı tabanlı telekonferans gibi bir yapıdır; burada otomatik bir dağıtım sistemi sağlanır ve dağıtım için bir "girdi" gönderen kullanıcı yalnızca mesajını "Reply-to:" alanında belirtilen posta kutularına göndermek zorundadır.

Eğer <reply-to-field> yoksa <from-field> en az bir makine adresi içermelidir. Kullanıldığı tüm durumlarda ve <sender> alanı mevcut olsa bile Reply-to alanı en az bir makine adresi içermelidir.

Not: Mesajlara verilen yanıtlar için otomatik olarak adres listeleri oluşturan sistemler için aşağıdaki gereksinimler belirtilmiştir:

(Geniş kapsamlı örnekler Bölüm II.D’de verilmiştir.) Bu öneri yalnızca <originator-field> alanları için geçerlidir ve hiçbir şekilde yanıtların bu mesajın diğer alıcılarına da gönderilmemesi gerektiği anlamına gelmez. Ek olanakların sağlanıp sağlanmayacağı ilgili posta işleme programlarına bağlıdır.

c. Alıcı Alanları

  1. To:

Bu alan mesajın birincil alıcılarının kimliğini içerir.

  1. cc:

Bu alan mesajın ikincil alıcılarının kimliğini içerir.

  1. Bcc:

Bu alan, birincil ve ikincil alıcılardan gizli tutulacak ek alıcıların kimliğini içerir. Bazı sistemler "Bcc:" alanının metnini yalnızca yazar(lar)ın kopyasında göstermeyi tercih edebilirken, diğerleri bunu "Bcc:" listesinde belirtilen herkese gönderilen metnin içinde de gösterebilir.

  1. Fcc:

Bu alan, iletinin kopyalarının gönderen tarafından yerleştirildiği herhangi bir mesaj dosyasının kimliğini içerir. Bu alanın bulunmasının, mesajın belirtilen dosyalarda uzun süreli olarak erişilebilir olacağını garanti etmediği unutulmamalıdır.

2. Başvuru Belirtimi Alanları

a. Message-Id

Bu alan, bu mesajın bu sürümüne başvurmak için benzersiz bir tanımlayıcı (<phrase>) içerir. Mesaj tanımlayıcısının benzersizliği her ana bilgisayar tarafından garanti edilir. Bu tanımlayıcının makine tarafından okunabilir olması amaçlanmıştır ve insanlar için mutlaka anlamlı olması gerekmez.

Bir message-id belirli bir mesajın tam olarak tek bir örneğine karşılık gelir; mesaja yapılan sonraki revizyonlar yeni message-id değerleri almalıdır.

b. In-Reply-To

Bu alanın içeriği, bu mesajın yanıt verdiği önceki yazışmayı tanımlar. Eğer bu alanda mesaj tanımlayıcıları kullanılıyorsa, bunlar köşeli ayraçlar (<>) içine alınmalıdır.

c. References

Bu alanın içeriği, bu mesajın referans verdiği diğer yazışmaları tanımlar. Mesaj tanımlayıcıları kullanılıyorsa bunlar köşeli ayraçlar (<>) içine alınmalıdır.

d. Keywords

Bu alan, virgülle ayrılmış anahtar kelimeler veya ifadeler içerir.

3. Diğer Alanlar ve Sözdizimsel Öğeler

a. Subject

"Subject:" alanı, mesajın niteliğini yeterli şekilde özetlemek veya belirtmek için gerekli olan bilgiyi sağlamayı amaçlar.

b. Comments

Mesaj gövdesinin içeriğini bozmadan mesaja metin yorumları eklenmesine izin verir.

4. Tarihler

Uluslararası yorum farklılıkları nedeniyle <day> belirtiminde <slash-day> seçeneği yerine <string-day> seçeneğinin kullanılması önerilir.

Eğer dahil edilmişse <day-of-week>, <date> belirtiminin ima ettiği gün olmalıdır.

<time-zone> değerleri Greenwich'e ve Amerika Birleşik Devletleri'ndeki her zaman dilimine başvuruyu mümkün kılar. "A" ile başlayan zaman dilimi referansları Atlantik saatini ifade eder ve karşılık gelen Doğu saatlerinden bir saat ileridedir. "Y" Alaska’daki Yukon saatini gösterir ve karşılık gelen Pasifik saatlerinden bir saat geridedir; "H" ise Hawaii saatlerini gösterir ve iki saat geridedir.

D. Örnekler

1. Adresler

a. Alfred E. Newman
Newman@BBN-TENEXA

Bu iki "Alfred E. Newman" örneği, yerel ana makinenin posta programının ve uzak ana makinenin FTP sunucusunun çalışması açısından aynı anlamsal içeriğe sahiptir. İlk örnekte, "Newman at BBN-TENEXA" alıcıyı tamamen belirttiği için "Alfred E. Newman" posta programı tarafından yok sayılır. İkinci örnek gereksiz bilgi içermez ve yine "Newman@BBN-TENEXA" hedeflenen alıcıdır.

b. Al Newman at BBN-TENEXA

Bu, "Al Newman " ile aynıdır. Yani tam , "Al Newman", FTP sunucusuna iletilir. Tüm FTP sunucularının çok sözcüklü tanımlayıcıları kabul etmediğini unutmayın; ve bunları kabul eden bazıları da her sözcüğü farklı bir alıcı olarak ele alır (bu durumda "Al" için bir kopya ve "Newman" için bir kopya göndermeye çalışır).

c. "George Lovell, Ted Hackle"

Bu biçim, tek bir posta kutusunun birden fazla kullanıcı tarafından paylaşıldığını belirtmek için kullanılabilir. Tırnak içindeki dize, "Shared-Mailbox at Office-1" hedef posta kutusunu tamamen belirttiği için gönderen ana makinenin posta programı tarafından yok sayılır.

d. Wilt (the Stilt) Chamberlain at NBA

"(the Stilt)" bir yorumdur ve gönderen sistemin posta programına verilen hedef posta kutusu adresine DAHİL EDİLMEZ. Adres, birinci ve ikinci sözcük arasında tam olarak bir boşluk bulunan "Wilt Chamberlain" dizisidir. (Tırnak işaretleri dahil değildir.)

D. Örnekler

2. ADRES LİSTELERİ

Gourmets:  Pompous Person <WhoZiWhatZit at Cordon-Bleu>,
           Cooks:  Childs at WGBH, Galloping Gourmet at
                   ANT (Australian National Television);
           Wine Lovers:  Drunk at Discount-Liquors,
                         Port at Portugal;;,
Jones at SEA

Bu grup listesi örneği, yorumların kullanımını, grupların iç içe yerleştirilmesini ve adresler ile grupların birlikte kullanılmasını gösterir. "Jones at SEA" ifadesinden önce gelen iki ardışık noktalı virgülün, Jones'un Gourmets grubunun bir üyesi OLMADIĞI anlamına geldiğine dikkat edin.

3. GÖNDEREN ÖĞELERİ

a.

George Jones, kendi Host sistemine "Jones" olarak giriş yapar. Postayı kendisi gönderir.

From:  Jones at Host

veya

From:  George Jones <Jones at Host>

b.

George Jones kendi Host sisteminde Jones olarak giriş yapar. Kendi sisteminde (SHost) Secy olarak giriş yapan sekreteri onun adına posta gönderir. Postaya verilecek yanıtların elbette George'a gitmesi gerekir.

From:    George Jones <Jones at Host>
Sender:  Secy at SHost

c.

George Jones Host üzerinde Group olarak giriş yapar. Postayı kendisi gönderir; yanıtlar Group posta kutusuna gitmelidir.

From:  George Jones <Group at Host>

d.

George Jones'un sekreteri, Host üzerinde Secy olarak giriş yapmış durumdayken, George adına ve Group üyesi sıfatıyla posta gönderir. Yanıtlar Group'a gitmelidir.

From:   George Jones<Group at Host>
Sender: Secy at Host

"Jones" ile "<" arasında boşluk bulunmasının zorunlu olmadığını, ancak diğer örneklerde olduğu gibi boşluk eklemenin okunabilirliği artırdığını unutmayın.

e.

George Jones, sekreterinden (Secy at Host) Group sıfatıyla kendisi adına bir mesaj göndermesini ister. Tüm yanıtların sekreteri tarafından ele alınmasını ister.

From:     George Jones <Group at Host>
Sender:   Secy at Host
Reply-to: Secy at Host

f.

George'un ARPANET kullanıcısı olmayan arkadaşı Sarah ziyarete gelmiştir. George'un sekreteri, Sarah'ın bilgisayar dünyasındaki bir arkadaşına posta gönderir. Yanıtlar, posta kutusu Jones at Host olan George'a gitmelidir.

From:     Sarah Friendly
Sender:   Secy at Host
Reply-to: Jones at Host

g.

George bir komitenin üyesidir. Mesajına verilecek yanıtların tüm komite üyelerine gitmesini ister.

From:     George Jones
Sender:   Jones at Host
Reply-To: Big-committee: Jones at Host,
                         Smith at Other-Host,
                         Doe at Somewhere-Else;

George, Big-committee listesinin içinde kendisini belirtmemiş olsaydı bir yanıt alamayacağını unutmayın; "Reply-to:" alanının varlığı, "From:" alanında belirtilen kişiye yanıt gönderilmesini GEÇERSİZ KILAR.

h. (YANLIŞ KULLANIM Örneği)

George, yanıtın sekreterine gitmesini ister; bu nedenle sekreteri "From:" alanından onun posta kutusu adresini çıkarır ve yalnızca adını bırakır. Ancak bu adın kendisi bir posta kutusu adresi değildir.

From:   George Jones
Sender: Secy at SHost

BUNA İZİN VERİLMEZ. Yanıtlar hiçbir zaman örtük olarak "Sender:" adresine gönderilmez; George'un sekreteri "Reply-to:" alanını kullanmalıydı ya da kullandığı posta oluşturma programı onu buna zorlamalıydı.

i.

George'un sekreteri, "Big-committee" üyelerinin tamamı tarafından ortaklaşa yazılmış bir mesaj gönderir.

From:   Big-committee: Jones at Host,
                       Smith at Other-Host,
                       Doe at Somewhere-Else;
Sender: Secy at SHost

4. TAM BAŞLIKLAR

a. Gerekli en az alan

Date:  26 August 1976 1429-EDT
From:  Jones at Host

b. Ek alanların bazılarını kullanarak

Date:       26 August 1976 1430-EDT
From:       George Jones <Group at Host>
Sender:     Secy at SHOST
To:         Al Newman at Mad-Host,
            Sam Irving at Other-Host
Message-id: some string at SHOST

c. Karşılaşabileceğiniz kadar karmaşık bir örnek

Date:        27 Aug 1976 0932-PDT
From:        Ken Davis <KDavis at Other-Host>
Sender:      KSecy at Other-Host
Reply-to:    Sam Irving at Other-Host
Subject:     Re: RFC içindeki Sözdizimi
To:          George Jones <Group at Host>,
             Al Newman at Mad-Host
cc:          Tom Softwood <Balsa at Another-Host>,
             Sam Irving at Other-Host,
             Standard Distribution:
              :File:
                </main/davis/people/standard at Other Host,
                "<Jones>standard.dist.3" at Tops-20-Host>
In-Reply-to: <some string at SHOST>
Message-ID:  4231.629.XYzi-What at Other-Host
Comment:     Sam iş seyahatinde. Bugün onun postalarını
             benim yönetmemi istedi. Yarın döndüğünde
             daha doğru bir açıklama sağlayabilecektir.

III. KAYNAKLAR

APPENDIX

A. Sözdizimi Kurallarının Alfabetik Listesi

<2-digit-year>      ::= <iki ondalık basamak>
<4-digit-year>      ::= <dört ondalık basamak>
<24-hour-time>      ::= <hour> <minute>

<addressee-field>   ::= "To"  ":" <address-list>
                      | "cc"  ":" <address-list>
                      | "bcc" ":" <address-list>
                      | "Fcc" ":" <path-list>

<address-item>      ::= <mach-addr-item>
                      | <group-name> ":" <address-list> ";"
                      | <any-name>
                      | <path>

<address-list>      ::= <null>
                      | <address-item>
                      | <address-item> "," <address-list>

<any-from-field>    ::= "From" ":" <address-list>

<any-name>          ::= <quoted-string>

<at-indicator>      ::= "at" | "@"

<atom>              ::= <bir veya daha fazla TELNET ASCII
                        alfanümerik ya da grafik karakterden
                        oluşan bir dizi; kontrol karakterleri
                        (ondalık değeri 33'ten küçük olanlar
                        veya 127 olan) ve <delimiters> hariç>

<comment>           ::= "(" <crlf> dışındaki TELNET ASCII
                        karakterleri ")"

<cr>                ::= <TELNET ASCII carriage return (ondalık 13)>
<crlf>              ::= <TELNET ASCII carriage return/line feed
                        (ondalık 13 ardından ondalık 10)>

<date>              ::= <string-date> | <slash-date>
<date-field>        ::= "Date" ":" <date-time>
<date-time>         ::= <day> <date> <time>

<day>               ::= <null> | <day-of-week> ","

<day-of-month>      ::= <bir veya iki ondalık basamak>

<day-of-week>       ::= "Monday" | "Mon"
                      | "Tuesday" | "Tue"
                      | "Wednesday" | "Wed"
                      | "Thursday" | "Thu"
                      | "Friday" | "Fri"
                      | "Saturday" | "Sat"
                      | "Sunday" | "Sun"

<delimiter>         ::= <specials>
                      | <comment>
                      | <linear-white-space>
                      | <crlf>

<field>             ::= <field-name> ":" <field-body>

<field-body>        ::= <field-body-contents>
                      | <field-body-contents> <crlf>
                        <linear-white-space-CHAR> <field-body>

<field-body-contents> ::= <alan gövdesini oluşturan TELNET ASCII
                          karakterlerinden oluşan dizi; <atom>,
                          <quoted-string>, <text-line>
                          ve <specials> birleşimlerinden oluşur>

<field-name>        ::= <atom> | <atom> <field-name>

<group-name>        ::= <phrase>

<headers>           ::= <required-headers>
                      | <required-headers> <optional-headers>

<host-indicator>    ::= <at-indicator> <host-name>

<host-name>         ::= <atom> | <ondalık ana makine adresi>

<host-phrase>       ::= <phrase> <host-indicator>

<hour>              ::= <iki ondalık basamak>

<lf>                ::= <TELNET ASCII line feed (ondalık 10)>

<linear-white-space> ::= <linear-white-space-char>
                       | <linear-white-space-char>
                         <linear-white-space>

<linear-white-space-char> ::= <space> | <horizontal-tab>

<mach-addr-item>    ::= <mailbox>
                      | <phrase> "<" <mailbox-list> ">"

<mach-addr-list>    ::= <mach-addr-item>
                      | <mach-addr-item> "," <address-list>

<mach-from-field>   ::= "From" ":" <mach-addr-item>

<mach-from-list>    ::= "From" ":" <mach-addr-list>

<mach-host-phrase>  ::= "<" <host-phrase> ">"

<mailbox>           ::= <host-phrase>

<mailbox-list>      ::= <mailbox>
                      | <mailbox> "," <mailbox-list>

<message>           ::= <headers>
                      | <headers> <crlf> <message-text>

<message-text>      ::= <sıfır veya daha fazla TELNET ASCII
                        karakterinden oluşan dizi>

<minute>            ::= <iki ondalık basamak>

<numeric-month>     ::= <bir veya iki ondalık basamak>

<optional-headers>  ::= <optional-header-field>
                      | <optional-headers> <optional-header-field>

<optional-header-field> ::= <addressee-field> | <extension-field>

<originator>      ::=   <mach-from-field>
                      | <mach-from-list> <sender-field>
                      | <mach-from-field> <reply-to-field>
                      | <any-from-field> <sender-field>
                           <reply-to-field>

<path>            ::=   ":" "File" ":" <path-name>
<path-item>       ::=   <host-phrase>
<path-list>       ::=   <path-item> | <path-item> "," <path-list>
<path-name>       ::=   <path-item> | "<" <path-list> ">"

<phrase>          ::=   <word> | <word> <phrase>
<phrase-list>     ::=   <null> | <phrase>
                      | <phrase> "," <phrase-list>

<reference-item>  ::=   <phrase> | <mach-host-phrase>
<reference-list>  ::=   <null> | <reference-item>
                      | <reference-item> "," <reference-list>

<quoted-string>   ::=   <çift tırnak işareti ("), ondalık 34>
                           <bir veya daha fazla TELNET ASCII
                           karakterinden oluşan dizi; iki
                           bitişik tırnak tek bir tırnak
                           olarak değerlendirilir ve dizinin
                           parçası sayılır> <"">

<reply-to-field>  ::=   "Reply-To" ":" <mach-addr-list>

<required-headers> ::=  <date-field> <originator>

<sender-field>    ::=   "Sender" ":" <host-phrase>

<slash-date>      ::=   <numeric-month> "/" <date-of-month>
                                        "/" <2-digit-year>
<space>           ::=   <TELNET ASCII space (ondalık 32)>

<specials>        ::=   "(" | ")" | "<" | ">"
                      | "@" | "," | ";" | ":" | <"">

<string-date>     ::=   <day-of-month> <string-month>
<string-month>    ::=   "January"   | "Jan" | "February" | "Feb"

## Appendix

### Sözdizimi Kurallarının Alfabetik Listesi

                      | "March"     | "Mar" | "April"     | "Apr"
                      | "May"               | "June"      | "Jun"
                      | "July"      | "Jul" | "August"    | "Aug"
                      | "September" | "Sep" | "October"   | "Oct"
                      | "November"  | "Nov" | "December"  | "Dec"

<tab>             ::=   <TELNET ASCII tab (ondalık 9)>

<text-line>       ::=   <cr> ve <lf> hariç bir veya daha fazla
                           TELNET ASCII karakterinden oluşan dizi>

<time>            ::=   <24-hour-time> "-" <time-zone>
<time-zone>       ::=   "GMT" | "Z"   | "GDT" | "AST" | "ADT"
                      | "EST" | "EDT" | "CST" | "CDT"
                      | "MST" | "MDT" | "PST" | "PDT"
                      | "YST" | "YDT" | "HST" | "HDT"

<user-defined-field> ::= <bu belirtimde tanımlanmamış
                           bir <field-name> içeren bir <field>>

<word>            ::=   <atom> | <quoted-string>