supergarv

Vor gut 2 Wochen hat DomainFactory eine Mail an ihre Kunden herausgeschickt. Die Mail-Komponente der bisherigen Hosting-Pakete werden zu einem eigenständigen Produkt "MyMail" ausgegliedert und migriert.

In der Mail klingt das alles nach einer einfachen Umstellung, aber in der FAQ (Links 1, 2) sieht man recht schnell, dass man sehr intransparent die Features und den Tarif des Mailhostings verändert.

Konnte man in den Hosting-Paketen damals seinen gebuchten Speicherplatz (meist 50GB+) sehr frei mittels Aliasen, Weiterleitungen und Postfächern beliebig strukturieren, so kostet nun künftig jedes neue Postfach direkt ordentlich Geld. Aliase sind aktuell (Stand Juli 2023) "technisch nicht möglich", Weiterleitungen auf eine sehr kleine Zahl beschränkt. Mit dem Fehlen von Aliasen will man wohl die Preis-Daumenschrauben anziehen, so dass diese alle als eigenständige Postfächer bitte angelegt werden, zum Preis von gut 2€ (Stand Juli 2023) pro Stück.

Wer also bislang ein Postfach hatte mit "nachname@example.com" und auch über "vorname.nachname@example.com" oder "v.nachname@example.com" erreichbar sein will, der müsste dann drei Postfächer anlegen und Weiterleitungen schalten. Scheinbar arbeitet man noch an den Details, aber wie kann man eine Migration ankündigen, ohne solche grundlegenden Dinge korrekt zu klären?

Auch verfällt einfach der nicht zugeordnete Mailspace, den man derzeit in seinen Hosting-Tarifen noch hätte.

Das Kundenforum von DomainFactory wurde geschlossen.

Das hat für mich nach langer Zufriedenheit als Kunde (mindestens 10 Jahre) das Fass zum Überlaufen gebracht. Ich wurde damals schon frustriert durch einen Umzug des Serverstandorts Deutschlands in EU-Ausland, und es war immer nervig, dass DomainFactory den Industrie-Standard LetsEncrypt nicht unterstützen wollte (Zertifikate mit laufenden Kosten sind natürlich effektiver...).

Hier ein paar Fakten, die DomainFactory in der FAQ erwähnt, aber nicht wirklich in der Mail:

• Mails nur noch 30MB statt 100MB pro Stück


• Max. 500 Mails pro Tag versenden (Newsletter?!)


• Keine Catch-All-Weiterleitungen mehr, nur noch Catch-All-Accounts


• Maximal 10 Empfänger pro Weiterleitungs-Postfach


• Maximal 50 Weiterleitungen pro KUNDE (nicht pro Postfach)


• Keine Alias-Namen mehr (gh@, hicking@, g.hicking@, ...)


• In Zukunft angelegte Accounts haben (nach Stand Juli 23) 10GB Speicherplatz und kosten rund 2€ pro Account


• Spam-Filter sind Pflicht und können NICHT deaktiviert werden.


• Maximal 200.000 Mails pro Postfach


• Irgendwann 30 Minuten Ausfall des Mailsystems bei Migration


• Mailaccounts unter 1025MB werden in den 1GB Tarif migriert, Accounts darüber in den 10GB Tarif


• Ungenutzer Mail-Space verfällt (wenn man Dummy-Accounts anlegt, kann man sie später nicht umbenennen, bringt also nichts)


• Preisanpassung möglich, erst mit Mail angekündigt wenn Migration ansteht

Ich habe mir einige alternative Provider angeschaut: All-Inkl., Manitu, Netcup, Mittwald, Uberspace.

All-Inkl ist lange Jahre am Markt und ich habe nie schlechtes dazu gehört. Die Tarifstruktur beginnt aufgrund benötigter SSH-Zugänge erst ab Premium für mich, und lag am oberen Ende der Alternativen. Das war letztlich mein oberflächlicher Grund gegen diesen Provider, den ich sonst sicher in Betracht gezogen hätte.

Netcup wurde mir von Arbeitskollegen empfohlen, dort hat mein Arbeitgeber auch einen Managed Server. Die Tarif-Struktur ist günstig, die Größen jedoch auch für mich etwas merkwürdig aufgeteilt. Meine bisherigen Kontakte mit dem Support dort waren jedoch etwas "am Thema vorbei", daher hatte ich etwas Bauchweh dort.

Mittwald nutzt mein Arbeitgeber ebenfalls für mehrere Server. Der Support ist hervorragend, die Leistung zuverlässig, das Interface gut. Leider ist die Tarifstruktur für Privatkunden eher über meinem Budget, und schied daher aus.

Uberspace ist ein Provider, mit dem ich lange geliebäugelt habe, und der Nerds wie mich sehr anspricht. Letztlich wollte ich aber mit meinem privaten Web/Mailspace so wenig Arbeit wie möglich haben, und wenig selber Hand anlegen. Auch ist das variable Tarifmodell für mich etwas, wo ich immer etwas Sorge habe, dass es nicht aufgehen könnte und der Provider die Preise anzieht oder Leistung anpasst. Daher für mich auch eher ausgeschieden.

Manitu war mir immer ein Begriff, da ich den hostblogger.de auch noch aus meiner Serendipity-Zeit etwas kannte. Lange Zeit dachte ich, dass dies eher für mittelständische Betriebe und Server-Hosting ausgelegt ist, und Privatkundenpreise ausserhalb meines Budgets lägen. Weit gefehlt - der aktuelle Blick auf die Tarifstruktur zeigte mir ein ausgewogenes Leistungsspektrum zu einem extrem günstigen Preis. Letztlich ist hier der Webhosting M-Tarif für mich schon ausreichend. Ich habe mich also für diesen Provider entschieden, und bin nun fleißig bei der Migration.

Dennoch bin ich sehr traurig, dass ich mein eigentlich technisch rund laufendes Vertragsverhältnis zu DomainFactory nun kündigen muss. Die Entscheidungen zu den Tarifen und Produkten konnte ich nicht mehr unterstützen.

Dieses Blog läuft jetzt bei Manitu

In meiner knapp 2-stündigen Bonn-Köln-Berufs-Pendelei habe ich nicht nur einen ganzen Batzen Zeit um TV-Serien zu schauen, sondern auch um meine RSS-Feeds mit Informationen, Spaßigem und Geek-Kram abzugrasen. Da ich mit iPhone und iPod Touch ausgestattet bin, artet das häufig in witzigen True-Multitasking aus, indem ich den Videoplayer quer über dem iphone in einer Hand halte, und während "oben" die Serie läuft kann ich "unten" RSS und Mails lesen.

Gerade bei so oft mäßigen oder langatmigen Serien wie Chuck, V und The Event ist das eine nette Parallelaktivität. Eins macht die Sache jedoch ziemlich anstregend: Die Signalqualität der Zugstrecke Bonn-Köln ist löchriger als ein Schweizer Käse, und man kann im 2-Minutentakt mit GPRS-Signalverlust rechnen. UMTS ist sowieso nur in zwei ganz kurzen Streckenteilen verfügbar.

Hauptsächlich benutze ich den Web-basierten mobile Google Reader im iPhone-Safari. Dieser ist dank mehrerer Interface-Iterationen mittlerweile recht gut bedienbar. Ich sehe jeweils 25 Items pro Seite, kann die Seite dann als gelesen markieren und dann kommt die nächste. Ein Klick auf ein Item faltet die Liste lediglich auf, man hat also seine Gesamt-Artikel nach wie vor im Blick.

Dennoch ist der Mobile Reader nicht unbedingt slick und sexy wie manch andere Anwendung, zum Beispiel das populäre Reeder. Also habe ich gestern spaßeshalber endlich mal diese App gekauft und ausprobiert. Dank GoogleSync kann man seine Feedlisten ja heutzutage glücklicherweise in jedem Client lesen und stets auf demselben Stand halten. Zu RSS-Bandit-Zeiten war das alles deutlich schwieriger.

Aber nun zu Reeder.

Auf Wunsch von Robert aus dem Serendipity-Forum wollte ich mich gestern an ein Serendipity-Plugin begeben, dass die Kommentare zu einem Blog-Posting auf Facebook zurück ins Blog importiert.

Damit ein Blog-Posting erstmal bei Facebook ankommen kann, muss man seinen RSS-Feed bei Facebook hinterlegen damit es dort als "Note" importiert werden kann. Eine weitere Variante wäre, dass sich das Blog selbst bei Facebook über eine API anmeldet und postet, dafür gibt es aber derzeit noch kein Plugin. Das ganze arbeitet mit OAuth, und das ist schon bei Twitter arg fehleranfällig, weil es vile Nutzerinteraktion erfordert, die sich selber API-Keys besorgen müssen, die zwischen Blog und Facebook hin- und herkopieren müssen, etc.pp. Kurzform: Nur über die "Notes" ist es halbwegs einfach einzurichten.

Nun bietet Facebook per Graph API so etwas wie http://graph.facebook.com/supergarv/posts an, in dem meine letzten Postings stehen - unter anderem wird auch dieses Blogposting dort auftauchen. Kommentare zu der "Note" werden dann innerhalb der JSON-Daten von Facebook ausgegeben (sofern sie public sind).

So weit so gut - das Problem ist, dass der "link" zu einer "Note" nicht der URL des Blogeintrags entspricht sondern eher sowas wie http://www.facebook.com/notes/garvin-hicking/serendpity-podcast/10150119644579907 - und diese URL kann man nicht in die "echte" URL umleiten, ohne sich bei Facebook einzuloggen. Damit sich das Serendipity-Plugin einloggen kann, wäre aber der ganze OAuth-Pröll wieder erforderlich.

So zumindest verstehe ich die ganze Sache; ich könnte mir nur vorstellen dass die Note-URLs nur dann keinen Login erfordern, wenn das komplette eigene Profil nicht eine "Person" sondern eine "Page" ist.

Kennt sich jemand mit diesen Sachen aus und hat etwas Input zu leisten? Irgendwie muss man doch die Verbindung herstellen können. Das WP-Plugin an dem ich mich orientierte liegt übrigens hier: T3N Facebook Kommentar-Integration.

Vor kurzem hat Twitter seine API derart umgestellt, dass nur noch autorisierte Anwendungen auf den Twitter-Stream mit erweiterten Funktionalitäten (und vor allem schreibend) zugreifen dürfen. Der neue Zugriff erfolgt mittels OAuth. Hier werden einzelne Anwendungen für den Zugriff konfiguriert, und das Passwort zum eigenen Twitter-Account muss nie übermittelt werden.

Die Einbindung von OAuth wurde initial dank der Hilfe von Silvio Kunze vorangetrieben. Ich habe mich am Wochenende dem Plugin angenommen, und dank des Feedbacks in der Twittersphere (Danke jpwenzel, mattsches und gethash), nun auch endgültig OAuth verstanden. Eigentlich nicht schwer, aber doch relativ umständlich einzurichten.

Die neue Twitter-Plugin-Version gibt es derzeit hier: serendipity_plugin_twitter.zip (1.23, wird nach ein paar Tests auch demnächst offiziell eingestellt)

Der grundsätzliche Workflow ist wie folgt:

1. Man installiert das Serendipity Twitter plugin (wenn nicht schon geschehen)

2. In der Konfiguration des Plugins gibt es einen neuen Button, mit dem man seine Anwendung auf Twitter.com registriert. Zudem erklärt einem das Plugin, welche Felder man mit welchen Werten man dort eintragen kann.

3. Sobald man die Anwendung (also das Plugin von euch) bei Twitter.com registriert hat, kriegt ihr auf der Folgeseite den Consumer Key und das Consumer Secret. Diese Zeichenfolge identifiziert die nur für euch registrierte Anwendung eindeutig. Diese beiden Zeichenfolgen kopiert ihr einfach in die Konfiguration des Serendipity-Plugins.

4. Nach dem speichern von Consumer Key und Secret in der Pluginkonfiguration gibt es einen neuen Button namens "Einloggen". Wenn ihr darauf klickt, kommt man zur Twitter-Seite, wo man die gerade angelegte Anwendung dazu autorisiert, auf euren Twitterstream zuzugreifen. Nach der Bestätigung der Twitter-Meldung landet ihr in eurem Blog, und die Verbindung wird als hergestellt markiert.

5. Ab jetzt könnt ihr wieder in der Startseite des Blogs eure Tweets absetzen, und beim Posten von Blogeinträgen automatisch an Twitter senden.


