Az alkalmazói protokollok szerkezetének jobb átlátása végett álljon itt az SMTP (Simple Mail Transfer Protocol - egyszerű levéltovábbítási protokoll), azaz a levelezést megvalósító protokoll egy példája. Tegyük fel, hogy a TOPAZ.RUTGERS.EDU nevű számítógép szeretné az alábbi üzenetet elküldeni.
Date: Sat, 27 Jun 87 13:26:31 EDT From: hedrick@topaz.rutgers.edu To: levy@red.rutgers.edu Subject: meeting Let's get together Monday at 1pm.Az üzenet formátumát egy Internet szabvány (RFC 822) írja le. A szabványban megfogalmazódik, hogy az üzenetet ASCII karakterekként kell továbbítani. Az üzenet szerkezetének az alábbiak szerint kell kinéznie: fejléc sorok, aztán egy üres sor, majd az üzenet szövege következik. Végül a fejléc sorok szintaxisát definiálja részletesen: általában egy kulcsszó, majd egy érték.
A fenti üzenet címzettje LEVY@RED.RUTGERS.EDU. Kezdetben ez úgy nézett ki, hogy csak a címzett nevét és a gépet írták bele: ,,személy és gép''. A szabványok fejlődése azonban ezt sokkal rugalmasabbá tette. Ma már más rendszerek üzeneteinek a kezelésére is vannak előírások (ami persze ,,magától értetődő''). Ezzel lehetővé válik az Internetbe be nem kapcsolt gépek miatti automatikus átirányítás (forwarding): például az üzenetek egy sor rendszer számára egy központi (mail server) géphez kerülnek. Egyáltalán nem szükséges tehát, hogy létezzen a RED.RUTGERS.EDU névvel jelölt számítógép. A névkiszolgálókat úgy is be lehet állítani, hogy az üzenetek címzettet jelentő mezőjébe tanszékeket írunk, és minden egyes tanszék üzeneteit egy megfelelő számítógéphez irányítjuk. Az is lehetséges, hogy a @ jel előtti részbe ne egy felhasználónak a nevét írjuk, hanem valami mást. Egyes programokat fel lehet készíteni az üzenetek feldolgozására. A levelezési listák, illetve az olyan általános nevek, mint ,,postmaster'' vagy ,,operator'' kezelésére is felkészült a rendszer.
Az üzenet küldésének módját az RFC 821 és 974 dokumentumok tárgyalják. A küldést végző program párszor lekérdezi a névkiszolgálót, hogy meghatározza a célállomást. Az első lekérdezés alkalmával arról tájékozódik, hogy mely gépek kezelik a RED.RUTGERS.EDU gépnek szóló leveleket. Ebben az esetben a kiszolgáló válasza, hogy a RED.RUTGERS.EDU saját maga kezeli az üzeneteit. Ez után a program a RED.RUTGERS.EDU címét kéri le, ami 128.6.4.2. Ezek után a levelező program egy TCP kapcsolatot nyit meg a 128.6.4.2 gép 25-ös portjára. A 25-ös port a leveleket fogadó foglalatnak felel meg. Miután a kapcsolat létrejött, a levelező program megkezdi a parancsok küldését. Az alábbiakban álljon itt egy tipikus kommunikáció. A sorok előtt az szerepel, hogy az a TOPAZ vagy a RED nevű géptől származik-e. A példában TOPAZ kezdeményezte a kapcsolatot:
RED 220 RED.RUTGERS.EDU SMTP Service at 29 Jun 87 05:17:18 EDT TOPAZ HELO topaz.rutgers.edu RED 250 RED.RUTGERS.EDU - Hello, TOPAZ.RUTGERS.EDU TOPAZ MAIL From: <hedrick@topaz.rutgers.edu> RED 250 MAIL accepted TOPAZ RCPT To: <levy.red.rutgers.edu> RED 250 Recipient accepted TOPAZ DATA RED 354 Start mail input; end with <CRLF>.<CRLF> TOPAZ Date: Sat, 27 Jun 87 13:26:31 EDT TOPAZ From: hedrick@topaz.rutgers.edu TOPAZ To: levy@red.rutgers.edu TOPAZ Subject: meeting TOPAZ TOPAZ Let's get together Monday at 1pm. TOPAZ . RED 250 OK TOPAZ QUIT RED 221 RED.RUTGERS.EDU Service closing transmission channelA parancsokban mindenütt normál szöveg szerepel: ez az Internet szabványokra tipikusan jellemző. A protokollok többsége szabványos ASCII parancsokat használ, ami arra is jó, hogy követhessük éppen mi történik, és a problémákat diagnosztizálni lehessen. A levelező program például minden ilyen beszélgetést egy állományban naplóz. Ha valami nem a megfelelő módon történik, akkor az állományt elküldhetjük a postmaster-nak. Mivel ez ASCII fomátumú, ezért látni, hogy mi történt. A dolog arra is jó, hogy közvetlenül a levelezést kiszolgáló géppel lépjünk kapcsolatba tesztelés céljából. (Néhány újabb protokoll annyira összetett, hogy ez nem praktikus. A parancsoknak olyan szintaxis felelne meg, amely szintaktikus elemzőt igényelne. Ez azt jelenti, hogy az újabb protokoll esetében a tendencia a bináris formátumok felé mutat. Általában olyan struktúrákról van szó, mint a C vagy a Pascal nyelvek rekordja.) Második észrevételként említjük, hogy a válaszok mindegyike számmal kezdődik: ez is az Internet protokollok jellemző vonása. A megengedett válaszokat a protokollok definiálják. A számok segítségével a felhasználói programok egyértelműen kommunikálhatnak. A válaszok maradék része szöveg, ami a könnyebb olvashatóság miatt szerepel, és nincs semmiféle kihatása a programok működésére. (Habár van egy pont, ahol a protokoll a válasz szövegének egy részét is felhasználja.) Maguk a parancsok arra használatosak, hogy a levelező program a kiszolgálóval közölje azokat az információkat, amelyek az üzenet továbbítása miatt szükségesek. A fenti kiszolgáló az információt az üzenetből is kiolvashatja. Bonyolultabb esetekben azonban ez nem lenne biztonságos. Minden kommunikáció a HELO paranccsal kezdődik, amit a kapcsolatot kezdeményező rendszer nevének kell követnie. Ezek után következik a küldő és a címzett meghatározása. (Lehet több RCPT parancsot is kiadni, ha több címzett van.) Végül maga az üzenet jön. A szöveget olyan sorral fejezzük be, amiben csak egy pont szerepel. (Ha a szövegben is szerepel ilyen sor, akkor a pont megduplázódik.) Miután az üzenet fogadása megtörtént, a küldő másik üzenetet küldhet, vagy befejezheti a kommunikációt, mint ahogy a fenti példában is történt.
A válaszokat jelölő számokat egy minta szerint képezzük. A protokoll definiálja azokat a válaszokat, amelyek egy adott parancsra adhatóak. Amennyiben nem érdekes a válaszok részletes elemzése, akkor elég csak az első számjegyet figyelembe venni. A 2-vel kezdődő válaszok sikeres parancsot jelölnek. A 3-mal kezdődőek esetén további parancsokat vár a kiszolgáló (ld. fent is). A 4 ideiglenes hibát jelez (pl. lemezterület megtelt). Az üzenetet ilyenkor el kell menteni, és később újra kell próbálkozni. Az 5 állandó jellegű hibára utal, például nem létezik a címzett. Az üzenetet egy hibaüzenet kíséretében vissza kell küldeni a feladónak.
(A fejezetben említett protokollokkal kapcsolatban további információt szolgáltat az RFC 821/822 a levelezésről, az RFC 959 az állományátvitelről, és az RFC 854/855 a távoli bejelentkezésről.)