Dass das mobile Zeitalter bereits da ist, merkt man am grossen Angebot der Endgeräte. IPhones, Blackberrys, Palms usw. Die Netzbetreiber locken mit immer erschwinglicheren Angeboten. Es gibt sogar eine .mobi Domainendung.

Durch immer grösser werdende Handydisplays und ausgereiften Bedienmöglichkeiten wird es auch immer einfacher Internetseiten zu benutzen. Dabei spielt es kaum eine Rolle, wie „gross“ sie sind. Dank Zoomfunktionen, kann man trotzdem alles gut erkennen.

Ich will hier aber nicht von den Fähigkeiten der Handys reden, sondern von den Möglichkeiten der mobilen Internetseiten.

Was haben Sie denn nun für Vorteile?

• Meistens einfache zu bedienen/navigieren..
• In der Regel werden weniger Daten übermittelt, was kürzere Ladenzeiten zur Folge hat.
• Die Inhalte sind meistens auf das Wesentliche reduziert
• Man respektiert die „reduzierten“ Möglichkeiten der Mobiluser.

Auf was sollte man bei einer mobilen Version achten?

• Der Inhalt sollte für mobile Endgeräte entwickelt worden sein.
• Javascript und Flash sollte man möglichst verbannen.
• Wenige Bilder, da es die zu übertragende Datenmenge „unnötig“ aufbläht.
• Keinen „Schnickschnack“ auf der Seite.
• Grosse Schaltflächen und Eingabefelder, da meist über Touchscreens bedient wird.

Wer sollte eine mobile Internetseite betreiben?

• Suchmaschinen.
• Nachrichtenseiten.
• Banken (aber ohne den Bereich Onlinebanking).
• Blogs mit Ihren Einträgen in Listenform.
• Öffentliche Einrichtungen wie die Post und Ämter um Informationen wie Öffnungszeiten und Preise anzubieten.
• Bus-, Bahn- und Fluglinien.
• Ärzte und Krankenhäuser mit Ihren Öffnungszeiten und Notfallrufnummern.
• Hotels, Restaurants und Kinos, um schnelle Reservierungsmöglichkeiten zu bieten.
• Wetterseiten.
• Karten- und Navigationsdienste.
• Micropayment-Anbieter.

Ich werde mir zu diesem Thema weiterhin Gedanken machen und wahrscheinlich einen weiteren Artikel darüber schreiben, wie man seinen Blog in einer mobilen Version ausliefern kann.

Habe ich etwas vergessen? Wenn, ja, dann freue ich mich über ein paar Kommentare.

Bis zum nächsten Artikel,

Patrick

Wer das Apple Betriebssystem OSX 10.6 (Snow Leopard) benutzt und Skype 2.8, könnte evtl. Probleme mit der iSight Kamera vom iMac bekommen. Dafür ist ein Codec von Quicktime verantwortlich. Dieser scheint nicht kompatibel mit dem neusten OSX von Apple zu sein. Sobald Skype eingeschaltet wird funktioniert der Videochat nicht mehr. Anstatt der Bildübertragung sieht man nur noch einen grünen Bildschrim. Folgende Lösung erscheint mir am sinnvollsten und funktioniert auch wirklich.

1. Skype schliessen.
2. Ordner /Library/Quicktime öffnen.
3. Folgende Datei zuerst sichern, dann löschen: CamCamX5.component.
4. Skype starten.

Dies sollte zum gewünschten Ergebnis führen. Bitte Erfahrungsberichte in den Kommentaren hinterlassen.

Gruss,
Rupert

Update: Mittlerweile ist die Webseite wieder in vollem Umfang erreichbar.

Scheinbar wurde die Domain extjs.com gedropped. Somit ist sie nicht mehr erreichbar und damit auch die Dokumentation, der Premium Support, das Forum und die Downloadmöglichkeiten.

Damit man trotzdem keinen Entwicklungsengpass bekommt und Antworten auf seine Fragen findet, kann man die Dokumentation unter http://extjs.net/deploy/dev/docs/ benutzen. Generell ist unter http://extjs.net/ eine “Kopie” der .com Seite. Leider verweisen viele Links auf extjs.com und damit ins Leere.

Evtl. werde ich auf der Domain http://extjs.li/ ein Ersatzforum einrichten. Bitte sagt mir in den Kommentaren was ihr davon haltet.

Ich hatte gestern nach einer Lösung gesucht, mit der ich meine Bootcamp Partition vergrössern kann, ohne Windows auf dem Mac neu installieren zu müssen. Hier eine schnelle und sehr einfache Lösung.

