qmail ved NTNU

(Merk: Denne siden har vært essensielt uendret siden februar 2000, så den har kanskje først og fremst historisk interesse? Jeg har bare gjort én endring, nemlig å fjerne en referanse til en epostliste jeg hadde gående en tid. Listen er nedlagt på grunn av manglende interesse.)

Jeg ivrer for at sendmail skal bort fra NTNU, og at vi skal bruke qmail istedet. Nedenfor finner du noen av grunnene til det. Men det er sikkert mange fallgruver på veien, og hensikten med dette dokumentet er å prøve å utforske flest mulig av dem på forhånd.

Hvorfor innføre qmail?

På grunn av sikkerhet, effektivitet og enkel drift. Det blir stadig funnet nye sikkerhetshull i sendmail. Dessuten er sendmail ganske ressurskrevende, fordi den er designet i en tid da epost var mye mer komplisert enn nå. Man hadde adresser på blant andre UUCP-format og DECnet-format å hanskes med. qmail er designet med sikkerhet for øye. Dessuten håndterer den bare SMTP og Internet-type mailadresser, og er derfor betydelig enklere enn sendmail. Dette gir også øket effektivitet, og enklere konfigurasjon og drift.

Kort oversikt over komponentene i qmail

Hvilke konsekvenser vil det få for brukerne?

qmail leverer direkte til hjemmekatalogen

Default er at qmail leverer til ~/Mailbox. Forutsatt at environmentvariabelen MAIL er satt til å peke hit, vil normale mailprogram kunne lese posten akkurat som før.

De som bruker pop2, pop3 eller imap-klienter skal heller ikke merke noen forskjell.

qmail kan levere på maildirformat

Mbox-formatet har kjente problemer, blant annet ved et systemkrasj midt i en levering, som kan føre til at neste mail henger sammen med sin ufullstendige forgjenger. Leveres posten på maildir-format istedet, kan slike problemer ikke oppstå. Desverre kjenner de færreste (ingen?) MUAer til maildir-formatet. Man kan likevel sy sammen fornuftige løsninger ved hjelp av programmet maildir2mbox.

Hver bruker kontrollerer mange adresser

Post adressert til bruker-foo-bar@blah.ntnu.no blir levert til brukeren med brukernavn bruker og kontrollert av ~bruker/.qmail-foo-bar eller ~bruker/.qmail-default (hvis ingen av dem eksisterer, blir posten bouncet). For eksempel kan brukeren abonnere på forskjellige postlister med forskjellige adresser, og på den måten sortere listepost på en måte som er enkel og koster lite maskinkraft.

Hver bruker kan opprette egne postlister

Det gjelder selvsagt også med sendmail, men blir mye lettere med qmail fordi brukeren kontrollerer flere adresser, og fordi formatet på en .qmail-fil er mye mer generelt enn en .forward-fil. Dessuten følger det med enkel programvare for automatisk av- og påmelding.

Noen vil kanskje hevde at dette kan bli et problem. Det bør nok eksistere en policy for hvor omfattende postlister en bruker kan drive uten å ha spesialtillatelse.

Hva må gjøres av installasjonsarbeid, og hvilke problemer kan vi få?

Nye brukere og grupper

qmail er ekstremt partisjonert av sikkerhetshensyn, og den bruker ikke mindre enn 7 UIDer og 2 GIDer. Disse blir hardkodet i programvaren, som altså må rekompileres om disse endres. Jeg har reservert UID 150-156 og GID 150 og 155, slik:

/etc/passwd:
qmaild:x:150:151::/var/qmail:/sbin/sh
alias:x:151:151::/var/qmail/alias:/sbin/sh
qmailq:x:152:150::/var/qmail:/sbin/sh
qmailr:x:153:150::/var/qmail:/sbin/sh
qmails:x:154:150::/var/qmail:/sbin/sh
qmaill:x:155:151::/var/qmail:/sbin/sh
qmailp:x:156:151::/var/qmail:/sbin/sh
/etc/group:
qmail::150:
nofiles::151:
      

Dotlocking

All epost-programvare ved NTNU er så langt det er mulig konfigurert for å bruke dotlocking, og bare det, på mbox-filer. qmail bruker flock/lockf istedet. Jeg har laget en patch som får qmail til å bruke dotlocking istedet (patchen og et start/stopp-skript er tilgjengelig fra WWW).

Levering i hjemmekatalog

Jeg tror vi bør unngå forsøk på å levere post over NFS så langt det er mulig. Et kjent problem med NFS er at dersom en NFS-server har krasjet, vil gjerne et program som forsøker å aksessere en fil på serveren bli hengende. Detaljene kommer an på hvordan filsystemet er montert, men poenget er at vi risikerer at masser av innkommende post resulterer i like mange hengende prosesser, som kan bli en betydelig belastning på systemet. Vi har sett dette med sendmail og .forward-filer, som er en grunn til at man bruker /var/mail/forward/bruker istedet for ~bruker/.forward blant annet på salene.

En løsning er å fremsende posten til den maskinen som fysisk har hjemmekatalogen og levere den der. (Jeg har en løsning som kanskje er litt for infløkt, men jeg venter at dette blir mye enklere å håndtere i versjon 0.92 av qmail, da control/usermap blir erstattet av en mer generell database for håndtering av lokale adresser. Derfor går jeg ikke i detalj med dette her.)

pop2, pop3, og imap

Levering i hjemmekatalog gjør at man ikke helt uten videre kan bruke pop- og imap-demoner slik de normalt er konfigurert. Det er skrevet en qmail-pop3d som forventer å finne innkommende post på maildir-format i hjemmekatalogen til brukeren. Foreløpig finnes ingen tilsvarende pop2- eller imap-demoner.

De mest vanlig brukte demonene for dette bruket ser ut til å være de som ligger i store-pakken imap (på ernie). Denne er skrevet av Mark Crispin ved University of Washington. I filen imap/src-4.1.ALPHA/src/osdep/unix/env_unix.c finner man denne koden for å finne standard mailbox:

char *sysinbox ()
{
  char tmp[MAILTMPLEN];
  if (!sysInbox) {              /* initialize if first time */
    sprintf (tmp,"%s/%s",MAILSPOOL,myUserName);
    sysInbox = cpystr (tmp);    /* system inbox is from mail spool */
  }
  return sysInbox;
}
      

Hvis vi bytter ut sprintf-linjen med

    sprintf (tmp,"%s/Mailbox",myhomedir());
      

så skulle det antagelig være nok.