Ich wünschte man könnte den Prozess abkürzen, aber tatsächlich ist es von Twitter nicht vorgesehen, einfach per Link eine Anwendung mit vorausgefüllten Daten zu registrieren. Auch wäre es nicht sinnvoll eine einzelne App für alle Serendipity-Blogs zu erstellen, da ansonsten ein Missbrauch der Anwendung auswirkungen auf alle Anwender haben könnte. Abgesehen davon ist die Callback-URL ein Parameter pro Anwendung, und nicht pro Autorisierung - man müsste das Plugin also dann an zentraler Stelle als Proxy aufsetzen.

Bitte testet das Plugin bei euch, wenn ihr die Funktionalität gebrauchen könnt. Im ausführlichen Artikelteil gehe ich noch etwas spezieller auf die interne Funktionalität des Plugins ein.

Isotopp hat auf seinem Blog von flattr berichtet. Das war für mich der tipping point, um mich auch selbst ernsthaft mit flattr zu beschäftigen, das derzeit behypt wird.

Flattr ist eine Social-Micropayment-Service, auf dem man ein Budget verwalten kann, das anderen Leuten (und auch einem selbst) zu Gute kommen kann, die kostenlosen Content produzieren. Wie der Dienst schon selbst sagt, es ist etwas zum Liebe zurückzugeben. Solche hehren Weltverbesserungsziele unterstütze ich immer gerne.

Daher habe ich auch für Serendipity ein Flattr-Plugin gebastelt, dass nun auch hier zum Einsatz kommt. Wer es gerne benutzen will findet es beim üblichen Verdächtigen Spartacus. Man kann damit pro Eintrag bestimmen ob ein Eintrag geflattrt werden soll, mit welchen Attributen etc.

Mehr zu dem Plugin gibt es im s9y blog.

Stefan Esser, Rächer der Exploitierten, Injection-Schnüffler Extraordinaire und Fiebertraum aller Entwickler hat im Rahmen des diesjährigen Month of PHP Security mal wieder zugeschlagen, und unter anderem eine größere Sicherheitslücke in Xinha gefunden.

Xinha ist ein WYSIWYG-Editor, der angenehm komfortabel ist und dessen Vorgänger htmlarea seit Urzeiten in Serendipity integriert war. In Version 1.4 haben wir den Umzug auf Xinha gemacht, der mittlerweile einiges an neuen und coolen Features bietet. Viele davon nutzt Serendipity garnicht unbedingt, und das wurde uns jetzt zum Verhängnis.

Ein Sicherheitsleck in deren Plugin-API ermöglicht die Übermittlung von dynamischen Parametern zur Konfiguration des Xinha-Backends, das unter anderem das ImageManager und ExtendedFileManager-Plugin einsetzt. Diese PHP-Dateien sind auch leider extern aufrufbar, und ermöglichen den Upload von beliebigem PHP-Code.

Klingt ätzend, ist es auch. Serendipity's neue Version hat diese Funktionalität nun kurzerhand deaktiviert, und alle Serendipity-Nutzer sind aufgefordert entweder auf 1.5.3 zu aktualisieren oder kurzerhand die Datei htmlarea/contrib/php-xinha.php zu löschen. Wenn das Xinha-Team den Bug etwas genauer inspiziert und behoben hat, wird es sicher nochmal einen korrekteren Fix als unseren geben.

Bitte weitersagen, schnell fixen, und Stefan für das Finden danken. Nur durch derartigen, unermüdlichen Einsatz werden OpenSource-Systeme im täglichen Einsatz sicherer, und die Entwickler sensibler auf derartige Lücken hingewiesen. Auch wenn solche Lücken kurzfristig immer weh tun, derartige Full Disclosures sind unabdingbar. Danke, Stefan!

Ich bin ein großer Nörgler, und reize das Spektrum an konstruktiver Kritik immer gerne voll aus. Ausserdem lese ich gerne Fachliteratur über PHP/Web-Entwicklung.

Da liegt es nahe, meine 2 Cents in Form von technischen Reviews oder Übersetzungen zu Büchern beizutragen, wie z.b. beim PHP kurz&gut Handbuch oder der Übersetzung des phpMyAdmin-Handbuchs - oder natürlich dem eigenen Serendipity Handbuch.

Das erste Mal überhaupt habe ich für den PacktPub-Verlag das phpMyAdmin-Buch reviewed. Die Zusammenarbeit mit dem phpMyAdmin-Projektleiter Marc Delisle war damals schon sehr angenehm, und das erste richtige Buch zu PMA konnte in vielen Feedback-Iterationen entstehen. Später hat mich PacktPub auch noch für andere Bücher angefragt, vor einem Jahr ein Buch zu Moodle.

