NNTP:n tulevaisuus

31.10.1999

Petri Kujala
S
Teknillinen korkeakoulu
petri.kujala@iki.fi

Tiivistelmä

NNTP on yksi vanhimmista internetin protokollista ja tämän takia se alkaa käydä päivä päivältä ominaisuuksiltaan puuttellisemaksi. Niinpä NNTP:hen onkin puhallettu lisää henkeä erilaisten laajennusten avulla, joiden dokumentteja ei saa mistään kootusti ja ovat yleisesti ottaen järjestelmäkohtaisia.
Kaikkia NNTP:n puutteita ei pystytä kuitenkaan korjaamaan pelkillä laajennuksilla, ei ainakaan järjestelmän viimeistä lenkkiä -- puutteellista loppukäyttäjää.

1 Johdanto

2 Laajentamattoman NNTP:n heikkouksia
    2.1 Lähteen luotettavuus
    2.2 Protokollan heikkous
    2.3 Väärä käyttö

3 Laajennettu NNTP

4 Vaihtoehtoinen ratkaisu

Lähdeluettelo

1 Johdanto

Usenet on ensimmäisiä internetissä olleita palveluita. NNTP on yksi vanhimpia internetin protokollia. Miten nyysit on pärjännyt ajan hampaiden nakerusta vastaan ? Täyttääkö se edelleen tehtävänsä ? Miten se kohtaa uudet haasteet ?

2 Laajentamattoman NNTP:n heikkouksia

2.1 Lähteen luotettavuus

Lähteen luotettavuudella tarkoitan tässä lähinnä väärällä nimellä esiintymisen helppoutta eli ns. "fake mail":ia. Eri nimillä esiintymisessä ei sellaisenaan tehdä kauheasti pahaa, voihan yhdellä ihmisellä olla lempinimiä vaikka millä mitalla. Teko muuttuu paheksuttavaksi vasta sitten, kun väärällä nimellä aletaan jonkun toisen ihmisen puolesta esittää mielipiteitä.
Väärällä nimellä lähtevän viestin teko on helppoa. Tottumaton tietokoneen käyttäjä saattaa tehdä sitä jopa vahingossa, koska hänen uutistenlukuohjelmansa ei tarpeeksi jämäkästi nimeä ja sähköpostiosoitetta vaadi. Toisaalta, jos lukija on kokematon tietokoneen/uutistenlukuohjelmien käyttäjä, niin hänen ei ymmärrä katsoa postin otsikkotietoihin ja varmistaa tiedon lähettäjää. Alkuperäinen NNTP protokolla ei vaadi minkäänlaista allekirjoitusta, joten se ei ota mitenkään kantaa postin lähettäjän oikeellisuuteen.[1]

2.2 Protokollan heikkous

NNTP on alunperin tehty paljon pienempää kuormaa varten, se on suunniteltu aikana jolloin internetin käyttäjiä ei ollut kuin kourallinen verrattuna nykyhetkeen. NNTP:n suunnittelu ajankohtana ei päästy myöskään lähellekään nykyajan tiedonsiirtonopeuksia. Luultavasti näistä edellisisitä seikoista johtuen NNTP:aan on alunperin tehty resursseja hukkaava kyselyrakenne[5]. Esimerkiksi jo kymmenen viestin hakemiseen käytetään monta käskyä, koska jokainen viesti haetaan erikseen asiakaskoneelle. NNTP:stä puuttuu tähän tarkoitukseen sopiva komento.

Tämän lisäksi NNTP:ssä yhteys pysyy päällä myös sillloin kuin käyttäjä ei tee mitään. Tämä syö resursseja melkoisesti. Viisaampaa olisi ehkä hakea käyttäjän haluamat artikkelit ja tämän jälkeen luovuttaa resurssit muille.

Eli yhdistämällä nämä kaksi edellä mainittua asiaa voitaisiin hakea asiakaskoneelle joku tietty määrä viestejä, rajoitettuna esimerkiksi vapaasti määriteltävällä tavumäärällä. Tämän jälkeen yhteys palvelimeen katkaistaan. Luetaan artikkelit... Luodaan uusi yhteys, haetaan lisää dataa.

2.3 Vääränlainen käyttö

Tiedonsiirtonopeksien kasvu antaa mahdollisuuden siirtää postin muutakin kuin pelkkää testiä, mutta tähän ei pitäisi ryhtyä koska ei voida tietää lukeeko joku viestejä 300 baudin modeemin kanssa.

