| Maildir | |
|---|---|
| Type | E-mail-arkiv |
| Udvikler | Daniel J. Bernstein |
| Første udgave | 2000 [1] |
Maildir er et almindeligt e -mail -lagerformat , der ikke kræver eksklusiv filopsamling for at sikre postkasseintegritet, når du læser, tilføjer eller ændrer meddelelser. Hver besked er gemt i en separat fil med et unikt navn, og hver mappe er en . Fillåsning ved tilføjelse, flytning og sletning af filer håndteres af det lokale filsystem . Alle ændringer er lavet med atomiske filoperationer, så eksklusiv filoptagelse er på ingen måde nødvendig.
Maildir- biblioteketMaildir (ofte kaldet ) har normalt tre undermapper: tmp, newog cur.
Den originale Maildir-formatspecifikation blev skrevet af Daniel Bernstein( Daniel J. Bernstein ), forfatter til qmail , djbdns og andre programmer [2] . Selvom den originale specifikation er skrevet af forfatteren specifikt til hans qmail -program , er den ret generel, så den kan implementeres i mange programmer.
Sam Varshavchik, forfatter til Courier Mail Server og andre programmer, skrev en udvidelse [3] af Maildir-formatet kaldet Maildir++ for at understøtte undermapper og postkvoter. Maildir++ mapperne indeholder undermapper med navne, der begynder med en prik (""."), som også er Maildir++ mapper. Denne udvidelse i denne henseende er en overtrædelse af Maildir-specifikationen, som giver en udtømmende liste over det mulige indhold af Maildir, men dette er en kompatibel afvigelse, og anden software, der understøtter Maildir, understøtter også Maildir++.
Når en besked leveres, placeres den i en fil i en undermappe tmp(f.eks. af postfix SMTP-serveren ) . Filnavnet er dannet ud fra det aktuelle tidspunkt, værtsnavnet, ID'et for den proces, der skabte denne fil, og et tilfældigt tal - på denne måde er det unikke ved filnavne garanteret.
Efter at have skrevet hele beskeden til en fil, oprettes der normalt et hårdt link til den fil i mappen, newog det aktuelle link tmpfjernes fra, men i nogle implementeringer bruges et systemkald rename()- alt dette gøres for at ingen anden proces kan læs indholdet af beskeden indtil da , indtil det er helt skrevet, da MUA'er aldrig kigger på tmp.
Når mail-klienten finder meddelelser i mappen new, flytter den dem til cur(ved at bruge rename(), da brug af hårde links i dette tilfælde kan føre til duplikerede meddelelser) og tilføjer informationssuffikser til deres navne, før de læser filerne. Informationssuffikset består af et kolon (for at adskille den unikke del af filnavnet fra den aktuelle information), tallet '2', et komma og forskellige flag . Tallet '2' angiver groft sagt versionen af informationen efter decimaltegnet. '2' er den eneste officielt definerede version. '1' henviser til den eksperimentelle version. Vi kan kun antage, at dette versionsnummer blev brugt under udviklingen af Maildir-formatet. Specifikationen definerer flag, der angiver, om en meddelelse er blevet læst, slettet og så videre, ved hjælp af de første (store) bogstaver i følgende ord: Bestået, Besvaret, Set, Trashed, Draft og Flagget [2] . Dovecot bruger små bogstaver (små bogstaver) for at matche de 26 IMAP søgeord [4] , som kan omfatte både standard nøgleord såsom $ MDNSent og brugerdefinerede flag.
Daniel J. Bernstein designede Maildir, så flere processer sikkert kan skrive parallelt, uden nogen eksplicit låsning, og endda ved brug af NFS. I praksis fungerer dette ganske godt, men kan føre til særheder. Under læsning af biblioteksstrukturen vises eventuelle filer, der er omdøbt mellem det første og sidste systemkald, readdir()muligvis ikke på fillisten. Dette får læserprocessen til at tro, at beskeden er blevet slettet, mens det faktisk kun er dens flag, der er ændret. Når processen læser listen over beskeder igen, dukker den "slettede" besked pludselig op igen. For at eliminere denne form for problemer introducerer nogle mailadgangsprogrammer deres egne låse oven på Maildir. Dovecot bruger for eksempel sit eget ikke-standard låsesystem sammen med Maildir.
Der er implicitte låse, der bruges af filsystemet ved opdatering af mapper. Ikke-klyngede filsystemer tillader typisk kun én kernetråd af eksekvering på et givet tidspunkt at opdatere data om, hvad der er i en mappe, så et systemkald rename()vil give den nødvendige låsning. Maildir er ikke et låsefrit system, kun eksplicit-låsefrit. For mange små til mellemstore mailsystemer skaleres dette tilstrækkeligt selv på NFS, men når systemet bliver stort og håndterer mange samtidige leveringer, vil konstant ændring af indholdet af mange mapper på samme tid konstant ugyldiggøre cachedataene (cache-invalidering) af forskellige NFS-klienter, så det ville være nødvendigt at genudføre fjernprocedurekald (RPC) READDIR , som ikke skaleres godt. Derudover har mange filsystemer begrænsninger på antallet af filer pr. mappe.
Maildir lider således af de gamle skaleringsbegrænsninger for alle postlagringssystemer bygget på "et bogstav, en fil"-princippet.
Maildir-standarden kan ikke implementeres uden ændringer på systemer, der ikke understøtter koloner i filnavne. Dette inkluderer Microsoft Windows og nogle Novell Storage Services- konfigurationer .
Programmer, der kører på sådanne systemer, kan bruge en alternativ afgrænser (såsom ";" eller "-"), og det er ofte nok at patche programmet med en simpel patch for at bruge det [5] , for så vidt angår gratis og open source-software er bekymret .
Da der i øjeblikket ikke er nogen aftale om, hvilket tegn der skal bruges til den alternative afgrænsning, kan der opstå interoperabilitetsproblemer mellem forskellige programmer, der understøtter Maildir, på sådanne systemer. Men ikke alle programmer, der arbejder med Maildir, behøver at vide, hvilken afgrænsning der bruges, da ikke alle programmer skal kunne læse eller ændre beskedflag ("læst", "besvaret" osv.). Programmer, der kun er designet til at levere e-mail til Maildir, eller programmer til at arkivere gamle meddelelser derfra kun baseret på deres dato, burde ikke have noget problem med at fungere, uanset hvilken afgrænsning der bruges. Hvis det kun er en mailklient , der skal læse og ændre meddelelsesflag , og hvis kun én sådan klient bruges, vil der ikke være nogen interaktionsproblemer ved brug af en ikke-standard separator.
Antallet af programmer, der kan bruges med Maildir, er faktisk meget større, givet disse programmers interaktion med hinanden og rollen som netværksadgangsprotokoller.
For eksempel: