Een blik op MailRadar.com laat zien dat Sendmail nog steeds de nummer 1 MTA (mail transfer agent) is, gevolgd door Postfix, en op eerbiedige afstand door Qmail. Daar is ook te zien dat er hier en daar nog mensen zijn die MMDF gebruiken. Wat verder opvalt is het totaal ontbreken van Exchange, wat de cijfers natuurlijk ietwat verdacht maakt. Maar toch kunnen we veilig stellen dat Sendmail nog steeds aan de top staat.

De non-Sendmail MTA’s worden aangeprezen als, nou ja, non-Sendmail. Van Sendmail wordt vaak gezegd dat het een veiligheidsrisico is, maar dat is niet mijn ervaring, en ik heb in de loop van de jaren honderden Sendmailservers en mail relays beheerd. De laatste 15 jaar is Sendmail bij mijn weten zelfs nooit gebruikt als aanknopingspunt bij een aanval.

Binnen een paar minuten

Laatst hielp ik een vriend bij het opzetten van MailMan op een gehoste Linux VPS server. De VPS draaide Plesk en Qmail. Dat lijkt simpel genoeg. Alleen werd in dit geval de e-mail voor het domein ergens anders gehost, dus hadden we een subdomein nodig om e-mailverkeer naar die specifieke server te kunnen sturen. Dat leek slechts een kwestie van configureren, maar na een paar uur turen naar vreemde meldingen van Qmail, heb ik de hele server overgezet naar Sendmail. En toen had ik het hele zaakje binnen een paar minuten up en running. Natuurlijk is dat ook te danken aan mijn ervaring met Sendmail, maar als het om Qmail gaat ben ik ook geen beginner. Er waren in dit geval gewoon een paar behoorlijke problemen met Qmail en Plesk, en ik had geen zin om daar helemaal in te duiken.

Complex

Van Sendmail wordt wel gezegd dat de configuratie een ellende is. En ik ben iemand die custom rulesets heeft geschreven voor een geweldig complexe Sendmail structuur, dus kan ik zeggen dat als je wat dieper op Sendmail ingaat, het heel snel heel complex wordt. Maar dat is nu net het grote voordeel, dat je er dieper op in kunt gaan. Zoals de meeste dingen in IT, betekenen meer configuratiemogelijkheden ook een grotere complexiteit. De realiteit is dat 99 procent van de Sendmail-configuratie extreem simpel is – een paar regels in een sendmail.mc gevolgd door een make, en alles is in orde.

Maar zijn die andere MTA’s dan niet complex? Kijk eerst maar hoe je virtuele e-mail domeinen en aliases met Qmail moet configureren, en kom dan maar eens terug op de complexiteit van Sendmail. Dan piep je wel anders. Qmail is echt fantastisch simpel in een paar simpele dingen. Maar het is nodeloos complex als het om andere dingen gaat. Zelf hoop ik dat ik nooit meer een script hoef te schrijven om .zmail-xxx files uit te spuwen.

Postfix is een goed alternatief dat een paar van de betere concepten van Sendmail koppelt aan een simpelere (maar ook minder kneedbare) configuratie. Voor mij is Postfix het enige geloofwaardige alternatief voor Sendmail, als het gaat om features en het algemene gebruiksgemak. De belangrijkste reden dat ik me in het verleden niet met Postfix inliet, was het gebrek aan ondersteuning voor milter. Dat betekende dat het gebruik van milters als. MIMEDefang, milter-greylist niet mogelijk was. Gelukkig heeft Postfix deze ondersteuning toegevoegd in versie 2.3.

Exchange

