Copyright © 2000 Eric S. Raymond
Dit document is een introductie in de wereld van elektronische mail (email) onder Linux. Het is gericht op kwesties op gebruikersniveau en typische configuraties voor Linux homecomputers en kleine bedrijven verbonden met het net via een ISP.
Je hebt dit nodig als je van plan bent lokaal of met remote sites te communiceren via elektronische mail. Je hebt dit document waarschijnlijk niet nodig als je geen elektronsche mail uitwisselt met andere gebruikers op je systeem of gebruikers van andere sites.
Zie de Mail Administrator HOWTO voor informatie over het configureren en beheren van mail.
De bedoeling van dit document is de werking van email uit te leggen en een paar vragen te beantwoorden die tegemoet schijnen te komen aan de definitie `frequently asked questions' over e-mailsoftware onder Linux.
Moderne Linux-distributies geven je een bruikbare, voorgeconfigureerde setup voor elektronische mail klaar-voor-gebruik, gewoonlijk met een late versie van sendmail-v8. In deze HOWTO wordt verondersteld dat je een dergelijke setup en een werkende Internet-verbinding hebt.
(Zie de ISP Hookup HOWTO voor informatie over het instellen van een PPP- of SLIP-verbinding naar een ISP.)
Dienovereenkomstig wordt in tegenstelling tot de 1.x versies van Vince Skahan, in deze HOWTO de nadruk gelegd op gebruikerskwesties en architectuur; het technische gedeelte over UUCP, IDA sendmail en en andere voorheen belangrijke onderwerpen zijn komen te vervallen.
Dit document zal maandelijks naar de nieuwsgroep comp.os.linux.answers worden gepost. De laatste versie van deze HOWTO zou ook te bekijken moeten zijn op het World Wide Web op http://metalab.unc.edu/LDP/HOWTO/Mail-User-HOWTO.html.
Er zijn geen specifieke hardwarebenodigdheden voor mail onder Linux. Als je de beschikking hebt over de hardware om een verbinding met Internet te maken, dan kan het e-mail over die verbinding ondersteunen.
De software die je nodig hebt voor de ondersteuning van e-mail is waarschijnlijk in je Linux-distributie voorge�nstalleerd. Updates zijn te vinden in het Metalab Linux Archief, met name in de subdirectory mail.
Deze sectie bevat informatie gerelateerd aan user agents, wat de software is die de gebruiker ziet en gebruikt. Deze software rekent op de transport agents die worden beschreven in de Mail Administrator's HOWTO (waarin ook de configuratie van user-agents is opgenomen en tips voor het oplossen van problemen voor beheerders).
Mail user-agents roepen een editor aan ter ondersteuning bij de samenstelling van mail. Welke editor de standaard is, varieert. De meeste daarvan respecteren een conventie die teruggaat naar de beginjaren van Unix; de inhoud van de omgevingsvariabele VISUAL, als deze voorkomt, wordt aangenomen als de naam van je voorkeurseditor. Er wordt gecontroleerd op de variabele EDITOR als VISUAL niet is ingesteld.
Populaire waarden voor EDITOR zijn onder andere vi en emacs. Maar als je net als ik een type bent die GNU Emacs altijd heeft draaien, dan is de meest bruikbare wijze om EDITOR in te stellen op de waarde emacsclient. Gebruik dit met de volgende regels in je ~/.emacs bestand:
(autoload 'server-edit "server" nil t) (server-edit) |
Het programma emacsclient zal wanneer het wordt uitgevoerd, proberen een communicatie met een Emacs kopie die je reeds hebt draaien tot stand te brengen en het tijdelijke bestand met het e-mailbericht naar die Emacs ter bewerking overhandigen. Het effect hiervan is dat binnen Emacs een mailcompositievenster tevoorschijn komt, zodra je mailer een editor aanroept.
Typ C-x # zodra je zover bent om het bestand ter verzending aan de mailer te overhandigen. De mailbuffer verlaat je display en de kopie van de emacsclient die door je mailer werd aangeroepen, zal terugkeren waarbij het de controle teruggeeft aan de mailer.
Het is mogelijk meer dan ��n kopie van de emacsclient tegelijkertijd open te hebben zonder dat Emacs hiervan in de war raakt. Echter een andere Emacs aanroepen terwijl een sessie van een emacslient van de kopie�n meer terugvindt. Sluit alle kopie�n van Emacs af en herstart er slechts ��n als dit gebeurt.
Als je XEmacs draait in plaats van GNU Emacs, dan wijzigen deze aanwijzigingen iets. In dit geval wil je EDITOR instellen op gnuclient. In recente versies is je init bestand ~/.xemacs/init.el in plaats van ~/.emacs.
Dit gebruik ik en ik kan het je aanbevelen. Het is afgeleid van elm en het heeft standaard vergelijkbare opdrachten, maar het is veel krachtiger en beter configureerbaar. Het kan een POP3- of IMAP-client zijn, en er is uitstekende ondersteuning voor MIME en PGP in opgenomen. Er is een Mutt homepage op het web.
Mutt respecteert de EDITOR/VISUAL conventie.
Elm was de eerste schermge�rie�nteerde Unix-mailer, maar de ontwikkeling ervan staat nu al jaren stil en het is vervangen door Mutt. Een aantal versies van elm heeft ingebouwde POP3 ondersteuning. Zie de elk bronnen en installatie-instructies in de Metalab mail user agents directory voor meer informatie. Hier zijn een paar punten waar mensen zo nu en dan eens over struikelen:
Nee, elm kan niets met PGP. Er zijn patches beschikbaar voor de ondersteuning van PGP, maar de PGP ondersteuning van Mutt is superieur. Ik raad je Mutt aan als je gebruik wilt maken van PGP.
Elm respecteert de EDITOR/VISUAL conventie.
Pine is een user agent ontworpen voor beginnelingen; mogelijkheden die zijn opgenomen zijn het lezen van nieuws en ingebouwde ondersteuning van het IMAP remote-mail protocol. Veel mensen zweren erbij voor nieuwe gebruikers. Ik vind de magere opdrachtenset, beperkte configureerbaarheid en eigen editor moeilijk te slikken. Het biedt echter een uitstekende ingebouwde ondersteuning voor IMAP. Wil je het eens bekijken, de distributie is beschikbaar op http://www.washington.edu/pine.
Pine respecteert de EDITOR/VISUAL conventie.
De Netscape browser heeft ingebouwde POP3 en IMAP remote-mail bekwaamheden, dus kan het worden gebruikt als een mail user agent. Ik beveel dit niet aan; het is niet gespecialiseerd in een MUA, en het biedt daarom niet veel van de services die echte MUA's bieden (zoals aliassen en de afhandeling van PGP). Het ondersteunt echter wel LDAP en SSL.
Netscape levert een eigen mini-editor, dezelfde die wordt gebruikt als voor de browser (b.v. voor tekstvelden in formulieren).
Emacs heeft een modus genaamd smail waarmee mail kan worden verstuurd, en een ander genaamd rmail waarmee mail kan worden gelezen. De smail modus kan nogal handig zijn, aangezien je er mail binnen een volledige Emacs omgeving mee kunt samenstellen (maar zie ook de bespreking van de emacsclient elders in dit document).
De rmail modus, aan de andere kant, is niet aan te bevelen. Elke keer dat je het uitvoert, converteert het je inbox naar het BABYL formaat; gewone mail-tools zullen zich daarin verslikken. (Geef de opdracht M-x unrmail vanaf de Emacs opdrachtregel als je dit overkomt).
Er is een mailreader voor emacs genaamd `vm' die standaard V7 mailboxen schrijft en inleest. Het wordt niet met GNU Emacs gedistribueerd, maar de homepage ervan is te vinden op http://www.wonderworks.com/vm/.
De meest populaire mailreader voor emacs is waarschijnlijk GNUS, die met GNU Emacs wordt gedistribueerd. Het is een client voor USENET news als ook mail.
Emacs smail/rmail/vm respecteert de EDITOR/VISUAL conventie niet. In plaats daarvan gebruik je de Emacs die ze hebben ingesloten.
Als je simpelweg `mail' in de shell intikt onder Linux of enige andere moderne Unix, dan zal je daarmee een variant van het BSD Mail programma aanroepen. Het heeft een regelge�ri�nteerde interface die oorspronkelijk werd ontworpen voor gebruik op TTY's. Het is in die zin slechts van historisch belang.
BSD Mail vond de EDITOR/VISUAL conventie uit.
Van de volgende programma's is ook bekend dat ze onder Linux draaien. Raadpleeg `archie' om ze op te sporen...
mail user's shell, zeer krachtig voor filteren en batchverwerking.
mail handler, nog een andere mail user agent
Ik weet niet genoeg over mh of mush om ze hier in detail te kunnen beschrijven. Ze hebben beiden een nogal complexe interface en zijn ontworpen voor vergevorderde mailgebruikers.
Een `alias' is een manier om een pseudo-adres in te stellen dat mail simpelweg doorstuurt naar een ander (enkel) adres. Er bestaan twee soorten aliassen: MUA aliassen en MTA aliassen.
Een MUA alias is een alias die je instelt in je MUA als een soort persoonlijke afkorting. Andere mensen zullen deze alias niet kunnen zien of gebruiken. Je zou bijvoorbeeld:
alias esr Eric S. Raymond <[email protected]> |
in het configuratiebestand van mutt kunnen schrijven. Wanneer mutt nu `esr' in een adresregel tegenkomt, zou het zich gedragen alsof je `[email protected]' had ingetikt. Of je kunt `mutt esr' intikken met als resultaat dat het ge�xtraheerde adres automatisch zal worden ingevuld op de `to' regel.
Een MTA alias is een alias die je MTA extraheert; het zal door iedereen te gebruiken zijn, zowel op je machine als remote. Voor het aanmaken van MTA-aliassen, moet je een systeembestand aanpassen, wat gewoonlijk maar niet altijd /etc/aliases of /etc/mail/aliases is (de lokatie is afhankelijk van je MTA). Wellicht dat het instructief is door de aliassen op je systeem te bekijken; er zouden een aantal standaardaliassen, zoals `postmaster' in moeten staan.
Het kan zijn dat de MTA je tevens de mogelijkheid biedt als doel van een alias een bestandsnaam op te geven, welke zal worden behandeld als een mailbox waaraan de mail wordt toegevoegd (dit is handig voor het archiveren van mail). Wellicht dat het doel van een alias ook een programma kan zijn, in welk geval mail naar dat alias zal worden doorgegeven aan een kopie van het programma als standaardinvoer.
Voor het instellen van MTA aliassen zijn gewoonlijk beheerdersprivileges nodig. Maar voor gebruikers is het wenselijk als ze hun eigen mail zonder tussenkomst van de beheerder kunnen doorsturen.
Ter ondersteuning hiervan, volgen de meeste MTA's sendmail's wijze en zoeken in je homedirectory naar een bestand genaamd .forward. De inhoud van dit bestand wordt ge�nterpreteerd als het doel van een alias welke je mail zou moeten ontvangen. Wat het meest gebruikelijk hiervoor wordt toegepast is het doorsturen van je mail naar een account op een andere machine.
Een ander algemeen gebruik voor de .forward faciliteit is het doorgeven van je mail aan een `vacation' programma. Een vacation programma leest inkomende mail en genereert er automatisch een voorgefabriceerde mail naartoe; ze worden zo genoemd omdat de meest gebruikelijke vorm van voorgefabriceerde beantwoording is de verzender te informeren dat je op vakantie bent en dat je tot een gegeven datum niet bereikbaar bent.
Er zijn geen standaard vacation programma's universeel in gebruik. Hier zijn twee goede redenen voor: ��n, een dergelijk programma is erg makkelijk te schrijven als een shellscript of filter rule (zie verderop); en twee, vacation programma's werken slecht samen met mailinglijsten.
Je zou je tijdelijk van alle mailinglijsten uit moeten schrijven voordat je instelt op automatische beantwoording; anders worden alle leden van de mailinglijsten overstelpt met voorgefabriceerde berichten door je vacation programma. Dit wordt als zeer grof gedrag beschouwd en 't geeft je de garantie dat je een zeer koele ontvangst staat te wachten.
Een discussielijst is een pseudo-adres welke mail naar meer dan ��n gebruiker stuurt.
In zijn eenvoudigste vorm, is een discussielijst niet meer dan een MTA alias met meer dan ��n ontvanger. Een aantal kleine discussielijsten worden op deze manier onderhouden. Sendmail assisteert door een syntax te ondersteunen in /etc/aliases waarin de inhoud van een gegeven discusselijstbestand is opgenomen in de doelzijde van een alias. Het ziet er ongeveer zo uit:
admin-list: ":include:/usr/home/admin/admin-list" |
met het voordeel dat het admin-list bestand ergens in ruimte toegankelijk voor gebruikers kan worden beheerd (root is slechts nodig voor de oorspronkelijke instelling Een aantal andere MTA's bieden vergelijkbare features.
Deze eenvoudige lijsten worden over het algemeen `mail reflectors' genoemd. Er treden een paar problemen op met mail reflectors. E�n is dat bounce berichten van mislukte pogingen naar broadcast naar alle gebruikers gaan. Een ander is dat alle aan- en afmeldingen handmatig moeten worden bijgehouden door de beheerder van de mailinglijst.
Een soort software genaamd een discussielijstmanager is ontwikkeld om iets aan deze problemen en daaraan gerelateerde problemen te doen. De belangrijkste functie ervan is gebruikers van mailinglijsten zonder tussenkomst van de beheerder van de lijst toe te staan zich op de lijst aan- en af te melden.
Een discussielijstmanager houdt zelf de informatie over gebruikerslijsten bij en maakt een verbinding met de MTA via een programma-alias in /etc/aliases. Als bijvoorbeeld de admin-list van hiervoor via de discussielijstmanager SmartList gaat op een sendmail systeem, dan zou een deel van /etc/aliases er zo uit kunnen zien:
admin-list: "|/usr/home/smartlist/bin/flist admin-list" admin-list-request: "|/usr/home/smartlist/bin/flist admin-list-request" |
Dit zijn bijelkaarhorende aliassen. Het is bij echte discussielijsten gebruikelijk dat ze beschikken over een aanvraagadres welke wordt gebruikt voor de verzoeken van gebruikers voor de aan- en afmelding. Het wordt als grof en onwetend beschouwd het aan-/afmeldingsverzoek naar het hoofdadres van een dergelijke lijst te zenden -- doe het niet.
De robot achter het aanvraagadres biedt wellicht nog andere features behalve het gewoonweg aan-/afmelden. Het kan zijn dat het reageert op hulpverzoeken, je de mogelijkheid biedt te vragen wie zich op de lijst hebben aangemeld, of je automatisch toegang geeft tot archieven van de lijst. Het kan ook zijn dat beheerders van de lijst beperkingen kunnen opleggen aan bepaalde leden, de lijst op automatisch aanmelden in kunnen stellen voor die niet-leden die voor het eerste posten, of diverse beveiligingsopties voor gedragslijnen instellen. Discussielijstmanagers verschillen hoofdzakelijk in het ontwerp en de hoeveelheid van deze bijkomende features.
Helaas is het formaat voor het versturen van opdrachten naar robots die verzoeken voor een bepaalde discussielijst afhandelen niet standaard. Een aantal daarvan verwacht opdrachten in de onderwerpregel, een aantal negeert de opdrachtregel en verwacht dat de opdrachten in het berichtenvenster staan. Let op het antwoordbericht dat je krijgt wanneer je je voor het eerst inschrijft; het is verstandig dergelijke mail op te slaan in een aparte mailbox voor latere referentie.
De belangrijkste discussielijstmanagers zijn majordomo, listserv, listproc, en smartlist; majordomo is bij een aanzienlijke groep de populairste. mailman, een lijstmanager met een nogal fraaie webge�ri�nteerde signon/signoff/beheer interface, is recent zeer populair geworden en wellicht dat het de oudere programma's gaat vervangen. Er bestaat een tamelijk uitgebreide lijst met dergelijke packages op het Web.
Raadpleeg de informatiebronnen op de List-Managers Mailing Lijst, waaronder de FAQ voor meer informatie over discussielijstmanagers (noot: deze lijst is niet geschikt voor vragen over hoe je iets kunt doen).
Eem mailfilter is een programma dat tussen jou en je lokale delivery agent in staat en automatisch mail herverzendt of verwerpt nog voordat je het hebt gezien.
Mailfilters hebben een aantal gebruiksmogelijkheden. De belangrijkste daarvan zijn het filteren van spam, het uit de weg ruimen van meerdere mailboxen per onderwerp of afzender, en het automatisch beantwoorden van mail.
Kenmerkend stel je het filteren van mail in door een programma-alias te plaatsen in het .forward bestand voor het filterprogramma en schrijft een bestand met filterregels. Het formaat en de lokatie van het bestand met filterregels varieert tussen de verschillende filterprogramma's.
Er zijn goede opsommingen van de mogelijkheden van de drie belangrijkste mailfilters (procmail, mailagent, en deliver) in deel 3 van Chris Lewis's Email Software Survey. De populairste hiervan is (ondanks zijn nogal lastige regel syntax) procmail, dat in het algemeen op Linux systemen aanwezig is (en inderdaad, gewoonlijk wordt gebruikt als local delivery agent van het systeem).
A mail filter is a program that sits between your local delivery agent and you, automatically dispatching or rejecting mail before you see it.
Spam is ook wel bekend als `UCE' (Unsolicited Commercial Email) of `UBE' (Unsolicited Bulk Email). Zoals deze namen al impliceren is het een onaangename vorm van adverteren die je mailbox met formele brieven opvult. (De term `spam' komt van een Monty Python's Flying Circus die afgegeven op een koor Vikings eindeloos de eentonige melodie "Spam spam spam spam..." herhaalt).
De meeste spam lijkt te bestaan uit verzoeken voor pyramide schema's, advertenties voor pornografie, of (ergelijke) pogingen spam-zendende programma's te verkopen. Een paar individuele spams (zoals MAKE MONEY FAST of de Craig Shergold briefkaart poets) zijn zo hardnekkig dat ze legendarisch zijn. Spam is geneigd zowel woordenrijk als ongeletterd te zijn. Het is tijdverspilling en een zeer hoge mate van verkwisting van bandbreedte.
De spam epidemie lijkt z'n hoogtepunt midden-1997 te hebben gehad en is sindsdien langzaam afgenomen, maar kan nog steeds een serieuze ergernis zijn. Als je met spam wordt overstelpt, zorg dan dat je er kennis over op doet. Blader door de "Fight Spam on the Internet!" pagina. De "Death To Spam!" pagina is in het bijzonder effectief in methoden voor het stoppen of achterhalen van spam.
Er zijn een aantal Usenet groepen toegewijd aan technische kwesties met betrekking tot elektronisch mail:
het ELM mailsysteem.
Het Rand Message Handling systeem.
Multipurpose Internet Mail Extensies.
Algemene discussies over computermail.
Multimedia Mail.
De Mail User's Shell (MUSH).
de BSD sendmail agent.
de smail mail agent.
Mail in de uucp omgeving.
Hieronder volgt een niet alles inbegrepen set met boeken die van hulp kan zijn...
van O'Reilly and Associates is de definitieve referentie over sendmail-v8 en sendmail+IDA. Het is verplichte kost voor iedereen die hoopt iets zinvols te kunnen halen uit sendmail zonder daarbij te verdrinken.
van Osborne is een prima referentieboek waarin de diverse op het Internet beschikbaar services worden uitgelegd en het is een geweldige informatiebron over news, mail en de diverse andere Internet bronnen.
van Olaf Kirch van de LDP is beschikbaar op het net en het is ook gepubliceerd door (op z'n minst) O'Reilly en SSC. Het is een prima leidraad om alles te leren over wat je je ooit had voorgesteld dat je zou moeten weten over Unix netwerken.
Ook waard te vermelden is de periodieke posting van Chris Lewis over unix e-mailsoftware, welke beschikbaar is op ftp://rtfm.mit.edu/pub/usenet/comp.mail.misc als de bestanden genaamd ``UNIX_Email_Software_Survey_*''. Een in HTML omgezette versie is te vinden op http://www.faqs.org/faqs/mail/setup/unix/. Tijdens dit schrijven in 1999 is dit bericht sedert 1996 echter niet meer serieus bijgewerkt.
In relatie met andere Unixes, is er niet langer iets speciaals aan het configureren en draaien van mail onder Linux. Dienovereenkomstig, zul je bijna zeker je posting over algemene mail-gerelateerde vragen NIET stellen bij de comp.os.linux.* nieuwsgroepen.
Tenzij je posting echt Linux-specifiek is (bv, ``zeg me alsjeblieft welke routers reeds in de SLS1.03 versie van smail3.1.28 zijn gecompileerd ''), zou je je vragen in een van de hierboven genoemde nieuwsgroepen of mailinglijsten moeten stellen.
Laat me dat herhalen.
Er is eigenlijk geen reden meer om mail-gerelateerde vragen naar de comp.os.linux hierarchie te posten. Er zijn bestaande nieuwsgroepen in de comp.mail.* hierarchie om AL je vragen te behandelen.
Als je naar comp.os.linux.* voor niet-Linux-specifieke vragen post, zoek je op de verkeerde plaats naar hulp. De elektronische mailexperts begeven zich op die plaatsen die hierboven zijn aangegeven en gewoonlijk niet in de Linux groepen.
Met posten naar de Linux hierarchie voor niet-linux-specifieke vragen verspil je je tijd en die van anderen... en het vertraagt vaak het verkrijgen van een antwoord op je vraag.
(Vince schreef deze sectie, maar voor mij geldt hetzelfde.)
Ik ben in alle feedback ge�nteresseerd, positief of negatief, betreffende de inhoud van dit document via e-mail. Neem beslist contact met me op als je fouten aantreft of er iets in ontbreekt.
Ik lees alle ontvangen email, maar reageer hier niet noodzakelijkerwijs op. Verzoeken om uitbreidingen zullen worden overwogen en hierop zal actie op worden ondernomen afhankelijk van de combinatie van beschikbare tijd, de waarde van het verzoek en de dagelijkse bloeddruk :-)
Flames zullen in stilte naar /dev/null worden gestuurd dus doe geen moeite.
In het bijzonder, de standaard voor padnamen van het Linux filesysteem is in ontwikkeling. Wat in dit document staat, staat er alleen ter illustratie gebaseerd op de huidige standaard op het moment dat een deel van dit document werd geschreven en de paden die in de distributies of `kits' worden gebruikt die ik persoonlijk heb gezien. Raadpleeg alsjeblieft de speciale Linux distributie(s) voor de paden die ze gebruiken.
Feedback betreffende het feitelijk formaat van het document zou aan de HOWTO co�rdinator moeten worden gericht, mail naar [email protected]).
De Mail-HOWTO valt onder het copyright van (c)1999 Eric S. Raymond. Copyright is behouden voor het doel om de licentie-voorwaarden van het Linux Documentatie Project kracht bij te zetten.
Een woordelijke kopie mag worden gereproduceerd of geherdistribueerd via elk fysiek of elektronisch medium zonder toestemming van de auteur. Vertalingen zijn vergelijkbaar toegestaan zonder uitdrukkelijke permissie als het een vermelding bevat over wie het vertaalde.
Korte citaten mogen, zonder voorafgaande toestemming van de auteur, worden gebruikt. Afgeleide werken en gedeeltelijke distributies van de Mail-HOWTO moeten worden vergezeld met een woordelijke kopie van dit bestand of een verwijzing naar de woordelijke kopie.
Commerci�le herdistributie is toegestaan en wordt aangemoedigd; de beheerder zou het echter waarderen om op de hoogte worden gebracht van dergelijke distributies (uit beleefdheid).
In het kort, we willen verspreiding van deze informatie zoveel mogelijk aanmoedigen via zoveel mogelijk kanalen. We willen echter het copyright op deze HOWTO documenten blijven behouden.
We willen verder dat alle informatie, waarin voorzien in de HOWTO's, wordt verspreid. Als je vragen hebt, neem dan alsjeblieft contact op met de Linux HOWTO co�rdinator, via <[email protected]>.
Uiteraard verwerpen we een eventuele potenti�le aansprakelijkheid voor de inhoud van dit document. Gebruik van de concepten, voorbeelden en/of andere inhoud van dit document is geheel op eigen risico.
Oorspronkelijk werd dit document geschreven door Vince Skahan. Ik heb het herschreven voor de moderne rondom ISP gecentreerde wereld waarin UUCP niets meer is dan een herinnering.
In mei 1999 werd de naam "De Linux Electronic Mail HOWTO" gewijzigd ter voorkoming van een dubbele naam met Guylhem Aznar's Mail HOWTO, wat de Mail Administrator HOWTO is geworden.
| Wijzigingen | ||
|---|---|---|
| Herziening 3.3 | 2003-02-22 | Herzien door: esr |
| LDP site en mijn homesite verplaatst. | ||
| Herziening 3.2 | 2001-02-22 | Herzien door: esr |
| LDP Styleguide markup correcties. | ||
| Herziening 3.1 | 2000-12-08 | Herzien door: esr |
| Mailman vermeld. | ||
| Herziening 3.0 | 2000-08-08 | Herzien door: esr |
| Eerste DocBook versie. | ||