Maildir | |
---|---|
Tyyppi | Sähköpostiarkisto |
Kehittäjä | Daniel J. Bernstein |
Ensimmäinen painos | 2000 [1] |
Maildir on yleinen sähköpostin tallennusmuoto, joka ei vaadi yksinomaista tiedostojen kaappausta postilaatikon eheyden varmistamiseksi, kun viestejä luetaan, lisätään tai muokataan. Jokainen viesti on tallennettu erilliseen tiedostoon , jolla on yksilöllinen nimi, ja jokainen kansio on . Paikallinen tiedostojärjestelmä hoitaa tiedostojen lukituksen tiedostoja lisättäessä, siirrettäessä ja poistettaessa . Kaikki muutokset tehdään atomitiedostooperaatioilla, joten yksinomainen tiedostojen kaappaus ei ole mitenkään välttämätöntä.
Maildir - hakemistossaMaildir (usein nimeltään ) on yleensä kolme alihakemistoa: tmp, newja cur.
Alkuperäisen Maildirin muotomäärityksen on kirjoittanut Daniel Bernstein( Daniel J. Bernstein ), qmailin , djbdns :n ja muiden ohjelmien [2] kirjoittaja . Vaikka alkuperäinen määrittely on kirjoittajan kirjoittama erityisesti hänen qmail -ohjelmaansa varten, se on luonteeltaan melko yleinen, joten se voidaan toteuttaa monissa ohjelmissa.
Sam Varshavchik, Courier Mail Serverin ja muiden ohjelmien kirjoittaja, kirjoitti Maildir-muodon laajennuksen [3] nimeltä Maildir++ alikansioiden ja postikiintiöiden tukemiseksi. Maildir++-hakemistot sisältävät alihakemistoja, joiden nimet alkavat pisteellä ("."), jotka ovat myös Maildir++-kansioita. Tämä laajennus tässä suhteessa rikkoo Maildirin määrittelyä, joka tarjoaa kattavan luettelon Maildirin mahdollisesta sisällöstä, mutta tämä on yhteensopiva poikkeama ja muut Maildiria tukevat ohjelmistot tukevat myös Maildir++:aa.
Kun viesti toimitetaan, se sijoitetaan tiedostoon alihakemistoon tmp(esimerkiksi postfix SMTP -palvelimen toimesta ) . Tiedostonimi muodostuu nykyisestä ajasta, isäntänimestä, tämän tiedoston luoneen prosessin tunnuksesta ja jostain satunnaisluvusta - näin tiedostonimien ainutlaatuisuus taataan.
Kun koko viesti on kirjoitettu tiedostoon, hakemistoon luodaan yleensä kova linkki kyseiseen tiedostoon newja nykyinen linkki tmppoistetaan, mutta joissain toteutuksissa käytetään yksinkertaisesti järjestelmäkutsua rename()- kaikki tämä tehdään niin, että mikään muu prosessi ei voi lue viestin sisältö siihen asti , kunnes se on kokonaan kirjoitettu, koska MUA :t eivät koskaan katso tmp.
Kun sähköpostiohjelma löytää viestejä hakemistosta new, se siirtää ne hakemistoon cur(käyttäen rename(), koska kiinteiden linkkien käyttö voi tässä tapauksessa johtaa päällekkäisiin viesteihin) ja liittää niiden nimiin informatiiviset jälkiliitteet ennen tiedostojen lukemista. Tiedottava jälkiliite koostuu kaksoispisteestä (joka erottaa tiedostonimen yksilöllisen osan nykyisestä tiedosta), numerosta '2', pilusta ja erilaisista lipuista . Numero 2 tarkoittaa karkeasti sanottuna desimaalipilkun jälkeistä versiota. "2" on tällä hetkellä ainoa virallisesti määritelty versio. "1" viittaa kokeelliseen versioon. Voimme vain olettaa, että tätä versionumeroa käytettiin Maildir-muodon kehittämisen aikana. Määritykset määrittelevät liput, jotka osoittavat, onko viesti luettu, poistettu ja niin edelleen käyttämällä seuraavien sanojen ensimmäisiä (isoja) kirjaimia: Hyväksytty, Vastattu, Nähty, Roskakori, Luonnos ja Merkitty [2] . Dovecot käyttää pieniä (pieniä) kirjaimia vastaamaan 26 IMAP-avainsanaa [4] , jotka voivat sisältää sekä vakioavainsanoja, kuten $ MDNSent , että käyttäjän määrittämiä lippuja.
Daniel J. Bernstein suunnitteli Maildirin, jotta useat prosessit voivat kirjoittaa turvallisesti rinnakkain ilman nimenomaista lukitusta ja jopa NFS:ää käytettäessä. Käytännössä tämä toimii melko hyvin, mutta voi johtaa kummallisuuksiin. Kun luet hakemistorakennetta, tiedostot, jotka on nimetty uudelleen ensimmäisen ja viimeisen järjestelmäkutsun välillä, readdir()eivät välttämättä näy tiedostoluettelossa. Tämä saa lukijaprosessin uskomaan, että viesti on poistettu, vaikka itse asiassa vain sen liput ovat muuttuneet. Kun prosessi lukee viestiluettelon uudelleen, yhtäkkiä "poistettu" -viesti tulee uudelleen näkyviin. Tämän tyyppisen ongelman poistamiseksi jotkin sähköpostiohjelmat ottavat käyttöön omat lukkonsa Maildirin päälle. Esimerkiksi Dovecot käyttää omaa ei-standardista lukitusjärjestelmäänsä Maildirin kanssa.
Tiedostojärjestelmä käyttää implisiittisiä lukkoja hakemistoja päivittäessään. Ei-klusteroidut tiedostojärjestelmät sallivat yleensä vain yhden ydinsäikeen suorituksen kerrallaan päivittääkseen tietoja hakemiston sisällöstä, joten järjestelmäkutsu rename()tarjoaa tarvittavan lukituksen. Maildir ei ole lukitsematon järjestelmä, vain eksplisiittisesti lukitsematon järjestelmä. Monissa pienissä ja keskikokoisissa postijärjestelmissä tämä skaalautuu riittävästi jopa NFS:ssä, mutta kun järjestelmä kasvaa suureksi ja käsittelee useita samanaikaisia toimituksia, useiden hakemistojen sisällön jatkuva muuttaminen samanaikaisesti mitätöi välimuistitiedot (välimuistin mitätöinti). erilaisia NFS-asiakkaita, joten etämenettelykutsut (RPC) on suoritettava uudelleen READDIR , joka ei skaalaudu hyvin. Lisäksi monissa tiedostojärjestelmissä on rajoituksia tiedostojen lukumäärälle hakemistoa kohden.
Maildir kärsii siis kaikkien "yksi kirje, yksi tiedosto" -periaatteelle rakennettujen postin tallennusjärjestelmien vanhoista skaalausrajoituksista.
Maildir-standardia ei voida toteuttaa ilman muutoksia järjestelmissä, jotka eivät tue kaksoispisteitä tiedostonimissa. Tämä sisältää Microsoft Windowsin ja jotkin Novell Storage Services - kokoonpanot .
Tällaisissa järjestelmissä toimivat ohjelmat voivat käyttää vaihtoehtoista erotinta (kuten ";" tai "-"), ja sen käyttämiseksi riittää usein ohjelman korjaaminen yksinkertaisella korjaustiedostolla [5] sikäli kuin ilmaisissa ja avoimen lähdekoodin ohjelmistoissa . on huolissaan .
Koska tällä hetkellä ei ole sopimusta siitä, mitä merkkiä käytetään vaihtoehtoisessa erottimessa, tällaisissa järjestelmissä voi esiintyä yhteentoimivuusongelmia eri Maildiria tukevien ohjelmien välillä. Mutta kaikkien Maildirin kanssa toimivien ohjelmien ei tarvitse tietää, mitä erotinta käytetään, koska kaikkien ohjelmien ei tarvitse pystyä lukemaan tai muokkaamaan viestilippuja ("lukea", "vastattu" jne.). Ohjelmien, jotka on suunniteltu toimittamaan postia vain Maildiriin, tai ohjelmilla, jotka arkistoivat sieltä vanhoja viestejä vain niiden päivämäärän perusteella, ei pitäisi olla ongelmia käytetystä erottimesta riippumatta. Jos vain sähköpostiohjelman tarvitsee lukea ja muuttaa viestilippuja ja jos käytetään vain yhtä tällaista asiakasta, vuorovaikutusongelmia ei esiinny käytettäessä ei-standardista erotinta.
Maildirin kanssa käytettävien ohjelmien määrä on itse asiassa paljon suurempi, kun otetaan huomioon näiden ohjelmien vuorovaikutus keskenään ja verkkoyhteyskäytäntöjen rooli.
Esimerkiksi: