CERT waarschuwt voor kritieke fout in Sendmail

Het Sendmail Consortium heeft in verband met een kritisch veiligheidsprobleem een nieuwe versie uitgebracht van de gelijknamige mailsoftware. In oudere versies van Sendmail kan een aanvaller via een mailtje rechten verkrijgen op het systeem. In de header van het mailtje zal dan speciale code zijn opgenomen die gebruik maakt van het lek. Met een succesvolle aanval kunnen de rechten van het account waaronder de Sendmail daemon draait verkregen worden: in de meeste gevallen is dit het zogenaamde administrator account "root". Omdat er op e-mailniveau misbruik gemaakt kan worden van deze bug is het veiligheidslek extra gevaarlijk. Een firewall of packetfilter bied geen afdoende bescherming want de e-mail wordt gewoon doorgestuurd naar de ontvangende server achter de firewall:

Researchers found the vulnerability to be message-oriented, as opposed to connection-oriented, which means it is triggered by the content of a "specially-crafted email message rather than by lower-level network traffic." "This is important because an MTA that does not contain the vulnerability will pass the malicious message along to other MTAs that may be protected at the network level. In other words, vulnerable Sendmail servers on the interior of a network are still at risk, even if the site's border MTA uses software other than Sendmail," CERT/CC warned.

Ongeveer 75 procent van al het e-mailverkeer verloopt via oudere en kwetsbare versies van Sendmail. Iedereen wordt geadviseerd om de net uitgebrachte 8.12.8 te installeren of gebruik te maken van een van de patches voor oudere versies. Hier en hier is meer informatie te vinden.

Reacties (43)

[Verwijderd]

"Leuk" om te vertellen dat deze bug er al vijftien jaar inzit.

/edit

De fout zit in een beveiliginscode die over zijn nek gaat bij mails met buitensporig grote headers. Bijkomend probleem is dat Firewalls dit niet als gevaarlijk zien. Die beveiligingscode wordt al 15 jaar lang gebruikt in Sendmail.

De bug is trouwens al sinds januari bekent, dus de meeste bedrijven hebben al een update ontvangen.

[Crazy D]

tjah, open source he. Iedereen kan de broncode bekijken, en bugs worden dus ook heel snel gefixed. Blah blah. Standaard promo-praatje van open source, wat dus niet altijd de waarheid blijkt te zijn.

Hopen dat de patch zo snel mogelijk overal wordt geinstalleerd, anders kunnen we ons lol nog op....

Wel netjes dat er pas gewacht is met openbaar maken totdat de fix volledig klaar is. Zouden "ze" vaker moeten doen (en niet alleen bij open source).

[kakanox]

Zouden "ze" vaker moeten doen? Hmm... de broncode van Microsoft-software is ook niet zo moeilijk te vinden, er zwerven zat geripte versies over het internet. En zou je daar niet aan kunnen komen, dan is er nog altijd reverse-engineering.

Blijkbaar is deze bug in sendmail nog niet zo vaak misbruikt, ik heb er nog niemand over gehoord of gelezen in elk geval - dit terwijl er toch al een behoorlijk aantal wat grotere bedrijven gebruik maken van "alternatieve besturingssystemen". Rond Microsoft zijn in elk geval al zat schandalen geweest m.b.t. bugs...

Conclusie: Bugs vinden we overal, bij Microsoft, bij Linux, en bij alle andere besturingssystemen die ooit geschreven zijn. Laten wij tweakers dat nu eens niet telkens weer misbruiken om de betreffende fabrikant (en het bijbehorende concept) maar weer af te zeiken alsof het allemaal niks is - als je jezelf van de rechten wil voorzien (en ja, dat is dubbelzinnig bedoeld ) om software van anderen negatief af te schilderen, dan moet je zelf met een beter product of heel erg goede argumenten komen, lijkt me.

[Crazy D]

Ik doelde niet specifiek op MS of iemand anders.

"Men" zegt vaak dat 1 van de voordelen van open source is, dat het open is en er dus veel mensen in de broncode kijken, en dat bugs daardoor sneller opgemerkt worden. Als deze bug idd op zich al heel lang in sendmail heeft gezeten, is dat dus niet altijd het geval. Gewoon een constatering dus.

En met "zouden "ze" vaker moeten doen" bedoel ik heel simpel, dat het vaak zat gebeurt dat er eerst openbaar wordt gemaakt dat er een bug ergens in zit, en dat diegenen die achter dat programma zitten (bedrijf of groep vrijwilligers of wie dan ook) vervolgens maar als een gek moet gaan coden om de bug te fixen. In dit geval is gewacht met openbaar maken totdat de fix er was, en dat vind ik netjes. En dat zou dus vaker moeten gebeuren (zodat de programmeurs ook de tijd hebben om het goed te fixen).

[freaky]

"Men" zegt vaak dat 1 van de voordelen van open source is, dat het open is en er dus veel mensen in de broncode kijken, en dat bugs daardoor sneller opgemerkt worden. Als deze bug idd op zich al heel lang in sendmail heeft gezeten, is dat dus niet altijd het geval. Gewoon een constatering dus.

Veel mensen kunnen in de source kijken, dat wil dus niet zeggen dat ze dat ook doen.

En met "zouden "ze" vaker moeten doen" bedoel ik heel simpel, dat het vaak zat gebeurt dat er eerst openbaar wordt gemaakt dat er een bug ergens in zit, en dat diegenen die achter dat programma zitten (bedrijf of groep vrijwilligers of wie dan ook) vervolgens maar als een gek moet gaan coden om de bug te fixen. In dit geval is gewacht met openbaar maken totdat de fix er was, en dat vind ik netjes. En dat zou dus vaker moeten gebeuren (zodat de programmeurs ook de tijd hebben om het goed te fixen).

Denken dat de cracker/hacker society niet op de hoogte is van de bug omdat er toevallig niet over gesproken word is lomp. Eigenlijk is lomp nog te zachtzinnig. Persoonlijk vind ik het geheim houden van bugs hypocriet en lomp. Effe 3 maanden ons smoel houden.... Weet je hoeveel er in 3 maanden kan gebeuren? Ik had liever zolang even overgeschakeld op postfix oid ipv niet weten dat ik zo lek als een mandje ben en anders kan ik d'r altijd nog een content-filter voor hangen. De enige manier waarop deze methode zin heeft is als de rest v/d wereld zo lomp als een varken is en hoewel 95% dat ook is is er altijd die 5 andere procent nog.

Daar komt nog bij dat het algemeen bekend is dat sendmail zo buggy als de pleuris is. Als je dan zo lomp bent het toch te installeren, danwel het wel moet ivm de functionaliteit dan dien je dat dus in de gaten te houden. Hence, je wilt weten dat er een bug in zit, patch of niet.

[Verwijderd]

Ik denk dat er op korte termijn WEL een voordeel te behalen valt uit het niet bekend maken, vooropgesteld dat het probleem door een bonafide onderzoeker/programmeur is ontdekt (wat toch met enige regelmaat gebeurt en in dit geval ook, door ISS namelijk). Als je het meteen bekendmaakt, zal er METEEN gebruik van worden gemaakt door crackers, nog voordat er een fix is en voordat mensen de tijd hebben om te updaten. Zie het maar zo: het is blijkbaar (hoewel open source) in ik weet niet hoeveel versies niet ontdekt.

Wat is de kans dat het OPEENS WEL ontdekt wordt door een cracker NET in die paar dagen tussen de ontdekking door de bonafide onderzoeker en het beschibaar zijn van een fix? Nihil.
Wat is nu de kans dat er misbruik van wordt gemaakt als het meteen bekend wordt gemaakt, maar nog geen fix is? Nou, dicht bij 100% vermoed ik.

Ik weet niet waar je die drie maanden vandaan haalt (ik heb het zo gauw nergens zien staan).

Een paar dagen geheim houden tussen de ontdekking en de fix is een verstandige en risico-verkleinende strategie (geldt voor OS en voor closed source).

Even een opmerking over "Als deze bug idd op zich al heel lang in sendmail heeft gezeten, is dat dus niet altijd het geval."
Dat de kans dat iets optreedt heel klein is, wil niet zeggen dat het nooit zal gebeuren. OS claimt niet dat er nooit en te nimmer bugs heeft, enkel dat deze gemiddeld gesproken sneller opgemerkt en/of gerepareerd worden.

[arjankoole]

euh? hoe kom je d'r bij dat deze bug er al 15 jaar in zit?

't zou best kunnen hoor, maar vergeet niet dat 15 jaar geleden het net er een boel anders uitzag dan tegenwoordig het geval is. security leaks in software waren simpelweg niet intressant, want niemand wilde er misbruik van maken. Pas toen de halve planeet op internet ging werd het een ander verhaal en ging het fout met internet. (ook wel bekend als de eeuwige september bij de rotten op het net)

[Erycius]

Ik ben geen rot op het net, leg je dat van die eeuwige september es uit?

[Verwijderd]

Een paar jaar terug had nog (bijna) niemand thuis een Internetaansluiting en bedrijven zaten ook nog niet op Internet. Een groot deel van Internet-gebruikers was dus online via de universiteit. Elk jaar, in september, kwam er een grote groep nieuwe studenten op de universiteiten. September was dus heel lang de maand waarop veel 'newbies' op Internet kwamen, dan werden er dus veel domme en off-topic vragen gepost in nieuwsgroepen. Toen op een bepaald moment iedereen gebruik ging maken van Internet, kwamen er niet alleen in september veel 'newbies' online, maar was het het hele jaar door september; eeuwig september dus.

[liberque]

Kreeg zojuist een update via apt binnen op Debian.

http://security.debian.org stable/updates/main sendmail 8.12.3-5 [1004kB]

Vraag me nu dus af of dat die 8.12.8 backported is ofzo. Aangezien er gisteren nog geen updates beschikbaar waren.

[Verwijderd]

http://www.deadly.org/article.php3?sid=20030303174136

^^^^
OpenBSD 3.1/3.2 patch. Trouwens daar staat ook een imo interessante comment namelijk deze:

http://www.deadly.org/commentShow.php3?sid=20030303174136&pid=95

"Anyway, this bug is not trivial to exploit. As I see, what you can inject is restricted to a very small charset of control characters, it's hard to get a valid address with that (+ harder to copy something to that address)."

Het is jammer dat Sendmail een vrije licentie heeft en Qmail/Postfix niet. Nu blijft Sendmail bij een aantal OSen/distro's daardoor de default MTA.

[cpwins]

Ja zo doen ze dat bij Debian. Ze hebben besloten dat versie 8.12.3-* geschikt is voor 'stable'. Als er dan een security fout in blijkt te zitten dan maken ze daar zelf een patch voor. Meestal houdt dit in dat de patch die de auteurs maken geschikt wordt gemaakt voor de huidige 'stable' versie.

[arjankoole]

Vraag me nu dus af of dat die 8.12.8 backported is ofzo. Aangezien er gisteren nog geen updates beschikbaar waren.

Debian en andere Linux Distro's patchen altijd, net zoals FreeBSD's ports systeem / Core. Vandaar die -5 d'r achter, da's Patch 5 die is uitgevoerd.

gisteren was er wel degelijk een update overigens, de tijd dat ik 8.12.8 binnen trok was 18:00 op 3 maart.

[ShivanDragon]

Nou, virusschrijvers kunnen hiermee weer lelijk huishouden... Binnen een jaar staan draaien er nogsteeds duizende vulnerable sendmail deamons.

[GraveR]

Dat is dan de fout van de beheerders, niet van de software of de makers daarvan an sich.

Ik kreeg gister deze melding al via FreeBSD Security Advisories, kompleet met stap-voor-stap handleiding hoe de patch toe te passen of andere binaries op het systeem te zetten.

Beheerders die dit niet kunnen/willen of what ever, kunnen beter een andere baan gaan zoeken. Bloemschikker ofzo.

[Crazy D]

Dat is dan de fout van de beheerders, niet van de software of de makers daarvan an sich.

Dat is het altijd (zolang er een patch beschikbaar is voordat de bug openbaar gemaakt wordt). Alleen als het een MS product is, wordt MS volledig met de grond gelijk gemaakt, terwijl ook dan het de fout van de beheerders is dat een patch niet op tijd is geinstalleerd.

[arjankoole]

de grootste reden dat MS wel met de grond gelijk gemaakt wordt is omdat je voor MS producten bergen met geld betaald, terwijl dat voor sendmail (deze variant iig) niet zo is.

een ander belangerijk aspect is: hoe snel na bekendmaking van bijvoorbeeld CERT of een ander bedrijf (zoals in dit geval) zijn er patches? Bij microsoft blijven meldingen over exploits, compleet met analyses en exploit tools om te testen, soms maanden liggen. Tja, vind je het gek dat er dan geklaagt wordt.

persoonlijk vind ik, alhoewel ik een enorme BSD fanaat ben, dat MS qua product beveiliging, informatie verstrekking en patch bouwen sterk vooruit is gegaan. Ze maken nog wel eens blunders, sure, maar wie doet dat niet.

dat ik bij BSD blijf (en sendmail overigens) is simpelweg omdat ik het het beste en meest flexible (en schrik niet: het makkelijkste) vind werken.

(en ter illustratie: ik haat ports and packages)

[arjankoole]

Hoef ik alleen nog Apache & SSH in de gaten te houden. Scheelt weer...

scheelt niets. wat als er op dit moment een exploit voor qmail gevonden wordt, dan ben je alsnog druk bezig met het instaleren van een update. Of zou dan aan je voorbij gaan (met alle gevolgen van dien)?

er is geen software die foutloos en dus exploit-loos is. derhalve zul je als beheerder ten alle tijden al je software in de gaten moeten blijven houden, anders ben je de lul.

weet je nog dat de jongens van OpenSSH zo liepen te pochen over de veiligheid van hun code? Je hebt gezien hoe hard ze alle hoeken van het internet hebben gezien toen de ene na de andere root-exploit ontdekt werd. Op het moment dat je software heel veel gebruikt wordt trekt het ook intresse van bug-hunters.

[Verwijderd]

scheelt niets. wat als er op dit moment een exploit voor qmail gevonden wordt

Onrealistisch: is er nog nooit 1 gevonden in.. pak 'm beet 7 jaar. DJB loopt daar niet zo mee te pochten zoals het OpenBSD team. In Sendmail wordt er zo'n beetje elk kwartaal wel 1 gevonden. Qmail wordt overigens wel veel gebruikt: 2st populaire MTA. Het is ook schaalbaar. Hotmail/Yahoo gebruikt het bijvoorbeeld.

Dus, niets? Ik heb nog nooit mijn Qmail moeten upgraden. Ik heb altijd de vrijheid gehad tot keuze tot upgraden of niet.

er is geen software die foutloos en dus exploit-loos is. derhalve zul je als beheerder ten alle tijden al je software in de gaten moeten blijven houden, anders ben je de lul.

Je kunt de impact wel bemoeilijken met non-executable stack, propolice/systrace, chroots/jails en andere zaken.

weet je nog dat de jongens van OpenSSH zo liepen te pochen over de veiligheid van hun code? Je hebt gezien hoe hard ze alle hoeken van het internet hebben gezien toen de ene na de andere root-exploit ontdekt werd.

- Dat was het OpenBSD team; niet het OpenSSH team. Wezenlijk verschil.
- de meeste waren local root exploits; niet remotable exploitable.
- er is maar 1 remote root exploit geweest vlak voor PrivSep er aan kwam. Op het moment dat die hole bekend werd hebben ze gauw iedereen de mogelijkheid gegeven te upgraden naar een PrivSep enabled OpenSSH waardoor iedereen met PrivSep niet exploitable was. Daarna kwam de advisory/exploit in het openbaar inclusief bugfix.
- Vergelijk het eens met andere SSH server software. Lachertje.

Conclusie: je overdrijft het imo enigzins.

[Verwijderd]

dat ik bij BSD blijf (en sendmail overigens) is simpelweg omdat ik het het beste en meest flexible (en schrik niet: het makkelijkste) vind werken.

Dat is zo'n beetje ook de reden waarom ik het bij Linux + Qmail hou. Qmail heeft bovendien als voordeel dat er nog nooit een veiligheidslek in is aangetroffen. Hoef ik alleen nog Apache & SSH in de gaten te houden. Scheelt weer...

[AntiChris]

Het is niet de eerste keer geweest en zal zeker niet de laatste keer zijn dat je met Sendmail een buffer overflow kan genereren, dus voor de "virusschrijvers" is er nog steeds genoeg werk....

[dimi]

Cooooool! Ik kreeg dus vanochtend van Apple (OSX ofwel netBSD) een autoupdate met... sendmail. Ik hoorde het dus eerder van Apple dan van Tweakers. Begeleidend verhaaltje 'ook al staat het standaard uit, je krijgt em toch maar voor de zekerheid'. Netjes hoor.

[arjankoole]

Cooooool! Ik kreeg dus vanochtend van Apple (OSX ofwel netBSD)

FreeBSD is wat gebruikt werd voor OSX, niet netBSD. (de oprichter van FreeBSD, Jordan Hubbard, werkt tegenwoordig ook voor Apple)

overigens is de kernel weer Mach64.

[Little Penguin]

FreeBSD is wat gebruikt werd voor OSX, niet netBSD. (de oprichter van FreeBSD, Jordan Hubbard, werkt tegenwoordig ook voor Apple)

Volgens mij heeft Darwin (kernel van MacOS X) zowel code van NetBSD als van FreeBSD.

[Verwijderd]

Netjes? Appple weet dit al vanaf de eerste maand van het jaar. Niet echt snel gehandeld dus als je het mij vraagt.

[reinouts]

Op http://www.mandrakeclub.com/article.php?sid=547&mode=nocomments kun je de details vinden over de patch voor Mandrake.Overigens is postfix standaard in Mandrake dus hoef je die patch alleen te installeren als je bewust voor sendmail gekozen hebt.

[Verwijderd]

in de meeste gevallen is dit het zogenaamde administrator account "root".

mail 23072 0.0 0.0 2676 0 ? SW Mar03 0:00 [sendmail]

Hmmm, het is al weer even geleden voor mij dat ik sendmail gedraaid heb (bovenstaande is <a href="\"http://www.exim.org\"" target="_blank">exim</a>, vanwege het feit dat daar minder holes in lijken te zitten), maar het lijkt me dat die toch ook makkelijk onder een user als 'mail' moet kunnen draaien?

[Hans]

Een deel van het proces zal altijd als root moeten draaien omdat poort 25 een priviledged port is. Tegenwoordig wordt het grootste risico weggenomen door het gebruik van de user/group smmsp, maar bepaalde delen moeten als root draaien. Oplossing is evt. een chroot jail.

[arjankoole]

ik ben het helemaal eens met Hans, maar ik wil nog een kleine footnote plaatsen:

als je de gebruiker als mail laat draaien, zal iedere andere gebruiker op de een of andere manier ook als gebruiker mail moeten werken. (setuid of setgid dus). dus de constructie van exim snap ik niet helemaal. (tenzij exim weer setuid doet als ie mail wegkalkt, maar da's ook potentieel gevaarlijk)

root is niet zo slecht, ook niet als je root 'ziet'. Veelal laat een applicatie alle mogelijke rechten vallen, en houdt alleen het priv. poort recht. Slimme software dropt dus ook het recht weer te setuid()'en of setgid()'en. wat dus naar verhouding heel veilig is. (overigens weet ik niet hoe sendmail dit doet)

beeld je het in als: de applicatie is root, maar mag minder dan een reguliere user met een shell account

[Verwijderd]

Een deel van het proces zal altijd als root moeten draaien omdat poort 25 een priviledged port is

Nee hoor er zijn patches voor Linux waarmee bepaalde groups wel als user < port 1024 kunnen draaien.

Daarnaast draait Sendmail volledig als root. Kijk, DJB heeft dat met zijn Qmail heel anders gedaan: bijna niks draait als root, enkel 'qmail-lspawn' (van het MTA gedeelte, de POP3 server draait doorgaans ook als root via tcpserver)

[arjankoole]

Nee hoor er zijn patches voor Linux waarmee bepaalde groups wel als user < port 1024 kunnen draaien.

ik geloof dat dat POSIX breekt, iets wat FreeBSD en andere OS'en dus niet zo leuk vinden. En daarnaast, ik wil geen enkele normale user op een priv. poort hebben. Goeie software schrijven en je hebt nergens last van. Je moet niet alleen Linux denken aye?

waarom denk je trouwens dat het patches zijn, en het niet in de 'standaard' linux kernel zit. Ik denk dat Linus zich bij dergelijke patches ook wel drie keer bedenkt, het kan vrij riskant zijn.

het nadeel van sendmail is misschien wel dat het zo ongeloofelijk oud is, face it, het was de eerste MTA. En het is niet zonder reden dat veel ISP's (waaronder de ISP waar ik werk) het gebruiken. Qmail en Exim kunnen simpelweg niet wat wij met sendmail doen (getest uiteraard) en Postfix kan dat wel, maar met 20+ config files is het te onoverzichtelijk. met Sendmail zijn we heel snel klaar, en da's met 4 config files (en hashed databases). De config file zelf is ook zo simpel als het maar kan.

Daarnaast draait Sendmail volledig als root

dat weet ik dus zo net nog niet, het kan heel goed zijn dat het process eruit ziet als root, maar in principe minder rechten heeft dan ik als user op de shell. het hangt er maar net vanaf hoe de interne werking is, ik zou het eigelijk eens aan Eric Allman moeten vragen.

[Verwijderd]

ik geloof dat dat POSIX breekt, iets wat FreeBSD en andere OS'en dus niet zo leuk vinden. En daarnaast, ik wil geen enkele normale user op een priv. poort hebben. Goeie software schrijven en je hebt nergens last van. Je moet niet alleen Linux denken aye?

Dan vraag ik mij af in hoeverre breekt dat POSIX dat het belangrijk is om zo'n patch vooral niet te gebruiken? Wat is de impact volgens jou?

Sorry hoor maar hierboven beweer je in een discussie nog van 'veilige software bestaat niet je zult altijd moeten patchen' - dit als argumentatie waarom Qmail geen goede vervanging zou zijn voor Sendmail. Dan spreek je je bij deze tegen tov die uitspraak. Maagoed met PrivSep kun je dus zonder kernel patch wel binden op < 1024 en dat is momenteel OpenBSD-only hoewel makkelijk portable. En voila FreeBSD heeft het ook.

waarom denk je trouwens dat het patches zijn, en het niet in de 'standaard' linux kernel zit. Ik denk dat Linus zich bij dergelijke patches ook wel drie keer bedenkt, het kan vrij riskant zijn

Linus is conservatief in z'n stable branch mbt nieuwe patches, ook mbt security features. Je kunt het er echter zo bij patchen: Socket ACLs @ GrSecurity.

het nadeel van sendmail is misschien wel dat het zo ongeloofelijk oud is, face it, het was de eerste MTA. En het is niet zonder reden dat veel ISP's (waaronder de ISP waar ik werk) het gebruiken.

'De eerste' vind ik niet een argument waarom je een bepaalt stuk software zou moeten blijven gebruiken wanneer er alternatieven voor zijn. Waarom is MSIE zo populair? Deze mensen moeten allemaal aan de Mosaic!

Qmail en Exim kunnen simpelweg niet wat wij met sendmail doen (getest uiteraard) en Postfix kan dat wel, maar met 20+ config files is het te onoverzichtelijk. met Sendmail zijn we heel snel klaar, en da's met 4 config files (en hashed databases). De config file zelf is ook zo simpel als het maar kan.

Ben ik toch donders benieuwd wat jij met Sendmail wel aan de praat krijgt en met Qmail niet, maar goed, dat zijn misschien mijn zaken niet... desondanks ben ik wel benieuwd

Welke prettiger werkt dat is nogal subjectief. De geschiedenis mbt. beveiligen niet dat zijn harde feiten. De teller: Qmail, 2st populaire MTA: 0. Sendmail, 1st populaire MTA: de tel kwijt geraakt.

"Sendmail has more bugs than any other piece of software that I am aware of (excluding Windows). The ISC bedrijf dat BIND/DHCPd code - red.has been known to charge for bugfixes (including security-related ones). setuid-root applications run in a very dangerous environment: and yet, people tend to not take them very seriously..." bron.

PS: dat Sendmail 100% als root draait kun je zo met Google vinden... algemeen bekend ook... anders kun je 'lsof' gebruiken.

[arjankoole]

ik denk dat we deze discussie beter op ICQ oid kunnen voortzetten, voor we de databases van T.NET flooden met over en weer gepost

[Darkangle]

edit:
OOPS, was te snel... ff leren lezen...

[hommer]

Ik ben blij dat ik ooit voor qmail gekozen heb. Al sinds 1998 versie 1.03 zonder problemen.

[Verwijderd]

Ja hier ook alleen maar qmail ben er tot nu toe meer tevreden over dan over sendmail

[-=bas=-]

Als zo'n n00b als ik ben dan kom je idd uit bij Qmail.
Maar niets anders dan lof over Qmail, dat wilde tenminste gewoon werken en doet braaf zijn/haar werk.
Gelukkig zijn er ook voldoende alternatieven voor mailinglists e.d voor Qmail.

[oXygeN]

Ik heb gisteravond al 8.12.8 geinstalleerd...