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:

Open-to-wipe Samsung Galaxy Serie

English version is: here.

Eben hat jemand eine schöne Möglichkeit gepostet, wie man ein Samsung Galaxy S3 ohne Rückfrage wipen kann. Leider ist die Quelle schon wieder gelöscht, aber es gibt ja noch andere Quellen, wie z.b. dieser Forenthread zu dem Thema: http://forum.xda-developers.com/showthread.php?p=31994542. Hier gibt es noch ein YouTube Video der Demo http://www.youtube.com/watch?v=Q2-0B04HPhs.

Betroffen ist davon nicht nur das Samsung Galaxy S3 sondern mindestens auch das S2 (von mir eben getestet mit Android 4.0.3). Ich vermute mal, dass alle aktuellen Samsung Android ROMs betroffen sind.

Zum Testen verlinke ich mal auf den tweet von Tsia, der das mal als Webseite eingestellt hat: https://twitter.com/tsia/status/250566154165301248

Dort findet sich der Link auf seine Testseite. Ich verlinke absichtlich nicht direkt drauf, weil “bestenfalls” euer Gerät direkt und ohne Rückfrage gelöscht wird. Ein “mimimi, ich dachte da kommt eine Rückfrage” will ich nicht hören ;-)

Das ganze funktioniert natürlich auch als MMS, NFC Tag und so, aber als Webseite mit Frame hat es viel mehr charm. Der dazugehörige USSD Code lautet: *2767*3855# (auch hier: Das Gerät wird ohne Rückfrage gelöscht)

Wer testen will, ob ein Gerät auch anfällig für solche Angriffe ist kann den Quellcode von Tsias Seite mal auf einen harmloseren USSD Code abändern. (z.B. den zur Anzeige der IMEI: *#06#).

Wie immer in der IT gilt auch für Smartphones: Wer kein Backup hat, hat pech gehabt. Für Android kann ich hier TitaniumBackup empfehlen.

Update: Über Twitter hat mich gestern die Nachricht erreicht, dass hier kein kompletter wipe durchgeführt wird sondern “nur” ein factory reset, der zum Beispiel die SD Karte nicht formatiert.

CyanogenMod 10 Nightlies angekündigt

CyanogenMod hat eben angekündigt, heute Nacht die ersten “offiziellen” Nightlies zu compilieren und dann auf http://get.cm zu veröffentlichen.

Ich hab seit einigen Tagen schon eine Vorabversion von CM10 auf meinem Nexus S und bin sehr zufrieden damit. Es läuft ohne Probleme und Android 4.1 mit Google Now ist einfach gut gemacht.

Ich bin gespannt, was sich zwischen dem schon 2 Wochen alten Build und den nun erscheinenden Nighlies alles verändert hat. Morgen weiß ich mehr :-)

Disclaimer: Nighlies können gravierende Bugs enthalten. Zur Installation muss unter Umständen das Handy komplett gelöscht werden. Man sollte sie nur installieren wenn man ein Backup hat und weiß was man tut!

Twitter und seine Clients

Twitter hat heute massive Änderugen an der Twitter API endgültig angekündigt. Nachdem es schon früher Hinweise gab, dass die API stark eingeschränkt werden soll wurde dies nun heute konkret veröffentlicht: https://dev.twitter.com/blog/changes-coming-to-twitter-api

Primäres Ziel der Einschränkungen sind 3rd-party Twitter Apps. Die Apps die Twitter eigentlich erst so populär gemacht haben.

Auf Android nutze ich seit langem Twicca, auf Symbian hatte ich Gravity (an den bisher auch imho nichts annäherungsweise heran gekommen ist auf Android) und noch davor hatte ich irgendwas anderes gehabt. Auf dem iPad nutze ich im moment die originale Twitter App, das was sie soll kann sie dort. Auf Android hingegen stört mich irgendwie alles an ihr. Auf dem PC hatte ich lange Zeit TweetDeck, bis Adobe den Air Support für Linux eingestellt hat. Neben den aufgelisteten Apps gibt es noch viele weitere, man hat eine echt große Auswahl.

