De Linux Mail User HOWTO

Nieuwe versies van dit document

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.

Hardwarebenodigdheden voor e-mailprogramma's

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.

Softwarebronnen voor e-mailprogramma's

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.

Je maileditor instellen

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.

mutt

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

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

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.

Netscape

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 rmail/smail en vm.

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.

BSD mail

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.

Andere user agents

Van de volgende programma's is ook bekend dat ze onder Linux draaien. Raadpleeg `archie' om ze op te sporen...

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.

Aliassen

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	<esr@thyrsus.com>

in het configuratiebestand van mutt kunnen schrijven. Wanneer mutt nu `esr' in een adresregel tegenkomt, zou het zich gedragen alsof je `esr@thyrsus.com' 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.

Forwarding

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.

Automatisch antwoorden

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.

Discussielijsten

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).

Mailfilters

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.

Het hoofd bieden aan spam

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.

USENET

Er zijn een aantal Usenet groepen toegewijd aan technische kwesties met betrekking tot elektronisch mail:

Boeken

Hieronder volgt een niet alles inbegrepen set met boeken die van hulp kan zijn...

Periodieke USENET Postings

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.

Waar niet om hulp te zoeken

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.

Feedback

(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 linux-howto@metalab.unc.edu).

Copyrightinformatie

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 <linux-howto@metalab.unc.edu>.

Standaard Disclaimer

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.

Erkenningen

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.