Sinds enige tijd doe ik mee aan de IPv6-pilot van XS4ALL om gebruik te kunnen maken van IPv6 zonder dit via een extra tunnel te doen. In een recente update, versie 54.04.81-17599, voor oa de Fritz!Box 7270 van AVM is de ondersteuning voor RFC 5006 goed aangepakt. Helaas staat deze optie standaard uit, maar wel begrijpelijk om potentiële problemen te voorkomen met minder goed werkende netwerk hardware. Gelukkig zijn zowel MacOS X als vele Linux distributies klaar voor RFC 5006.
De vraag alleen is wat heb je aan RFC 5006? Het ligt eigenlijk in de provisioning van de nameservers die kunnen worden gebruikt als resolver. Met de komst van IPv6 is een DHCP-server eigenlijk niet meer nodig en blijft de vraag over hoe je sommige configuratie-items gaat zetten. En hoewel RFC 5006 een smerige hack lijkt is het eigenlijk wel netjes, want er zijn voorzieningen om bepaalde uitgiften te laten ondertekenen in IPv6. Hiermee gebruikt de client alleen gegevens met het juiste signature en is het eigenlijk veiliger dan vele DHCP-oplossingen die nu binnen bedrijven staan, maar een daadwerkelijke bruikbare oplossing laat nog op zich wachten.
Het aan de praat krijgen op bv Debian of Ubuntu is vrij simpel met de volgende opdracht.
$ sudo apt-get install rdnssd resolvconf
Als je nu reboot en kijkt in /etc/resolv.conf krijg je bv het volgende te zien:
$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver fd00::21f:3fff:fe30:4ff0
nameserver 192.168.178.1
search fritz.box
Wat nu nog overblijft is NTP wat met behulp van NTP-broadcasting gedaan zou kunnen worden, maar hier kleven wel nadelen aan. Want hoe kan je de broadcaster vertrouwen dat hij de juiste tijd geeft? Hoor ik hier een oplossing in DNSSEC?
Bij het lezen van idee #25103 op de Ubuntu Brainstorm-site kwam de vraag hoever Debian dit nu heeft opgelost. Zeker aangezien Debian de moederdistributie van Ubuntu is en ze enige tijd geleden al waren overgegaan op een GeoDNS oplossing voor sommige sites.
Een brand, een zware verstoring en een update van OpenOffice.org heeft ervoor gezorgd dat model van security.debian.org anders moest. Het moest van een enkele server naar een schaalbare oplossing gaan zonder daar de gebruikers mee op te zadelen. Dit is gelukt aangezien security.debian.org nu mbv GeoDNS en HTTP-polling voor iedereen bereikbaar is gemaakt door een bereikbare mirrorserver in de buurt van het gebruiker aan te bieden.
Voor de algemene repository is de urgentie wat minder groot, omdat de gebruiker zelf kan kiezen in welk land de mirrorservers moeten worden benaderd. De vraag blijft of deze manier blijft schalen, want er zal altijd wel ergens een server onbereikbaar zijn door werkzaamheden. De Nederlandse mirror is daar geen uitzondering van, maar voor gratis hosting moet je iets over hebben. En waarom zou een andere server dit werk niet “transparant” kunnen overnemen?
Een klein project loopt nu om te testen of te kijken wat de meest ideale manier is om dit ook voor de normale mirrors van de repository te doen. Gelijk komt hier het probleem naar voren dat niet alle mirrors alle architecturen aanbieden, maar iedereen met een i386 of amd64 installatie zou overal zijn packages moeten kunnen krijgen. De aanpassing aan sources.list zoals hieronder is vrij simpel.
deb http://cdn.debian.net/debian/ testing main
deb-src http://cdn.debian.net/debian/ testing main
deb http://security.debian.org/ testing/updates main
deb-src http://security.debian.org/ testing/updates main
Nu al enige tijd staat cdn.debian.net in mijn configuratie voor APT en ik moet zeggen dat ik voorlopig tevreden ben. Hopelijk wordt dit project verder uitgewerkt en opgenomen in zeg Debian 7.0, maar dan moet 6.0 wel eerst uitkomen natuurlijk.
In de afgelopen periode is SpamAssassin al meerdere malen aanbod gekomen en vooral in de context met Bayesian-filtering, maar er is nog veel meer. Zeker nu recentelijk release 3.3 het daglicht heeft gezien wordt het tijd om eens wat dieper in SpamAssassin te duiken.
Een van de grootste probleempunten met SpamAssassin was altijd de ruleset en de strijd met de spammers om die rules net te omzeilen. Bayesian-filtering lost een deel van dit probleem op, maar het andere probleem is de ruleset zelf. Voorheen werden rules met SpamAssassin meegeleverd en werden ze pas bijgewerkt als je een nieuwe versie van SpamAssassin installeerde. Het mag duidelijk zijn dat dit een onbegonnen strijd is, maar ook een gevaarlijke strijd. Zeker voor installaties die afhankelijk waren van DNS blacklists cq whitelists en waarbij de beheerder van de lijst besloot om zijn lijst op te heffen bijvoorbeeld.
De SARE-regels zijn een hele tijd populair geweest en zijn dat helaas nog steeds. Dit terwijl ze stelselmatig worden opgenomen in de ruleset van SpamAssassin zelf. Gelukkig heeft oa SARE er wel voor gezorgd dat er een update methode kwam die met de 3.3 release verplicht is geworden. Hiermee volgt SpamAssassin eigenlijk ClamAV in de voetsporen en is het verspreiden van een vaste ruleset overbodig geworden.
De eerste stap is eigenlijk heel simpel met het draaien van het commando sa-update als de gebruiker root op Debian. Als we nu in /var/lib/spamassassin/ kijken dan zien we het volgende:
$ ls -l /var/lib/spamassassin/ /var/lib/spamassassin/*/
/var/lib/spamassassin/:
total 8
drwxr-xr-x 3 root root 4096 2010-01-02 14:46 3.002005
/var/lib/spamassassin/3.002005/:
total 8
drwxr-xr-x 2 root root 4096 2010-01-02 14:46 updates_spamassassin_org
-rw-r--r-- 1 root root 2431 2010-01-02 14:46 updates_spamassassin_org.cf
We zien netjes de betreffende versie van SpamAssassin en in die directory de ruleset zoals die nu voor versie 3.2.5 wordt aanbevolen door SpamAssassin. Deze regels worden automatisch meegenomen als SpamAssassin de volgende keer start. Nu kan je zelf een paar regels in de crontab van de gebruiker root zetten, maar in Debian zijn al voorzieningen getroffen. Door het onderstaande aan te passen in het bestand /etc/dedault/spamassassin zal automatisch de sa-update worden gedaan en wanneer nodig SpamAssassin worden geherstart.
CRON=1
Helaas stopt hier het verhaal niet, want op dit moment worden services zoals Amavisd-new, die ook de SpamAssassin ruleset kan gebruiken, niet herstart. Op moment van schrijven staan bugs 315961 en 567205 hier nog over open. Totdat die zijn opgelost kan de volgende extra code geen kwaad aan het einde van /etc/cron.daily/spamassassin
test -f /var/run/amavis/amavisd.pid && /etc/init.d/amavis force-reload
Dit laatste is natuurlijk op eigen risico, maar het lost de bug voor mij al een redelijke tijd op.
Bij de introductie van Linux 2.6.32 is blijkbaar besloten om anders om te gaan bij bumps in de ABI en DKMS reageert daar nog niet goed op. Helaas merk je dit bij oa VirtualBox vrij snel en zo te zien zijn ze er nog niet uit hoe ze oa bug #563246 gaan oplossen. Het onderstaande commando zorgt voorlopig voor de juiste triggers om de modules opnieuw te laten genereren.
$ sudo apt-get install --reinstall virtualbox-ose-dkms
Misschien wordt het tijd om strikter de testing-tree te gaan volgen nu de freeze voor Debian 6.0 onderweg is.
DKIM aka DomainKeys Identified Mail is een alternatief op SPF aka Sender Policy Framework en hoewel het lastiger is op te zetten aan de verzenderkant is het wel goed te gebruiken als ontvanger. Zeker omdat oa grote partijen zoals Google en Yahoo het ook gebruiken om hun e-mail te versturen. Gelukkig zijn er ook steeds meer kleinere partijen die DKIM gebruiken.
Op Debian kan door het installeren van Mail::DKIM het oa worden gebruikt door SpamAssassin en Amavisd-new.
$ sudo apt-get install libmail-dkim-perl
Voor SpamAssassin om gebruik te maken van DKIM hoeft in het bestand /etc/spamassassin/v312.pre de volgende regel staan zonder #-teken ervoor.
loadplugin Mail::SpamAssassin::Plugin::DKIM
Je kan los een DKIM-proxy installeren om een header te laten toevoegen of de DKIM-signature voldoet, maar als je al al gebruikt maakt van Amavisd-new dan kan het al automatisch worden gedaan door Amavisd-new. Zorg dat in het bestand /etc/amavis/conf.d/50-user de volgende regel staan en herstart de daemon.
$enable_dkim_verification = 1;
Je zal nu zien dat de volgende regels zien verschijnen in /var/log/mail.log:
Dec 29 20:36:45 server amavis[7162]: Module Mail::DKIM 0.32
Dec 29 20:36:45 server amavis[7162]: DKIM code loaded
Als je bijvoorbeeld RoundCube gebruikt dat kan je met DKIM verification plugin de status automatisch laten weergegeven als de gebruiker zijn e-mail leest. Het zal je ook opvallen waar het voorlopig niet verstandig is om e-mail te rejecten op basis van een invalide DKIM signature. Bij sommige mailinglisten worden extra regels aan de body van de e-mail toegevoegd waardoor het signature niet meer valide is.
Recente reacties