En dan is er natuurlijk nog de gorilla die de naam Exchange draagt. Voor iedereen die is opgegroeid met Sendmail of Postfix, is Exchange vanuit het beheerstandpunt een gruwel. Dat is door de jaren heen wel wat verbeterd, maar ik vind het nog steeds vervelend als ik ermee word geconfronteerd. Exchange is langzaam en nukkig, en vergeleken met de GUI beheerinterface van Exchange is de configuratie van Sendmail kinderspel. Je kunt zeggen wat je wilt over de non-Microsoft MTA’s, maar ze hebben een ding gemeen, en dat is dat over het algemeen de hele configuratie maar op een of twee plaatsen staat. Bij Exchange zit het overal en nergens, maar op een of andere manier toch allemaal binnen een MMC-tool. Natuurlijk is Exchange meer dan een MTA, maar dat is geen excuus voor de hindernissen waar systeembeheerders overheen moeten springen om relatief simpele taken voor elkaar te krijgen, zoals het migreren naar een nieuwe server.

Laten we nog een zaak bekijken: Een Sendmail server met IMAP en POP die gemigreerd moet worden naar nieuwe hardware of een virtuele machine. Daarvoor moeten we een nieuwe server bouwen, de inhoud van /etc/mail, /etc/passwd, /etc/Group en /etc/shadow kopiëren, en een rsync draaien op de mailbox folder. Als er gecentraliseerde authenticatie is, dan is het nog eenvoudiger. Alles bij elkaar is dat een uurtje werk, vanaf het installeren van het besturingssysteem totdat de nieuwe server in de lucht is. Met grote mailboxes doet rsync er misschien wat langer over. En als de IMAP/POP server gebaseerd is op Cyrus, dan zijn er nog wat meer aanpassingen nodig, maar verder is het een simpele situatie zonder verrassingen.

Migratie

Daar kun je niet van spreken bij Exchange. Het migreren van een relatief kleine mailstore kan uren en uren in beslag nemen. Bij een Exchange migratie die ik laatst meemaakte ging de voortgangsbalk voor de Move Mailbox operatie in de GUI binnen vijf minuten van 0 naar 100 procent, waar we nogal van opkeken. Een paar controles brachten aan het licht dat de migratie nog lang niet klaar was, maar nog gewoon bezig was. De voortgangsbalk kreeg vervolgens een epileptische aanval die zo’n zes uur duurde voordat de 15GB aan mail eindelijk was verplaatst. Voor de mensen die mee zitten te schrijven, dat is ongeveer 5.5Mbit of 600KBps. En dit ging tussen twee dual-CPU servers met gigabit interfaces en six-spindle RAID5 arrays!

Als er iets is waar ik niet tegen kan bij migraties, dan is dat het feit dat zulke lange, zware processen alleen een enkele reis zijn. Want als aan het eind van die lange zes uren problemen opduiken met de migratie, dan moet je op een of andere manier weer terug kunnen naar de originele server. Bovendien heb ik er een gruwelijke hekel aan als voortgangsbalken tegen me gaan zitten liegen. Zonder goede indicatie tast je als admin in het duister en dat is geen pretje, zeker niet als de migratie de volgende dag compleet moet zijn.

Het is ook niet aan me voorbijgegaan dat de meeste Exchange implementaties niet direct aan het internet hangen. Meestal is er een mail relay die de e-mail filtert voor die bij Exchange komt. Zelf zou ik Exchange nooit installeren als een front-end MTA. Ik gebruik liever preventief een Linux Sendmail server, MIMEDefang en een virusscanner.

Onder de veren

Maar zonder Exchange zouden we geen Outlook hebben. En zonder Outlook, zo stel ik me voor, zouden mensen niet weten wat ze zouden moeten doen. Dan zitten ze besluiteloos achter hun bureau, zonder dat ze weten waar de vergadering plaatsvindt en wie ze gaan ontmoeten. Het is waar dat de meeste organisaties de features nodig hebben die door Exchange worden geleverd, en hoewel er wel open source producten zijn die deze features bieden, zijn die niet zo gestroomlijnd en geïntegreerd als de combinatie Exchange/Outlook. Wie echt onder de veren van Microsoft wil schieten zal precies daar moeten beginnen. Bron: Techworld