Flag Mails received with TLS or IPv6

Flags in Thunderbird

Flags in Thunderbird

I just wondered how wide spread IPv6 and TLS are when receiving e-mails, so I wanted to quickly see which kind of transport an incoming mail used. I wanted to see it directly when it hits my inbox, so I adding a tag to the mail would be a sensible approach.

Since I’m running a quite common setup with Postfix, Dovecot and the usual stuff connecting into those two daemons, it wasn’t much work to do it.

Dovecot has the ability to filter and sort mails directly on the server using sieve. I have sieve up and running to sort mails from mailinglists into their corresponding folders and do stuff like that.

The best way to find out how an e-mail was received is to look at the „Received“ header:

Received: from sender.domain.invalid (sender.domain.invalid [IPv6:2001:db8:cofe::1])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by receiver.otherdomain.invalid (Postfix) with ESMTPS id 01D2C3E4A02
 for <nico@otherdomain.invalid>; Sun, 11 Jan 2015 17:24:17 +0100 (CET)

The header spreads across multiple lines and with (usually) tabs infront of the new ones. It tells us that the sending Mailserver was using IPv6 and TLS. Of course, sender.domain.invalid and receiver.otherdomain.invalid are only to demonstrate it. In reality, there should be your domain and the sender’s one.

Automatically detecting IPv6 is not so simple as one might think, the „Received“ line must include „IPV6:“ in it. But also, you want to make sure that it is only a hit, when the message was received by you via IPv6, not by one of the mailservers it might have passed earlier on its way through the internet.

There is a handy tool called regexr.com, where you can built and test regular expressions. It took me some minutes to make it work, without having long expression The IPv6 one can be seen here. You need to paste the received header from above, to see it work.