Und genau diese App vielfalt will Twitter nun einschränken, wenn möglich wohl sogar komplett abschaffen. Die Realtime bzw Streaming API gabs ja schon nur in sehr wenigen Anwendungen und ich vermute, dass diese Zahl nun nicht mehr zunehmen wird.

Twitter will keine Apps haben, die das Verhalten der original Twitter-App Nachahmen. Ich finde nicht, dass Twicca und Gravity dies tun. Ja, man kann mit fast allen Clients auch tweets absenden. Twicca kann man im Gegensatz zur original App aber mit einer stattlichen Anzahl Plug-Ins erweitern. Man kann fast alles anpassen, was irgendwie geht. Gravity hingegen kann sehr komfortabel mehrere Accounts gleichzeitig verwalten und unterstützt die Realtime API.

Twitter will seine API Ausrichtung nun mehr auf Firmenkunden und andere Dienste ausrichten und “Klone” ihrer App eher aus dem Weg räumen.

Und ja, Twitter ist in ihrem Bereich Marktführer. Nokia war auch mal Marktführer bei Smartphones, wie AOL bei fast allem was im Internet damals passierte. Vor einigen Jahren war da auch noch StudiVZ. Twitter sollte aufpassen, dass sie nicht die vergraulen, die ihnen mit ihren Daten die Einnahmen ermöglichen: die User.

Verdächtigkeit von Facebook-Verweigerern

Aktuell kommt mal wieder ein bekanntes Thema in den Vordergrund: Machen sich Facebook-Verweigerer verdächtig? Viele Onlinemedien aus den verschiedensten Ländern berichten darüber und verweisen auch gerne darauf, dass Personalabteilungen eine Online-Abstinenz auch sehr verdächtig finden.

Fast alle Artikel haben eins Gemeinsam: Sie stellen das Verweigern von Facebook mit einer kompletten Abstinenz aus dem Internet gleich. Für viele von ihnen besteht das Internet entweder ausschließlich aus Facebook, oder sie unterstellen das jedenfalls dem normalen Leser.

Ich bin nicht auf Facebook, aber nicht weil ich kein Bock auf das Internet hätte sondern einfach weil mir die durchführung von ihrem Geschäftsmodell nicht passt. Ich will nicht alle 3 Tage nachschauen müssen ob die privacy Einstellungen noch so sind wie ich sie gerne hätte, oder ob Facebook diese mal wieder “optimiert” hat und dadurch mehr öffentlich ist als ich möchte. Dafür bin ich bei Twitter, Google+, Xing, in verdiedenen Foren und Mailinglisten, nutze Jabber und Skype, blogge ab und zu und verbringe auch sonst sehr viel Zeit mit Systemen im Netz.

Bin ich trotzdem verdächtig, nur weil ich Facebook nicht Nutze? Das Netz kann viel mehr bieten, als nur Facebook.

Gnome 3

Seit Gnome 3 endlich final erschienen ist benutze ich es. Gnome 3 beobachte ich schon recht lange, vor einiger Zeit hatte ich sogar mal kurz einen pre-alpha built installiert, der zwar nicht stabil war aber wenigstens kurz zeigen konnte, auf was man sich bei der neuen Oberfläche freuen kann :-)

KDE 4 war zwar “ganz nett” aber auf dauer war ich irgendwie genervt davon. Es fühlte sich meistens sehr zäh und irgendwie unrund an. Noch dazu machte KDE 4 bei meinen Monitoren nur Probleme im dual Monitor Setup. Ich konnte es zwar aktivieren, nach einem reboot waren aber die einstellungen so defekt, dass sich die Oberfläche auf einen 5cm breiten Streifen erstreckte (mit voller Auflösung) und der Rest schwarz war*. Es dauerte meistens ein bis zwei Tage bis es richtig lief. Gnome 2 war im allgemeinen zwar auch okay aber schon sehr in die Jahre gekommen und mir irgendwann zu langweilig.