1. Zuerst muss die FAT 32 Partition in NTFS umgewandelt werden. Dies wird mit dem Befehl convert c: /fs:ntfs (Console unter Windows) gemacht.
2. Mit Winclone (Freeware für Mac) ein Image der Windows Umgebung auf eine externe Festplatte speichern. http://www.twocanoes.com/winclone/
3. Mit dem Bootcamp Assistenten die Partition löschen und eine neue  mit der gewünschten Grösse anlegen.
4. Die Installation nicht ausführen, sondern abbrechen.
5. Mit Wincolne das eben erzeugte Image wieder auf die neu erstelle Partition einspielen.
6. Windows unter Mac starten und alles ist wieder so wie früher, einfach mit mehr Speicherplatz.

In diesem Sinne viel Erfolg!

Gruss Rupert S.

Ab sofort sind Service2Max und www.zuhause.li Partner im Bereich Webdevelopment. Wir freuen uns auf die kommende Zusammenarbeit. Auf dass sie erfolgreich sein wird und beide Parteien davon profitieren.

Ich freue mich unseren Blog in neuem Design präsentieren zu dürfen. Anregungen, Lob oder Kritik sind herzlich willkommen und erwünscht. Einfach das Kommentarsystem nutzen.

Danke für die Aufmerksamkeit,
Patrick

Es kann immer vorkommen, dass eine Email zu Unrecht als Spam definiert wurde. Sollte dies der Fall sein, dann kann man mit dem Befehl amavisd-release die Email aus der Quarantäne befreien und sie in die normale Queue einschleusen. Dabei wird AMaVis die Email nicht mehr bewerten und nicht mehr als Spam erkennen.

Bevor ihr loslegt müsst ihr aber eine Einstellung in der Config überprüfen bzw vornehmen. Die Stelle die ihr bearbeiten müsst findet ihr unter /etc/amavis/conf.d/25-amavis_helpers

$unix_socketname = "/var/run/amavis/amavisd.sock";

$interface_policy{'SOCK'} = 'AM.PDP-SOCK';
$policy_bank{'AM.PDP-SOCK'} = {
  protocol => 'AM.PDP',
  auth_required_release => 0,
};

Dabei ist die Zeile auth_required_release wichtig. Der Wert muss 0 sein, sonst wird beim Wiederherstellen eine secret-id verlangt.

Hinweis:Das Abschalten dieser Überprüfung ist sicher, solange der Zugriff auf das Socket geschützt ist.

Jetzt könnt ihr die Email wiederherstellen. Einfach nach folgendem in der Benachrichtigungsemail von AMaVis suchen

The message has been quarantined as: spam-I51NXaAUBNsZ

Jetzt führen wie den oben erwähnten Befehl aus. Dieser würde mit den gegebenen Informationen so aussehen:

amavisd-release spam-I51NXaAUBNsZ

Danach wird die Email wieder in die Queue gesetzt und AMaVis wird sich nicht mehr damit beschäftigen.

Schönen Tag noch,

Patrick

Ich möchte mit diesem Blogeintrag der Opfer vom 28.08.1988, die damals wegen Leichtsinn ums Leben gekommen sind, gedenken. Mögen sie in Frieden ruhen. Auch werde ich nicht besonders viel dazu schreiben, sondern auf andere Webseiten verweisen, die sich weitaus mehr mit dem Thema beschäftigen.

Hier noch ein Video von YouTube:
Spielt das Video nur ab, wenn ihr das auch wirklich verkraftet (in eurem eigenen Interesse)

Weitere Links zum Thema:

• http://www.ramstein-1988.de/
• http://www.ramstein-airbase-katastrophe.de/
• http://www.robert-stetter.de/Ramstein/ramstein_d.html
• http://de.wikipedia.org/wiki/Flugtagunglück_von_Ramstein

Ich möchte hiermit nochmals mein herzlichstes Beileid an alle Angehörigen aussprechen.

Patrick

Trotz recht gut eingerichtetem Spamschutz kann es immer wieder vorkommen, dass ein Spammer “erfolgreich” ist. Zumindest kommt er bis zu Amavis und Spamassassin. Dabei nutzt er immer dieselbe IP, die nicht in DNSBLs gelistet ist. Will man nun verhindern, dass dieser Spammer überhaupt soweit kommt, dann kann man dem mit recht einfachen Mitteln entgegenwirken.

Das Einrichten dieses Schutzes ist sehr einfach. Als erstes legen wir uns eine Datei an, bearbeiten sie mit postmap und sagen Postfix, dass es die neue Datei als Zugriffsfilter nutzen soll.

# cd /etc/postfix
# touch access
# vim access
# postmap access

In die Datei “access” müsst ihr nun die Regeln schreiben, die berücksichtigt werden sollen. Die könnte so aussehen:

# Access Liste
195.186.18.70 REJECT
213.75.38.161 REJECT

In diesem Beispiel handelt es sich tatsächlich um bekannte Spammer. Jetzt, wo ihr die Datei mit Inhalt gefüllt habt muss der Befehl postmap wieder eine lookup-table daraus machen. Also:

# postmap access

Nun ist alles vorbereitet. Und wie macht Postfix nun was es soll? Dazu müssen wir die main.cf bearbeiten. Um die Access-Liste zu berücksichtigen wird unter den Client-Restrictions ein Befehl eingebaut. Der Abschnitt in der main.cf sieht folgendermassen aus:

smtpd_client_restrictions =
	    check_client_access hash:/etc/postfix/access

So… nun speichert alles und sagt Postfix, dass es die neue Konfiguration mit

# /etc/init.d/postfix reload

laden soll.

Ich hoffe, dass ihr wieder etwas lernen konntet und dass die Welt wieder ein Stücken “spammfreier” wird. Anregungen, Kritik, Lobgesang -> in die Kommentare bitte.

Patrick

Spamabwehr ist heute eine der Hauptbeschäftigungen jedes Webhosters, jedes grösseren und kleineren ISPs und natürlich auch jedes einzelnen Benutzers, wenn’s um Emails geht. Dieses kleine Tutorial soll eine kleine Hilfe für Systemadministratoren sein, die etwas mehr Schutz für die Emailkonten der eigenen Systeme suchen.

Heute reden wir über policyd-weight, einem kleinen Programm, dass als Daemon läuft und in Perl programmiert wurde. Es soll bei der Bekämpfung von gefälschten Absenderadressen und HELOs helfen. Mit policyd-weight kann man Punkte für verschiedene Kriterien wie DNSBL, HELO, MAIL FROM und IP-Adressen vergben und auswerten bevor die Nachricht überhaupt die Queue erreicht. Dies führt zu weniger Datentraffic, geringere Systemauslastung und natürlich auch zu weniger Spam. Voraussetzung ist allerdings eine gute Konfiguration der einzelnen Punktbewertungen.

1. policyd-weight installieren

Jetzt sollten wir aber anfangen und policyd-weight installieren. Natürlich geht es, wie gewohnt, einfach über apt.

# apt-get install policyd-weight

Nachdem es installiert ist, werden wir noch die Default-Konfiguration erstellen. Diese wird nämlich bei der Installation über apt nicht automatisch erzeugt. Dazu geben wir folgenden Befehl ein:

# /usr/bin/policyd-weight defaults > /etc/policyd-weight.conf

Die Einstellungen können eigentlich alle so bleiben. Ich habe lediglich die Werte $MAXDNSBLSCORE = 10 und $TCP_PORT = 60001 gesetzt. Nachdem wir das getan haben, müssen wir policyd-weight mit

# /etc/init.d/policyd-weight restart

neustarten.

2. Postfix konfigurieren

Damit Postfix nun auch weiss, dass es den neu installierten Dienst nutzen soll und wo es ihn findet, werden wir Anpassungen an /etc/postfix/main.cf vornehmen müssen. Konkret handelt es sich um die smtpd_recipient_restrictions. Nachfolgend eine Beispielkonfiguration:

smtpd_recipient_restrictions =
            permit_mynetworks,
            permit_sasl_authenticated,
	    reject_invalid_hostname,
            reject_unknown_recipient_domain,
            reject_unauth_pipelining,
            reject_unauth_destination,
	    check_policy_service inet:127.0.0.1:60001
	    permit

Na gut… dann wollen wir doch schnell Postfix sagen, dass es die neue Konfiguration laden soll. Also schnell ein

# /etc/init.d/postfix reload

und Postfix kurz arbeiten lassen. Danach können wir unseren Erfolg mit

# tail -f /var/log/mail.log

überprüfen. Sollten Meldungen wie folgendes im Log auftauchen, dann wissen wir, dass alles läuft.

postfix/policyd-weight[4519]: weighted check:  DYN_NJABL=ERR NOT_IN_SBL_XBL_SPAMHAUS=-1.5 NOT_IN_SPAMCOP=-1.5 NOT_IN_BL_NJABL=-1.5 HELO_IP_IN_CL_SUBNET=-1.2 (check from: .seznam. - helo: .admiralestateagents. - helo-domain: .admiralestateagents.)  FROM/MX_MATCHES_NOT_HELO(DOMAIN)=1 IN_PM_RFCI=3.2 IN_ABUSE_RFCI=3.2    , rate: 1.7
postfix/policyd-weight[4519]: decided action=550 Mail appeared to be SPAM or forged. Ask your Mail/DNS-Administrator to correct HELO and DNS MX settings or to get removed from DNSBLs; in postmaster.rfc-ignorant.org; in abuse.rfc-ignorant.org

Also dann… legt los und mach eure Server sicherer und schützt eure Kunden, euch selbst oder einfach ALLE vor möglichem Spam. Natürlich ist das nur eine von vielen Möglichkeiten, die ihr gegen Spammer unternehmen könnt. Solltet ihr Fehler im Beitrag finden, Verbesserungsvorschläge, Lobgesang, oder sonst was loswerden wollen, dann nutzt doch bitte das Kommentarsystem.

Patrick

Weiterführende Links:
- Postfix Homepage
- policyd-weight Homepage