Das Thema interessierte mich, ich habe Kommentare beigetragen und das ein oder andere Kapitel verrissen, nur um am Ende rauszufinden dass mein Feedback ignoriert wurde. Daraufhin hab ich meinen Namen aus dem Teaching Moodle-Buch entfernen lassen und war etwas frustriert (was ich dem scheinbar mittlerweile indischen Verlag auch mitteilte).

Vor einigen Monaten fragte man mich erneut ob ich diesmal ein Buch namens PHP Team Development reviewen wollte. Ich wollte, denn das Thema ist für mich natürlich auch sehr wichtig, und man versprach mir diesmal viel Sorgfalt walten zu lassen. Immerhin gibt es ja auch einige recht gute Packt-Bücher.

Die ersten Entwurfs-Kapitel dieses Buches waren grausam.

Zum einen merkte man deutlich, dass ein Non-Native Speaker seinen Text zum besten gibt, zum anderen waren die Kapitel voll inhaltsleeren buzzword-droppings, falschen Vereinfachungen und auch ohne relevanten Praxisbezug. Das Buch schien ausgerichtet für den "Human Resources Manager", der von Programmierung keine Ahnung hat, und nur gerne für's nächste Team-Meeting ein paar weise Zitate loswerden kann.

Also habe ich mir die Finger wundreviewed und meine Meinung abgelassen, die auch jedesmal dankend angenommen wurde.

Gen Ende des Buches wurden die Tipps und Alltags-Beschreibungen von PHP-Entwicklung im Team etwas konkreter und auch besser zusammengefasst. Nach etwas Funkstille folgte dann der Hinweis, dass die erste Reviewrunde zu Ende sei, ich bekam eines der späteren Kapitel zum probelesen, und sah in dem Kapitel mein Feedback sogar auch teilweise implementiert.

Hurrah, dachte ich mir - Feedback ist doch produktiv. Da ich den Sommer über mit einem neuen Projekt ausgelastet war, fehlte mir die Zeit den zweiten Schwung Entwürfe durchzulesen, das Buch ging in den Druck, mein Reviewer-Name steht im Cover, ich kriege das Final-Exemplar und:

Verdammt.

Ein Großteil der Kapitel ist nach wie vor Buzzword-geschwängert, schmeißt mit teilweise realitätsfernen Empfehlungen oder unlogischen Schlüssen um sich.

Einerseits denke ich mir, "Ich bin ja nur der Reviewer, mehr als meine Meinung sagen geht nicht". Auf der anderen Seite sehe ich ein Buch vor mir, dass ich in weiten Teilen nicht gut finde. Auf der einen Seite hätte ich mir die Zeit nehmen sollen die zweite Reviewrunde zu nehmen, auf der anderen Seite kriege ich dafür kein Geld, mache es zum Spaß, habe meine Kritik konkret und konstruktiv geäußert, und bin ja auch nicht der Autor.

Wie auch immer, aus solchen Fehlern lernt man. Wer etwas Spaß haben möchte und vom Fach ist, wird mit diesem Buch übrigens dennoch Freude haben!

Heute ein PHP 5.3 update gemacht und danach einige Schwierigkeiten bekommen.

Abgesehen davon, dass PHP 5.3 mit seinen E_DEPRECATEDs mit sich herumschmeißt als seien die im totalen Ausverkauf, hatte ich danach einige Probleme die Anwendungen auf dem Server wieder ans laufen zu kriegen.

Letztlich war das Problem einfach nur, dass die neu aufgespielte php.ini (im Debian-Paket) zwar sessions konfiguriert, aber keinen default session.save_path gesetzt hat. Darauf aufsetzende Anwendungen haben also alle gedacht sie könnten Sessions nutzen, obwohl nirgends etwas geschrieben wurde.

Das nur mal so als Memo an mich.

Andy wollte gerne einen eigenen Linktrimmer, um so etwas wie TinyURL, Tr.Im und Bit.ly lokal abzubilden. Das hat Sinn, denn wie man just an Tr.im gesehen hat, kann ein derartige Service jederzeit ausfallen und die liebgewonnenen URLs töten. Da ist man in manchen Fällen also lieber selber für seine Daten und Backups verantwortlich.