Mein Unmut über die aktuellen Desktopumgebungen wurde noch größer, als Ubuntu bzw Canonical anfingen die Oberflächen auf eigene Faust zu “verbessern”. Angefangen mit den Fensterbuttons oben links (oder war das schon der zweite Streich den ich korrigieren musste? Ich weiß es nicht mehr) die einfach aus meiner Sicht dort falsch sind. Direkt über dem Menü den schließen Button anzuordnen war für mich eher ein Bug als ein Feature, viel zu leicht konnte man sich verklicken und das Programm schließen statt das Menü zu öffnen. Das nächste Feature was dann an OS X angelehnt wurde (für mich sieht es jedenfalls sehr danach aus) war das globale Menu in der Leiste am oberen Bildschirmrand. Damit wurden die Fensterbuttons links zwar wieder benutzbarer aber für mich war es trotzdem ein reinfall.

Die Bedienung bei OS X mit der Menüleiste oben ist angenehm und nach kurzer Umstellung hat man sich auch dran gewöhnt. Bei OS X gehört es dazu und ist im System komplett “drin”. Bei Ubuntu dagegen war es nachträglich hinzugefügt und eckt überall an. Es war nicht Einheitlich, manche Programme kamen damit klar, andere hingegen nicht. Am Ende stand man vor einem inkonsistenten Bedienkonzept. Für mich keine Alternative. Dass das Menü ausgeblendet wird wenn es nicht benutzt wird war zwar auch eine nette Idee, ich frage mich aber immer noch: wozu?

Noch dazu konnte Unity nicht sinnvoll mit mehreren Monitoren umgehen. Die Leiste am linken Rand hat mich auch gestört. Meine Meinung nach ist es für Netbooks zwar gut geeignet, aber auf einem 24″ Monitor möchte ich es nicht.

Mit gnome3 wurde in meinen Augen alles besser. Die Bedienung ist durchdacht, die Systemfunktionen sind gut integriert. Wenn eine IM reinkommt, muss ich nicht zwingend das Chatfenster öffnen sondern kann direkt in der Benachrichtigung am unteren Bildschirmrand antworten. Wenn eine verschlüsselte Festplatte angesteckt wird kann ich in der Benachrichtigung über den neuen Datenträger das Passwort eingeben und sie wird eingebunden. Dual Monitor hat bei mir bisher keine Probleme gemacht, es funktioniert einfach.

Es gibt zwar noch ein paar Stellen an denen geschraubt wird (der Netzwerkmanager könnte noch etwas Pflege gebrauchen) aber im großen und ganzen bin ich im Moment sehr zufrieden.

* Nachtrag: Der Fehler hat mich richtig genervt, als ich im September eine SSD geliehen bekommen hatte und Kubuntu darauf installieren wollte. Nach einer Stunde des (erfolglosen) Probierens hab ich dann Windows 7 darauf installiert. Das hat wenigstens funktioniert. Der Fehler war gefühlt nicht von KDE sondern durch die Anpassungen von Canonical. Später hab ich das gleiche mit KDE bei Fedora getestet und hatte den Fehler nicht gehabt. An der Stelle war Kubuntu für mich vorerst gestorben.

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.

Android 4.0 und das Galaxy Nexus

Heute wurde von Samsung und Google die neue Android Version 4.0 Icecream Sandwich und das neue Google Handy Galaxy Nexus aka Nexus Prime vorgestellt.

Die neue Android Version sieht sehr schick aus (Heise Artikel dazu). Einige Features wurden bei bisherigen Android Versionen vermisst, wie z.B. Screenshots. Diese funktionieren bisher nur mit Modifikationen der OEM Hersteller (HTC hatte es z.b. Nachgerüstet), mit Root oder mit Custom ROMs. NFC wird auch erweitert und bekommt eine “Beam” Funktion, um schnell Daten mit anderen Android 4.0 Geräten zu Tauschen.