Ylimääräistä liikennettä lisää myös spämmi eli roskapostaus. Tämä on vielä pahempi asia kuin binäärien lähetys, koska se lisää järjetelmän taakkaa alueella jossa se on jo muutenkin heikoilla, kts. kohta 2.2.
Lisäongelmia aiheuttaa se, että usein spämmi on lähetetty siten, että kirjoituksen kopio on lähetetty kuhunkin ryhmään erikseen tai kerrallaan muutamaan ryhmään, ilman crosspostausta. (Tällöin nyysijärjestelmä ei tunnista niitä yhdeksi artikkeliksi, vaan lukiessasi nyysejä näet artikkelin jokaisessa ryhmässä, jota luet.) [4]

3. Laajennettu NNTP

NNTP:tä on laajennettu erilaisilla laajennuksilla, jotka ei kuulu vanhaan standardiin. Laajennuksien johdosta nyky-NNTP on joiltakin osin dokumentoimaton.
Uusilla laajennuksilla voidaan esimerkiksi saada aikaan erilaisia hakutoimintoja, joiden avulla voidaan suorittaa tekstihakuja suoraan nntp-palvelimella.
Tätä asiaa selkeyttämään on tekeillä NNTP:n eli RFC 977 päivitys, josta on jo tehty RFC-vedos[2,3].

Vedoksen mukaan asiakaskoneella on uudessa NNTP:ssä käytössä käsky LIST EXTENSIONS, jolla palvelin palauttaa listan sen osaamista laajennuksista. Näin asiakasohjelma voi heti yhteyden alussa kieltää käyttäjältä sellaiset toiminteet joita serveri ei hyväksy.[2]

Haku on vedoksessa järjestety PAT-komennon avulla. Komento palauttaa ne otsaketiedot, jotka sopivat PAT komennolle annettavaan argumenttiin[2].

Omasta mielestäni vedos voisi ottaa turvallisuusnäkökohtiin kantaa hieman enemmän kuin mainitsemalla lopussa vain, että turvallisuuteen voitaisiin puuttua esimerkiksi uusilla laajennuksilla.
Vedos kertoo myös, että NNTP pitäisi pitää mahdollisimman yksinkertaisena eli lupaa julkisten laajenuksten rakentamiseen saisi vain erittäin painavista syistä.

4. Vaihtoehtoinen ratkaisu, postituslistat

Postistuslistat ovat hyvä vaihtoehtoinen ratkaisu kokonaiselle uutisryhmälle niin kauan kuin postituslista pysyy riittävän pienenä. Postituslistassa jokaisesta lähetystä viestistä lähetään kopio jokaiselle postituslistalle olevalle, joten systeemi on jo pienillä viestimäärillä melko tehoton[3].
Postituslistoille liittyminenkään ei käy aivan yhtä helposti kuin uutisryhmään. Joihinkin postituslista toteutuksiin on kylläkin tehty www-käyttöliittymä, joka tekeekin sen melko toimivaksi.
Ilman www-käyttöliittymää myös postituslistalta poistuminen saattaa aiheuttaa joskus melkoista päänvaivaa, varsinkin jos sattuu käyttämään enemmän kuin yhtä sähköpostiosoitetta. Palvelimet kun yleensä vaativat, että palveluun kirjautuminen ja poistuminen tehdään samalta sähköpostiosoitteelta.

Lähdeluettelo

[1]	Anon, Figuring out fake E-Mail & Posts, 15.9.1999 < http://digital.net/~gandalf/spamfaq.html >
[2]	Barber S, INTERNET DRAFT Network News Transport Protocol, Elokuu 1999 < http://www.ietf.org/internet-drafts/draft-ietf-nntpext-base-08.txt >
[3]	Kantor B & Lapsley P, RFC 977, Helmikuu 1986 < ftp://ftp.funet.fi/rfc/rfc977.txt >
[4]	Korpela J, Nyysiopas, 22.10.1999 < http://www.hut.fi/u/jkorpela/nyysit/opas.html >
[5]	Palme J, How the Usenet News Protocols Work Excerpt from the book Electronic Mail with online revisions, 30.9.1999 < http://www.dsv.su.se/~jpalme/e-mail-book/usenet-news.html >