Eigentlich wäre es ein leichtes, ein dediziertes PHP-Script dafür aufzusetzen. Aber weil ich sowas auch gerne haben wollte und es eine 30-Minuten-Fingerübung wäre, habe ich es als Serendipity-Plugin implementiert.

Das Plugin kümmert sich darum, ein Kürzungsinterface direkt im Backend vom Blog einzubinden, und auch als zusätzlicher Button beim Erstellen von Blog-Einträgen. In der Eingabemaske trägt man die zu kürzende URL ein, ggf. optional den eigenen Hash, klickt auf den Go-Button und erhält einen Link zum eigenen Blog zurück, der dann auf die eingebene URL per 301 Redirect weiterleitet.

Die Links werden automatisch durchnummeriert (sind daher also auch "iterierbar" durch Besucher) udn mit meinem Base62-Verfahren gekürzt. Aus einer Zahl wie "10" wird daher "A", aus "61" wird "y" - und bis die URL also lang wird, hat man viele Links gesammelt.

Das ist derzeit alles noch sehr grob und für meine/Andys Bedürfnisse geschnitzt. Aber vielleicht hilft es ja dem ein oder anderen. Denkbar wäre in einer weiteren Ausbaustufe noch eine Art bookmarklet für noch einfachereres wandeln - das sind nämlich derzeit Komforts, die man sich bei der Nutzung von externen Diensten noch erkauft.

Vielleicht wäre es später auch noch nett, das Plugin mit dem tollen Twitter-Plugin von Grischa zu verheiraten, um die Links mit dem eigenen Trimmer zu kürzen. Das wiederum macht aber dann Tweetbacks schwerer. Naja, das Leben ist ein ständiger Kompromiss.

Das Plugin liegt derzeit als serendipity_event_linktrimmer im Spartacus-CVS und kann hier runtergeladen werden:http://php-blog.cvs.sourceforge.net/php-blog/additional_plugins/serendipity_event_linktrimmer, ein ZIP-Archiv für besonders hastige habe ich temporär auf meinen Server geladen. Auf meinem Server regelt eine zusätzliche .htaccess dann die Weiterleitung von Links im Stammverzeichnis auf meine s9y-Installation.

Meinungen?

Ich hätte da gerne ein Stück Software, was für mich IMAP-Konten unterschiedlicher Server als "virtuellen" Unterordner eines unabhängigen IMAP-Servers mappt.

Oder verbose formuliert:

Ich habe einen lokalen Courier IMAP Server auf meinem Heimserver. Der enthält mein maildir, dass via fetchmail mehrere POP-Accounts abgreift, die ich dann einfach via IMAP gruppiert darstellen kann.

Da ich jetzt einen Kollegen mit zwei Mailaccounts urlaubsmäßig vertrete, möchte ich dessen Mails (IMAP-Konto) gerne in meinen Master-Account reinziehen. Da aber auch andere Kollegen sein Mailfach abrufen, darf ich die Mails nicht beim Abruf löschen - und vor allem sollte der "Gelesen"-Status bei Abruf egal welcher Person beibehalten werden. Wenn ich z.b. Mails lese oder Spam lösche, sollen die anderen Kollegen das nicht auch nochmal tun müssen.

Daher kann ich nicht einfach per fetchmail auch noch den IMAP-Account abrufen, denn wenn ich dann die Mails lokal bei mir lese werden sie auf dem Remote-Server ja nicht als gelesen markiert.

Am coolsten stelle ich mir einen virtuellen IMAP-Folder vor, der dann nicht in meinem ~maildir/ liegt, sondern bei jedem Aufruf quasi die IMAP-Kommandos an den remote Server weiterleitet. Mein Googlen hat leider nichts derartiges hervorgebracht, aber ich bin überzeugt dass die Grundidee was ziemlich cooles sein könnte.

Technisch sollte das vielleicht auch nicht so schwer sein, da das ganz ja quasi nur ein Proxy ist, der die Client-Request und Remote-Server-Response 1:1 an den Client weitergibt. Es gibt zwar IMAP Proxy-Software, aber die integriert sich halt nicht innerhalb meines normalen IMAP-Servers.

Ziel soll halt sein, alles auf meinem iphone mit einem einzigen Server lesen und synchen zu können.

Geht das, gibt's das?