Steven von MobilityMagazin.de hat hier eine schöne Zusammenfassung der neuen Features.

Das Galaxy Nexus fällt wie erwartet aus: Dual Core, größerer Bildschirm der den Wegfall der Sensortasten kompensiert (sie werden jetzt im Bildschirm angezeigt), LTE, Full-HD Videoaufnahmen (das Nexus S hat nicht mal 720p), 720p HD Display, noch dünneres Gehäuse. Das Curved Design wird beibehalten, was mich persönlich Freut.

Der Heise Artikel erwähnt im Gegensatz zu anderen Seiten nur WLAN b/g/n, das 5Ghz a-Band soll aber auch Unterstützt werden (wird z.B. hier geschrieben). Das a-Band macht an Orten mit starker WLAN Abdeckung Sinn. Die Bandbreite der Luft als Medium ist für jede Frequenz beschränkt. Je mehr WLANs auf einer Frequenz arbeiten, desto weniger Bandbreite bekommt jeder Nutzer. im 2,4Ghz Bereich sind in Städten einerseits schon sehr viele Access Points vorhanden, andererseits gibt es auch ziemlich starke Überlappungen zwischen den 13 nutzbaren Kanälen. Im 5Ghz Bereich ist dagegen noch sehr viel mehr Platz, unter Anderem auch weil es dort mehr verfügbare Kanäle gibt.

Ich persönlich bin sehr auf das Galaxy Nexus gespannt. Ich werde es mir zwar nicht kaufen, will aber Wissen wie die Verarbeitung ausfällt. Samsung hat sich in meinen Augen in letzter Zeit nicht mit Ruhm bekleckert. Zu viel Plastik, zu viel Knarzen und Knacken im Handy. Mein Nexus S gefällt mir zwar von den Funktionen her ganz gut (NFC z.B.), die Verarbeitung ist bei HTC Geräten aber meiner Meinung nach besser. Dazu kommt noch, dass ich den GPS Empfang von meinem E71 gewöhnt war, was Nokia deutlich besser hinbekommen hat (dazu kommt wahrscheinlich noch ein Beitrag irgendwann). Ich persönlich finde den Namen Galaxy Nexus auch unglücklich gewählt. Nexus Prime wäre passender und schöner, die Galaxy Serie ist in meinen Augen zu negativ Vorbelastet. Einerseits weil mir persönlich Galaxy S und S2 nicht gefallen, andererseits durch den Patentstreit mit Apple, bei dem es in erster Linie um Geräte der Galaxy Reihe geht. Auch “erwartet” der Käufer bei Galaxy Geräten die Samsung TouchWiz Oberfläche, die beim Nexus ja (imho zum Glück) fehlt. Andererseits kann man auch sagen “Namen sind Schall und Rauch”, es kommt auf die Funktionen und die Hardware an. Gespannt bin ich auch auf die Dicke und Haptik des Gerätes, das Galaxy S2 ist gefühlt zu Dünn geraten, abwarten :-)

Nicht ganz so Lange werde ich (hoffentlich) für Android 4.0 warten müssen. Ich gehe davon aus, dass das Update noch vor Weihnachten kommt. Root sollte dann auch recht schnell verfügbar sein.

Was ist eure Meinung zum neuen Nexus und zu Android ICS?

Nachtrag: Wie Heise berichtet soll das Android 4.0 Update für das Nexus S wohl im Dezember kommen. Demnach habe ich garnicht so schlecht geschätzt, dass es vor Weihnachten kommt. Wann das Update aber per OTA hier in Deutschland angeboten wird ist so eine Sache. Google rollt das Update immer nach und nach aus, wobei man das Update auch manchmal von Hand machen konnte.