(from).+\[IPv6:.*(\s.*)*(by receiver\.otherdomain\.invalid)

First, we filter for „from“ and „IPv6:“ (the colon just to make sure that we don’t hit in a possibly wrong hostname) in one line, then after some more lines we filter on the receiving mailserver.

Of course, the sieve regex implementation has its own flavour of regular expressions, explained here, so I had to do some modifications to use them with sieve.

The TLS regex was on the same level of complexity. It’s that piece of regex.

(from).+\s+\(using TLS.*(\s.*)*(by receiver\.otherdomain\.invalid)

It also hits on „from“ but then searched fot the TLS header. Again, it also matches the receiving servers hostname. Sinve SSLv3 is broken and should not be used, I to only match TLS.

As linked earlier, the sieve regex has some own ways to find whitespaces or newlines, so have a look at the linked document, if you want to build your own expressions.

I did not want to modify the message but wanted to see the flags on a first glance, I did not want to add a pre- of suffix to the subject. I instead decided to use the colour flags Thunderbird can display. I do not use them normally so they are a good fit for that task. They can easily be removed afterwards, when stuff gets boring and everyone uses IPv6 and TLS 😉

The dovecot wiki lists the lables and the corresponding colours. I chose green for TLS and blue for IPv6. Usually they are used for „Personal“ and „ToDo“

To do the filtering, your sieve instructions file must require the modules „imap4flags“ and „regex“, otherwise it won’t work. My sieve config is like the following (but much longer with a lot more rules):

require ["imap4flags","regex"];
 # rule:[TLSTest]
 if header :regex "received" "(from).+[[:space:]]+\\(using TLS.+([[:space:]]*.*)*(by receiver\\.otherdomain\\.invalid)"
 {
 addflag ["$label3"];
 }
 # rule:[IPv6Test]
 if header :regex "received" "(from).+\\[IPv6:.*([[:space:]]*.*)*(by receiver\\.otherdomain\\.invalid)"
 {
 addflag ["$label4"];
 }

These regexes work quite well for me. You need to replace the domain „receiver.otherdomain.invalid“ with the one your mailserver uses. Until now, I had no false-negatives or false-positives. I’m not sure what happens when TLS is in one Received header, and my hostname in another. I think that sieve checks them one by one but did not challenge that. The one by one checking would make sense because the regex itself is only executed for „received“ headers, as you can see in the sieve rules.

Of course, other sieve plugings like fileinto“ can move mails to differend locations but I just wanted to observe the Mails coming into my inbox, with the new flag.

Mail with Flags

Mail with Flags

I renamed the two flags (or tags, as they are called in Thunderbird), just to have it a bit less tidy in my inbox.

How far TLS and IPv6 are spread. Right now I see a lot of TLS but nealy no IPv6, only from RaumZeitLabor and folks sorrounding it.

 

Nico

Debian Wheezy veröffentlicht

Nach einiger Zeit der Entwicklung ist am Sonntag die siebte Debian Version namens wheezy veröffentlicht worden.

Sie löst damit ihren Vorgänger squeeze nach etwa 2 Jahren ab. Debian wheezy war bisher als testing geführt worden und hatte hier in letzter Zeit schon eine recht hohe Stabilität gezeigt. Doch auch ein paar Bugs waren noch vorhanden, z.B. bei der Berechnung der Load in Verbindung mit KVM liefert der Kernel manchmal interessante Werte. Hier bleibt abzuwarten, wie sich die Anzeige nach dem Update verhält.

Debian wheezy setzt in alter Tradition eher nicht auf die neusten Versionen der Programme, verfolgt damit aber eine Strategie die auf Stabilität abzielt statt neuste Features. Wer unter Debian stable neuste Software will sollte auf die Debian Backports, Dotdeb oder andere Repositories setzen, die das entsprechende Programm anbieten.

Auf allen Servern die ich in den letzten Monaten neu installiert hab (z.B. mein Monitoring, der neue Server des RaumZeitLabors) läuft schon Debian wheezy, ein großes Update steht für mich trotzdem an: der Server auf dem dieses Blog läuft nutzt aktuell squeeze, welches bisher stable war. Im Zuge des Debian Updates werde ich die Daten wahrscheinlich auf einen neuen VPS umziehen, der mehr Leistung hat (4GB RAM statt 2GB, für den gleichen Preis). Meine Erfahrung bei Debian Updates ist zwar gut (besser als bei Ubuntu) aber es ist immer hilfreich, ein Backup zu haben 😉

Spamabwehr: SPF und Greylisting

Vor ein paar Monaten hab ich testweise SPF und Greylisting auf meinem Mailserver aktiviert. Doch, was ist das?

Fangen wir mit dem einfacheren von beidem an:

Was ist Greylisting?

Beim Greylisting werden einkommende E-Mails erstmals mit einem temporären Fehler abgewiesen. Versucht es der absendende Mailserver nach ein paar Minuten nochmals, wird die E-Mail akzeptiert (ich hatte dafür als Wartefrist mindestens 10 Minuten eingestellt). Dann wird der Mailserver auf eine Art Whitelist gesetzt (bzw. seine IP-Range, je nach Einstellung), auf der er auch bleibt, so lange er nicht 14 Tage am Stück keine E-Mails an meinen Server gesendet hat.

Die „Erfindung“ des Greylistings basierte auf der Annahme, dass Spammer es nicht nochmals versuchen, die Mail zuzustellen. Früher war das wohl auch richtig, Heute ist der Anteil an erfolgreich abgewehrten Spamnachrichten aber doch eher klein geworden, weil die meisten Spammer „vollwertige“ Mailserver einsetzen, die es auch wieder versuchen..

Es wurden zwar ein paar Spams abgewehrt, im Gegenzug verzögert sich aber auch die E-Mail Zustellung, sofern der Absender in letzter Zeit keine Nachricht an mich gesendet hat. Es nervt einfach auf Dauer, wenn man sich irgendwo Forum anmeldet, die Bestätigungsmail 10 bis 15 Minuten brauch und man in seinen Logddateien sieht, dass sein Greylisting daran schuld ist. Das wiegt die „paar“ abgewehrten SPAM Nachrichten nicht auf. Zu allem Übel nutzen Spammer heutzutage auch gerne mal gehackte Mailaccounts. Da bringt Greylisting auch nichts.

 

Die zweite „Nettigkeit“ die ich getestet habe war SPF.

Was ist SPF?

Für SPF erstellt man unter seiner Domain einen weiteren DNS Eintrag vom Typ TXT und dem Inhalt, welche IP-Adressen für diese Domain E-Mails absenden dürfen.

Der Eintrag sieht für mich so aus:

v=spf1 ip4:83.169.40.215 -all

spf1 steht für die SPF Version 1, das im Moment gebräuchliche. Danach folgt die IPv4 Adresse von meinem Server, dass dieser E-Mails in meinem Namen (also für Absender innerhalb meine Domain) absenden darf und ein „-all“. Letzteres heißt, dass sonst absolut kein anderer Mailserver E-Mails für die Domain vthadden.de verschicken darf. Ein Empfangender Mailserver prüft nun beim Erhalt von E-Mails, ob für diese Domain ein SPF Eintrag besteht, wertet ihn aus und befolgt ihn hoffentlich.

Statt „-all“ gibt es noch „~all“ und „?all“. „-“ heißt Hardfail, E-Mails ablehnen; „~“ steht für Softfail, in dem Fall würde es bedeutet dass die E-Mail wahrscheinlich nicht richtig ist, was damit passiert ist mir aber egal; „?all“ steht für „mir egal, wer was verschickt“, also wie wenn kein Eintrag gesetzt wäre.

Wie ihr schon seht: der Empfangende Mailserver muss SPF unterstützen, auswerten und auch befolgen. Machen viele aber nicht.

Google setzt SPF z.B. ein, mit einem „?all“ am Ende, also setzen sie es praktisch doch nicht ein. Bei eingehenden E-Mails werten sie den Eintrag aus und ignorieren das Ergebnis. Eigentlich müssten sie E-Mails ablehnen, die als Absender meine Domain haben aber nicht von meinem Server kommen. Tun sie aber nicht, eben nochmals von anderen Servern aus getestet, die E-Mail wird zugestellt.

web.de hat keinen SPF Eintrag, 1und1 nutzt aktuell ~all.

gmx.de hat einen SPF Eintrag, sogar mit -all, sie nutzen SPF also in diesem Sinne schonmal. Eingehende E-Mails von meinem DSL Anschluss werden schonmal direkt abgewiesen (bzw die Verbindung sofort getrennt), eine E-Mail von einem anderen Server aus wird aber angenommen und im SPAM Ordner abgelegt. Das wäre bei einem Softfail („~all“) akzeptabel, entspricht aber nicht dem bei einem Hardfail definierten verhalten, so ganz scheinen sie sich nicht zu trauen.

Selbst aol.com, die in Sachen Spambekämpfung einen eigenartigen Ruf haben hat ein „?all“ im DNS Eintrag. Von breiter Akzeptanz kann man wohl nicht sprechen. Paypal.com hat ein „~all“ eingetragen.

Manche Domains haben zwar ein -all eingetragen, aber deutlich mehr Hosts (IP-Adressen) erlaubt als meine Software auswerten konnte, wodurch die E-Mail auch abgewiesen wurde, twitter.com fällt z.b. hierunter, ob das Problem nur bei dem von mir benutzten ‚tumgreyspf‘ auftritt oder auch bei anderen Programmen weiß ich nicht.

Wo ist jetzt der Knackpunkt bei SPF?? Bei E-Mail Weiterleitungen. Theoretisch könnte/sollte man dafür den Absender umschreiben (indem man z.b. einen Envelope-From benutzt)

Ich habe z.b. noch eine E-Mail Adresse bei GMX, welche ich mir auf meinen Server weiterleiten lasse. GMX ändert aber den Absender nicht einwandfrei, wodurch z.b. eine weitergeleitete E-Mail von PayPal (ihr erinnert euch „-all“) abgewiesen wurde, weil GMX nicht authorisiert ist E-Mails für PayPal abzusenden.

Afterbuy versendet seine E-Mails z.b. im Namen und mit dem Absender des Shops, der afterbuy nutzt. Hat dieser eine GMX Adresse wird diese E-Mail mit hoher Wahrscheinlichkeit auch abgewiesen, jenachdem wie das „~all“ interpretiert wird.

Dies sind jetzt nur 2 Beispiele die ich auf Anhieb (also ohne große Suche) in meinen Logdateien gefunden habe. Weitere würde ich sicher finden.

Eine weitere mögliche Fehlerquelle sind natürlich noch falsche DNS einträgt, die man z.B. nach einem Serverumzug nicht korrigiert oder ergänzt.

Also gilt für SPF (in meinem Falle) das Gleiche wie für Greylisting: Ja, es kann Spam abwehren, im Gegenzug kann es aber auch erwünschte E-Mails blockieren. Die paar False-positives (fälschlicherweise abgewiesene Mails) die ich hatte, waren aber trotzdem ärgerlich, sie kamen zwar durch falsche Konfiguration anderer Mailserver zustande, treffen mich aber trotzdem.

Fazit:

Greylisting hat früher viel gebracht, heute überwiegen aber die Nachteile. SPF ist im Ansatz zwar „schön“, weil man damit einschränken kann, wer in wessen Namen E-Mails veschicken darf, in der Praxis ist es aber entweder schlecht implementiert oder garnicht eingerichtet. Auch hier überwiegen im Moment die Nachteile.

Ich für meinen Teil bleibe weiterhin aus der Kombination von ix-DNS Blacklist und Spamassassin, den ich aus meinem Spamordner regelmäßig anlerne. Diese beiden „Hürden“ leisten bei mir seit langer Zeit eine gute Arbeit, verbessern kann man da wohl nicht mehr sehr viel ohne mehr False-positives zu bekommen (diese bewegen sich im Moment irgendwo im Promille Bereich).

Open-to-wipe Samsung Galaxy Series (english version)

German version is: here.

Someone just posted a nice way to wipe a Samsung Galaxy S3 without any call backs. Since the original source I’ve got via twitter is gone, here is a thread about it: http://forum.xda-developers.com/showthread.php?p=31994542 and here the YouTube video, which demonstrated it on a conference: http://www.youtube.com/watch?v=Q2-0B04HPhs

This is proved to work not only on Galaxy S3 but also on Galaxy S2 devices (test by me and others). I think all Samsung Android ROMs will behave like this.

For testing porposes, I will link to tias tweet which links to his demopage. This demo will wipe (at least S2 and S3 devices) witout any user interaction when opened on your phone!!!

https://twitter.com/tsia/status/250566154165301248

This demo will wipe (at least S2 and S3 devices) witout any user interaction, when opened on your phone!!!

The USSD code used (*2767*3855#) will also work when tramsmittes via MMS or coded in an NFC tag, but a web page has a lot more power than a single MMS. As it seems, there is no way to protect yourself against it, than not surfing any websites on your phone.

If you want to test if your phone also has this vulnerability, you can grab tsias source code and modify it for another USSD code which is more harmless, e.g. the one showing your IMEI number: *#06#.

I think you’d better have a backup of your phone. I love TitaniumBackup on Android for that job.

Update: This seems only to factory-reset your phone, not to wipe it completely. Media stored on the sd-card is not deleted, as mentioned on twitter:

SMTP Ports 25 und 587

Wenn man jemandem nach dem SMTP Port fragt ist die Antwort meistens „25/tcp“. Manchmal hört man noch „465/tcp“ für SMTPS. Der Port darf dafür aber eigentlich nicht mehr verwendet werden (seit 1998), stattdessen soll STARTTLS über den normalen SMTP Port verwendet werden.

Seit einigen Jahren wird bei manchen ISPs, wenn man eine Einwahlverbindung (wie z.B. DSL) nutzt, der Port 25 für Verbindungen gesperrt, bekannt hierfür ist unter Anderem die Telekom. Diese Anbieter sperren bei Verdacht auf den Spamversand den Port 25 für ausgehende Verbindungen einzelner DSL Anschlüsse. Wie dies überprüft wird weiß ich nicht.

Als neuer Port für entsprechende Client zu Server Verbindungen wurde der Port 587/tcp definiert. Der Dienst hierzu heißt „Submission“ und sieht laut RFC 2476 die Authentifizierung der User vor. Dies heißt, dass jegliche Server zu Server Verbindungen weiterhin über Port 25 erfolgen, die Clients sich aber auf Port 587 verbinden müssen/sollen.

Wie hier berichtet will Südkorea nun für „Endkunden“ den Port 25 sperren. Sie Planen ähnliche Sperren wie bei der Telekom, die Server zu Server Kommunikation soll weiterhin über Port 25 laufen. Die Sperre soll den Versand von Spamnachrichten erschweren. Hier für muss man sich überlegen wie der E-Mail Versand normalerweise abläuft.

Der Enduser der eine E-Mail versenden will sendet diese z.b. mittels Thunderbird. Thunderbird verbindet sich auf den Mailserver des Anbieters von dem man eine E-Mail Adresse hat (bei mir ist es mein eigener Server), authentifiziert sich mit Usernamen und Passwort und reicht die E-Mail Weiter. Der Mailanbieter ist in dem Fall der Smart Host bzw. das Relay welches die Nachrichten weiterleitet.. Er nimmt die E-Mail an, schaut an wen sie zugestellt werden soll und verbindet sich mit dem Mailserver des Zielanbieters (z.b. gmx, gmail und co). Dieser Server nimmt die E-Mail nun ohne Authentifizierung an, da er für die Zieldomain zuständig ist und stellt die E-Mail nun lokal zu.

Das Grundprinzip ist also: Für Nachrichten die an andere Mailserver weitergeleitet werden sollen sollte man sich authentifizieren. Ist der Mailserver aber für die Zieldomain zuständig ist keine Authentifizierung notwendig und die E-Mail wird direkt angenommen. Meistens werden noch weitere Dinge, wie IP-Adresse und Domain des Absenders überprüft (ob der DNS richtig eingetragen ist) bzw. auch die IP-Adresse mit einer Blacklist abgeglichen.

Welche Wege gibt es nun Spamnachrichten zu versenden:

– Normale, virenverseuchte, PCs die direkt Verbindungen mit des Zielservern herstellen und die Spamnachrichtenversenden

– gehackte/verseuchte Server bzw. fehlerhaft konfigurierte Server, die Nachrichten direkt zustellen

– gehackte Useraccounts bei Mailhostern

Das Sperren von Port 25 greifen effektiv nur bei der ersten Gruppe. User die Einwahlverbindungen benutzen können bei entsprechenden Sperren E-Mails nicht direkt zustellen sondern dafür einen Smart Host verwenden, z.B. den ihres Mailanbieters. Der normale Internetuser macht dies auch so, er würde bestenfalls wahrscheinlich nichts von den Sperren mitbekommen, sofern er seinen E-Mail Client richtig konfiguriert hat und den Port 587 zur SMTP Kommunikation einsetzt. Bietet der Mailanbieter den Versand über den Port 587 nicht an, bleibt nur noch der (veraltete) Port 465 für SSL, welcher meistens auch unterstützt wird. Der Virus auf dem Rechner versucht dagegen die Zielsysteme zum Zustellen der Spamnachrichten direkt zu erreichen und wird durch die Sperre davon abgehalten. Die Kommunikation über Port 587 sollte nicht möglich sein, da auf dem Port grundsätzlich eine Authentifizierung vorgesehen ist. Hier setzen allerdings auch schon DNS Blacklisten an, die häufig entsprechende IP-Adressbereiche die zur dynamischen Vergabe vorgesehen sind bzw. Spamnachrichten versenden listen, wodurch Mailserver unautorisierte E-Mails von entsprechenden IP-Adressen nicht annehmen sollten.

Die zweite Gruppe kann man damit nicht blockieren. Hier hilft nur der Ansatz der DNS Blacklisten, der auch schon bei Gruppe 1 hilft. Falsch konfigurierte Server nehmen von unautorisierten Usern nicht nur E-Mails zur lokalen Zustellung an sondern leiten diese auch ohne Authentifizierung an andere Mailanbieter weiter.

Die dritte Gruppe der Absender kann man als Zielsystem der Spamnachricht bisher nicht effektiv blocken. Für alle Beteiligten ist die Nachricht nicht ohne weiteres von einer legitimen Nachricht zu unterscheiden. Hier ist man auf die Kooperation der Mailanbieter angewiesen, bei denen der gehackte Account registriert ist.

Die RFC für Port 587/tcp sieht ausdrücklich vor, dass auf diesem Port nur von autorisierten Benutzern Nachrichten angenommen werden sollen, eine Server zu Server Kommunikation soll hierüber nicht erfolgen. Ein richtig konfigurierter Mailserver sollte sich hieran auch halten, fehlerhaft konfigurierte Server sind aber immer noch ein Problem. Die Chance, dass ein Admin den Port 587 genauso falsch (also komplett ohne Authentifizierung) konfiguriert wie schon den Port 25 ist durchaus gegeben. Hier helfen also wieder „nur“ Blacklists.

Eine Sperre des Ports 25 für Client zu Server Verbindungen ist nicht selten, von daher auch nicht weiter tragisch. Server zu Server Verbindungen darüber auch zu sperren würde allerdings keinen Sinn machen. Einerseits weil man damit gegen die RFC verstößt, andererseits weil Spammer nicht so unflexibel sind wie manch einer vermutet und rasch auf andere Ports ausweichen würden. Die Server zu Server Verbindung auch mit Passwörtern abzusichern ist nicht machbar. Weitere Sicherungsmaßnahmen zum Authentifizieren des Absenders werden zwar teilweise eingesetzt, meistens funktionieren sie aber nicht richtig oder sind nur halbherzig implementiert wodurch sie größtenteils nutzlos sind. (Oh, ich dachte den Beitrag dazu hätte ich schon veröffentlicht.)

Es bleibt abzuwarten, wie groß der Effekt der Portsperren beim Spamaufkommen sein wird. Ich selbst erwarte mir hiervon keinen merklichen Unterschied. Die meisten der ankommenden Spamnachrichten werden bei mir durch die NiX Spam DNSBL (Infos hierzu). Die wenigen Nachrichten, die es zum Spamassassin schaffen, kommen meistens von gehackten Useraccounts, hier werden die Sperren keinen Unterschied machen.

Nachtrag: Wenn man keine DNSBL verwendet kommt natürlich mehr Spam durch. Es gehen also schon noch einige direkt über Einwahlanschlüsse raus, so gesehen würde durch eine Sperre von Port 25 das Problem schon etwas abgeschwächt werden. Der Großteil der Nachrichten kommt aber eher von falsch konfigurierten Servern und von gehackten Useraccounts.

IPv6 Zertifizierung und die glue Records

Hurricane Electric, ein ISP aus den USA, bietet als (im Moment) einer der größten IPv6 Backbone Provider einerseits kostenlose IPv6 Tunnel (http://tunnelbroker.net, benutze ich selbst u.a. auch), aber auch eine IPv6 Zertifizierung an.

Die Zertifizierung ist kostenlos und besteht aus theoretischen und praktischen Aufgaben. Im Praktischen Teil muss man einen Server in mehreren Schritten komplett IPv6 fähig machen, der letzte Schritt ist die Eintragung von IPv6 glue Records bei der Domain Registrierunsstelle.

Ein glue Record enthält die IP Adresse zu dem Nameserver, der für eine Domain zuständig ist. Der Eintrag ist notwendig , wenn der Nameserver unter der gleichen Domain läuft als die Domain, die man auflösen möchte.

Für mich und meinen Server heißt das:

Meine „Haupt“ Domain, unter der ich die meisten Services laufen lasse ist 4nx.de.

Mein primärer Nameserver „hört“ auf den Namen ns1.4nx.de und gehört damit dieser selbst an. Dadurch muss bei der Denic direkt hinterlegt sein, unter welcher IP-Adresse dieser Nameserver erreichbar ist. Diesen Eintrag nennt man dann glue Record.

Um bei der IPv6 Zertifizierung den höchsten Grad zu erreichen, muss man seine Domain mit diesen Einträgen ausstatten. Alle vorherigen Schritte habe ich schon letztes Jahr gemacht. Diesen letzten erst gestern, aus einem einfachen Grund: Weiterlesen

Mittwoch ist IPv6 Tag

Ja, am Mittwoch ist es so weit.

Geplant ist, dass Google, Facebook, Akamai und viele andere Betreiber von Diensten im Internet ihre Dienste auch regulär per IPv6 zur Verfügung stellen.

Google macht das bisher unter http://ipv6.google.com und für User bestimmter Netzwerke/DNS Server auch auf http://google.com

„Normale“ Internetnutzer bekommen dagegen keine IPv6 Adressen für Webseiten zurückgeliefert von Googles Nameserver. Damit wollen sie Problemen aus dem Weg gehen, die einige ältere Betriebssysteme (und manche Router) haben beziehungsweise haben könnten.

Facebook und co handeln ähnlich.

Anders wird es diesen Mittwoch sein. Am Mittwoch werden die Fragen nach IPv6 Adressen für Google, Facebook etc beantwortet und der Computer könnte die Webseite per IPv6 erreichen, sofern er per IPv6 angebunden ist, man kann auch Parallel IPv4 und IPv6 benutzen, meistens wird IPv6 bevorzugt wenn eine Webseite beides unterstützt. Wenn nicht sind alle aktuellen Betriebssysteme so clever es auch nicht zu versuchen sondern benutzen direkt IPv4.

Ich für meinen Teil setze IPv6 (zuhause zwar mit Tunnel) seit über einem Jahr ein und hatte bisher keine Probleme damit. Alle meine Server sind (mittlerweile nativ) IPv6 fähig und auch auf dieser Webseite ist es aktiviert. Rechts in der Spalte hab ich eine kleine Box eingebaut, die anzeigt ob man per IPv4 oder IPv6 hier ist.

Von Daher: Wenn du diese Webseite lesen kannst und bei dir keine Fehler auftreten dann wirst du wahrscheinlich auch keine Probleme am IPv6 Tag am Mittwoch haben. Wenn du diese Webseite nicht lesen kannst… Wenn bei dir Probleme mein Laden aufgetreten sind, dann lass es mich wissen 😉

Manche sehen im IPv6 Day zwar nur eine Alibiaktion, ich habe aber die Hoffnung, dass ein positiver Ausgang die Einführung von IPv6 beschleunigt.

Viele Firmen haben noch Hemmungen vor IPv6 bzw sehen keinen Nutzen darin (ok, darüber kann man sich streiten wenn man will). Von daher bin ich gespannt was am Mittwoch herauskommt, vielleicht ist IPv6 ja gar nicht so „schlimm“ wie bisher befürchtet 😉

 

Nachtrag: Christoph hat auch noch ein paar Worte dazu geschrieben

Mailgraph probleme

So langsam mal dafür sorgen, dass die Stille hier im Blog verschwindet (oder wenigstens versuchen) 🙂

Wie geplant hab ich den Server in der Nacht auf Montag (letzte Woche) umgezogen, hat soweit alles geklappt nur ein Script macht Probleme:

mailgraph – ein Script welches mit Hilfe von RRDtool Statistiken zu meinem Mailserver erstellt.

Ich weiß noch nicht woran es liegt, jedenfalls meint das Script „ein paar“ Dateien zu öffnen, bei 16.700 ist dann das Limit erreicht und der Kernel macht dicht, nichts geht mehr (bis ich das Script abwürge). lsof kann auch nicht ausgeführt werden (während mailgraph läuft) , sonst wüsste ich welche Dateien der mailgraph öffnet.

Versuche mit ‚ulimit -n 3000‘ die Zahl der maximal offenen Dateien auf 3000 zu reduzieren haben nicht funktioniert, wurden einfach ignoriert (oder überschrieben, wie auch immer…)

Ich werde die Tage mal wieder danach schauen, in der Hoffnung den Fehler irgendwann zu finden (das dann aber erst mal in einer Lokalen – vergleichbaren – VM), vielleicht liegt es daran, dass ich die „alten“ rrd Tabellen einfach auf den neuen Server kopiert habe, glaube und hoffe ich aber nicht.

Falls jemand eine Idee hat woran es liegen könnte bin ich für Vorschläge offen ^^

Vorbereitungen zum Serverumzug

Ich hab ja schon nicht mehr damit gerechnet, aber heute Nacht um 00:04 Uhr bekam ich von Hosteurope die E-Mail mit den Zugangsdaten zum neuen Server.

Größte änderung (nach außen hin): komplett neues IP-Netz (vorher hatte ich immer eine IP aus dem Netz 87.230.0.0/17, diesmal ist es 83.169.0.0/18), irgendwann ist auch jedes Netz mal voll.

Größte Änderungen „innendrin“: neuerer Kernel 2.6.18 statt vorher 2.6.9, mehr Ressourcen und Speicher

Umziehen werde ich dann wahrscheinlich in der Nacht auf Montag, ist aber noch nicht komplett sicher (hab ja eine Woche Zeit dafür), Konzept steht größtenteils

Vielleicht bekomm ich mit dem neuen Kernel auch einen IPv6 Tunnel hin, um den Server darüber erreichbar zu machen 🙂

Nachtrag: hat alles gut geklappt, bis auf mailgraph, dazu gleich mehr