Dell liefert defektes Inspiron 1520 – aber pünktlich

Wie es scheint hat Dell aus der öffentlichen Kritik an den langen Lieferzeiten gelernt. Jedenfalls wurde mein Inspiron 1520 vergangenen Mittwoch nach 12 Tagen geliefert. Doch nach dem erwartungsvollen Auspacken war die Enttäuschung umso größer, als das Display des Inspiron schwarz blieb. Ein extern angeschlossenes Display zeigte ein gestörtes Bild.

gestörtes Bild auf externen Display des Inspiron 1520

Ganz offensichtlich war die Grafikkarte defekt. Die schnelle Lieferung ging offenbar zu Lasten der Qualitätskontrolle. Mit einem Anruf bei der Servicehotline wolle ich das Gerät reklamieren. Positiv fiel mir dabei auf, dass Dell unter einer normalen Frankfurter Telefonnummer erreichbar ist. Nach kurzer Wartezeit meldete sich eine freundliche Servicemitarbeiterin, die mir nach Schilderung des Defekts eröffnete, dass wahrscheinlich lediglich das Displaykabel nicht richtig aufgesteckt sei und fragte mich, ob ich es mir zutraute das Notebook zu öffnen. Obwohl ich es für ausgeschlossen erachtete, dass angesichts des Bildfehlers auf einem externen Display ein falsch oder zu locker aufgestecktes internes Displaykabel ursächlich für den Fehler sein könnte, tat ich der Servicetechnikerin den Gefallen. Mit nur einem Handgriff ließ sich die Abdeckung über der Tastatur öffnen, unter ihr verlaufen die Anschlusskabel für die integrierte Webcam und das Display. Hier hebt sich Dell positiv von anderen Herstellern ab, die ihre Geräte so konstruieren, dass sie nur mit Spezialwerkzeug zu öffnen sind.

Anschlusskabel für internes Display des Inspiron 1520
Das Kabel war – wie nicht anders erwartet – fest aufgesteckt. Wie empfohlen löste ich es dennoch und steckte es neu auf. Zu meiner Verwunderung leuchte das Display des Insprion nach Wiedereinschalten tatsächlich auf und zeigte ein gestochen scharfes, makelloses Bild. Jedoch konnte ich mir nicht vorstellen, dass es wirklich an dem Kabel gelegen haben sollte. So teste ich alleine weiter und stellte fest, dass die Funktion der Grafikkarte temperaturabhängig ist.

Mit einem erneuten Anruf bei der Hotline wollte ich nun endgültig den Austausch meines Insprion 1520 in die Wege leiten. Zu meinen Ärger war der Service gegen 19 Uhr jedoch völlig überlaufen, allerdings bat man mir einen Rückruf am nächsten Tag an. Der erfolgte dann auch pünktlich zu vereinbarten Uhrzeit – insofern auch hier kein Grund zur Kritik. Offenbar arbeitet Dell mit einem guten Servicesystem, denn der Mitarbeiter war ohne weitere Erklärungen meinerseits sofort im Bilde und diagnostizierte einen Defekt der Grafikkarte. Schon darauf gefasst das Inspiron einschicken zu müssen und wochenlang auf Reparatur zu warten, wurde ich einmal mehr positiv überrascht: Binnen der nächsten fünf Werktage, aber voraussichtlich eher am nächsten Tag würde sich ein Techniker vormittags bis 10 Uhr bei mir melden, um noch am gleichen Tag einen Termin zum Austausch der Grafikkarte vor Ort zu vereinbaren.

Am nächsten Morgen gegen 8:30 Uhr klingelte dann auch schon das Telefon und gegen 11 Uhr stand der Dell-Techniker bei mir mit einer neuen Grafikkarte im Gepäck vor der Tür. Mit flinken Bewegungen zerlegte er das Notebook und baute die neue Grafikkarte ein. Dabei arbeitete er für meinen Geschmack jedoch etwas zu hastig und sorglos: Die Folgen waren ein verschmiertes Display und einige kleine Kratzer am wohl recht empfindlichen Gehäuse. Als er mir den Erfolg seiner Arbeit demonstrieren wollte, ließ sich das Inspiron nicht einschalten. Wie sich herausstellte, hatte er vergessen das Tastaturkabel wieder einzustecken.

So betrachte ich den Service von Dell mit gemischten Gefühlen: Außer Frage steht, dass der Dell-Support inbesondere im Vergleich zu anderen Herstellern sehr gut erreichbar ist. Bemerkenswert erscheint mir auch, dass Dell zu vereinbarten Terminen zurückruft und Service vor Ort in weniger als 24 Stunden liefert hat. Jedoch sollten solche groben Patzer wie die Auslieferung eine Notebooks mit defekter Grafikkarte durch eine umfangreiche Qualitätskontrolle grundsätzlich vermieden werden. Auch die Arbeitsweise des Technikers vor Ort war meines Erachtens zu fahrlässig und hat – wenn auch nur zu geringfügigen – Beschädigungen am Gehäuse geführt. Außerdem lässt Dell sich den Support recht teuer bezahlen, obwohl es eine Selbstverständlichkeit sein sollte, dass ein Hersteller ein defektes Gerät umgehend repariert oder austauscht – auch ohne zusätzlichen Supportvertrag.

Mit dem Inspiron 1520 bin ich auch nicht vollauf zufrieden: Die Oberfläche des Gehäuses scheint sehr empfindlich zu sein und lässt sich nur schwer reinigen. Ebenso das Display, auf dem sich nach meinen Versuch mit alkoholfreien Displayreiniger die Fingerabdrücke des Technikers wegzuwischen.
Das Inspiron ist recht laut und wird fast so heißt wie mein MacBook. Auch ist ein hochfrequentes Pfeifen zu vernehmen, das wahrscheinlich von einem Spannungswandler ausgeht. Aber auch das scheint mir bei vielen neueren Notebooks ein grundsätzliches Problem zu sein.

Besonders hervorzuheben ist indes die für Notebooks gute Tastatur, die Qualität des gut und gleichmäßig ausgeleuchteten Displays sowie das Preis Leistungsverhältnis. Wie produktiv sich mit den Inspiron 1520 arbeiten lässt, wird sich in den nächsten Wochen zeigen. Gespannt bin ich auch darauf, wie rund Ubuntu auf dem Inspiron läuft.

Neues Notebook – Dell hat Lieferschwierigkeiten

Beim Kauf von Notebooks fehlt mir das richtige Händchen. Nachdem mein MacBook gelinde gesprochen nicht meinen Erwartungen entsprach, orderte ich gestern bei Dell ein Insprion 1520. Überzeugt haben mich nicht nur die Testberichte in Fachzeitschriften und aus der Community, sondern vor allem mein persönliche Eindruck, den ich mir durch das Inspiron 1520 eines Arbeitskollegen vermitteln konnte. Besonders gefreut hat mich, dass er Ubuntu ohne größere Probleme auf dem Inspiron nutzen konnte. Das recht hohe Gewicht von über 3 kg scheint mir das einzige nennenswerte Manko zu sein, doch das Notebook soll eher Verwendung als Desktopersatz finden, denn mir als Reisebegleiter zu dienen.

Inspiron 1520

Ärgerlich ist hingegen, dass ich heute – natürlich nach Zahlung der Rechnung – in der c’t lesen musste, dass Dell große Lieferschwierigkeiten hat. Mitunter sollen Kunden schon seit mehreren Monaten auf die Lieferung ihres Geräts warten. Angesichts von nahezu tagesaktuellen Preisen sind solch lange Lieferzeiten besonders ärgerlich. Denn nach mehr als einen Monat ist ein gewiss zu teuer bezahlt.

Nun überlege ich von Kauf zurückzutreten, allerdings fehlt mir eine gute Alternative im Preissegment bis 1.500 Euro.

Qualitätsmängel MacBook

Die Enttäuschung über mein MacBook wird immer größer. Zumindest die Verarbeitung meines Exemplars ist wesentlich schlechter als von vielen Lowbudget-Notebooks. Wie schon mal in diesem Blog beklagt, klemmen einige Tasten und das Display öffnet und schließt mit deutlichen Widerstand, dessen Überwindung zu einem vernehmbaren Knacken führt.
Nun hat sich heute noch ein Teil vom Rand des Topcase gelöst, ohne dass das MacBook über Maß – etwa durch einen Sturz – beansprucht worden wäre.

MacBook mit gebrochenen Topcase

Ursprünglich sollte mein nächstes Notebook ein MacBook Pro werden, nun liebäugle ich doch wieder anderen Herstellern, die bessere Ausstattung und Qualität zum kleineren Preis bieten.

1&1 stellt gekündigte Domain in Rechnung

Eines muss man 1&1 lassen: Sie wissen wie man Geld verdient. Nachdem die 1&1 Internet AG kürzlich eigenmächtig eine Domain aus meinem Vertrag gelöscht hat, mich aber weiterhin für den nun brachliegenden Webspace zu Kasse bat, stellen sie mir nun eine weitere, am 27.07.2007 per KK an die Key-Systems GmbH übergebene Domain in Rechnung. Meine telefonisch Bitte um Stornierung der Rechnung wurde von 1&1 damit beantwortet, dass ich doch bitte beweisen möge, mit der Domain tatsächlich umgezogen zu sein. Das sollte kein Problem werden, allerdings ist es eine Frechheit als Kunde in die Pflicht der Beweisführung genommen zu werden.

Wie Rene bereits so treffend kommentierte: „Alles sehr schön dort, doch wenn man mal raus will dann wird’s unangenehm.“

Geht doch – mit Signtrust-Zertifikaten E-Mails signieren

Bislang wurden per E-Mail verschickte Rechnung in unserem Unternehmen über DATEV e:secure signiert. Die Lösung funktonierte viele Jahre problemlos. Doch leider stellt DATEV den Trustcenterbetrieb ein – soweit mir bekannt aufgrund mangelnder Nachfrage. Auf der Suche nach einer Alternative verwies DATEV uns an Signtrust, eine Tocher der Post AG.

Nachdem in der letzten Woche bereits Smartcard und PIN-Codes bei uns eingingen, wurde auch heute der neue Cardreader geliefert. Die Installation der mitgelieferten Software verlief zwar unnötig kompliziert, aber problemlos. Testweise signierten und verschlüsselten wir über die im Lieferumfang enthaltene Software OpenLimit SignCubes einige Dateien – klappte prima.

Doch die Probleme folgten stehenden Fußes, als wir versuchten das Signtrust-Zertifikat seinem primären Zweck zuzuführen: Dem Signieren von E-Mails aus Microsoft Outlook 2003 heraus. Zwar ließ sich das Zertifikat ohne Mühe einbinden, doch beim Versenden von zu signierenden E-Mails verweigerte Outlook mit der Fehlermeldung den Dienst, dass die Nachricht weder verschlüsselt noch signiert werden könne, da keine Zertifikate für das Senden von Nachrichten von der Adresse vorhanden seien.

Outlook 2003 erklärt Signtrust-Zertifikat für ungültig

Ein Blick auf die Details des Zertifikats bestätigten die Fehlermeldung. Tatsächlich war für den Antragssteller keine E-Mailadresse im Signtrust-Zertifikat hinterlegt.
Allerdings fordert S/MIME v2 dass in den verwendeten Zertifikaten die E-Mailadresse des Absenders hinterlegt sein muss. Darüber inwieweit es sinnvoll ist ein Zertifikat an eine E-Mailadresse zu binden, lässt sich vortrefflich streiten, aber es ist mehr als ärgerlich, dass sich die doch recht teueren Signtrust-Zertifikate nicht ohne Weiteres zum Signieren von E-Mails nutzen lassen.

Zum Glück gibt es eine, der Supportabteilung von Signtrust übrigens bislang unbekannte, Lösung für Outlook 2003.
Tatsächlich ist die Absenderadresse zur Überprüfung einer signierten E-Mail völlig unerheblich, da das Zertifikat an den Antragsteller gebunden ist und seine E-Mailadresse nur ein zusätzlich Attribut ist. Darum wird zumindest von Outlook kein Zertifikat nur aufgrund einer abweichenden E-Mailadresse als ungültig eingestuft. Lediglich der Versand bereitet Probleme, doch das lässt sich via Registry lösen.

Dazu ist im Hive HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\11.0\Outlook\Security der DWORD-Wert SupressNameChecks einzufügen und mit 1 zu belegen. Fortan lassen sich über Outlook auch mit Signtrust-Zertifikaten signierte E-Mails versenden.

Ein Supporter von Signtrust insistierte, Signtrust habe uns ausdrücklich darauf hingewiesen, dass es nicht möglich ist mit Signtrust-Zertifikaten E-Mails zu signieren. Bislang gelang es mir jedoch nicht einen entsprechenden Vermerk in den Unterlagen zu finden – außerdem geht es ja dennoch, wenn auch nur über Umwege. Allerdings wirkte die Erklärung sehr einstudiert und erfolgte schon, ehe ich unser Problem vollständig schildern konnte. Mich deucht, dass unsere Beschwerde kein Einzelfall ist.

Übrigens gab Signtrust mir die Auskunft, dass Ihnen keine Genehmigung der Bundesnetzagentur vorläge, um die E-Mailadresse des Antragsstellers ins Zertifikat zu integrieren. Weiß jemand genaueres darüber?

SSH absichern

Vor einiger Zeit schon  habe ich mir vorgenommen etwas darüber zu schreiben, wie ein Webserver abgesichert werden kann. Darum nehme ich die heute kürzlich gestellte Frage zum Anlass endlich damit zu beginnen und fange bei SSH an. Im folgenden beziehe ich mich auf die Implementierung OpenSSH. Die Konfiguration anderer Implementierung wie etwas SSH.com verläuft ähnlich, weicht jedoch im Detail ab.

Bevor wir beginnen, solltest du sicherstellen, dass du eine aktuelle SSH Version benutzt. Unter Debian genügt dazu der Einzeiler apt-get update; apt-get dist-upgrade. Unter anderen Distributionen stehen ähnliche Werkzeuge zum Update zur Verfügung wie etwas yast unter Suse.

Nun ist es an der Zeit die Konfigurationsdatei /etc/ssh/sshd_config zu bearbeiten. Ich werde im folgenden die sicherheitsrelevanten Optionen durchgehen und kurz kommentieren.

ListenAddress 217.79.182.18

Wenn ein Server mit mehr als einem Netzwerkinterface ausgestattet ist, kann es sinnvoll sein den Zugriff bestimmte Interfaces zu beschränken. Beim klassischen Webserver dürfte das allerdings nicht der Fall sein.

Port 2222

Standardmäßig lauscht der SSH-Dämon auf Port 22. Viele Bruteforceattacken gegen ganze Netzwerksegmente können durch Nutzung eines anderen Ports erfolgreich abgewehrt werden. Solche Angriffe gehen meist von Botnetzen oder bereits gekaperten Servern aus, die mit großer Bandbreite tausende Logins gegen Port 22 feuern. Dabei werden Standardbenutzernamen (admin, root, httpd, mail usw.) mit leerem Passwort oder Passwörter aus Wörterbüchern und Passwortlisten durchprobiert. Solche Angriffe können zwar einen sicher konfigurierten Server nicht gefährden, blähen aber die Logdateien auf, führen zu verminderten Reaktionszeiten und schlimmstenfalls können sich legitimierte Benutzer ob der vielen Anfragen nicht über SSH einloggen. Selbstverständlich bietet die Nutzung eines anderen Ports keinen Schutz gegen gezielte Brutforceangriffe, bei denen dem eigentlichen Angriff ein Portscan vorausgeht. Abhilfe können hier zum Beispiel sshblack schaffen oder eine Kombination von Snort, Netfilter und iptables. Da DoS-Attacken kein SSH-spezifisches Problem sind, werde ich an dieser Stelle nicht weiter darauf eingehen.

Protocol 2

Die Version 1 des SSH-Protokoll enthält Designschwächen, die einen unbefugten Login ermöglichen, und sollte darum nicht benutzt werden.

PermitRootLogin no

Es ist eine gute Idee root den Zugang über SSH zu verwehren. Denn wenn jemand gelänge sich über SSH unbefugt Zugang zum Server zu verschaffen, könnte er als unprivilegierter Nutzer nur begrenz Schaden anrichten. Da es ohnehin von Leichtsinn zeugt stets als root zu arbeiten, spricht auch wenig dafür den direkten Login als root zu erlauben. Wichtig ist auf einen frisch installierten System einen neuen Benutzer anzulegen, bevor wir über PermitRootLogin no root vom SSH-Login ausschließen.

AllowUsers tom thomasfalkner@thomas-falkner.de
AllowGroups admin

Wenn nur bestimmte Nutzer sich via SSH auf dem Server einloggen dürfen, können diese über AllowUsers bestimmt werden. Wenn Benutzer nur von einem bestimmten Host aus Zugang zum Rechner erhalten sollen, kann dass über user@host geregelt werden. Das kann sinnvoll sein, wenn ein Webdesigner sich nur aus dem Firmennetzwerk, nicht aber von zu Hause auf dem Server anmelden darf. Durch die Option AllowGroups kann der Login auf bestimmte Benutzergruppen beschränkt werden.
Sollen mehr Benutzer erlaubt als ausgeschlossen werden, ersparen die Gegenstücke zu AllowUsers und AllowGroups, DenyUsers und DenyGroups, eine Menge Tipparbeit.

Doch es ist nicht nur wichtig festzulegen, wer sich über SSH anmelden darf, sondern auch welche Authentifizierungsverfahren dazu genutzt werden sollen. Hier greift die Regle: Alles deaktivieren, was nicht benötigt wird.

Wer mit dem höchsten Sicherheitsstandard arbeiten möchten, sollte ausschließlich die PubKeyAuthentication nutzen und alle anderen Authentifizierungsverfahren ausschalten.

RhostsRSAAuthentication no
HostbasedAuthentication no
KerberosAuthentication no
GSSAPIAuthentication no
RSAAuthentication no

Obwohl die meisten Optionen wie etwa RhostsRSAAuthentication per Default abgeschaltet sind, halte ich es für sinnvoll sie explizit auf no zu setzen, um eine klare Konfiguration vor Augen zu haben. Ferner wäre es töricht davon auszugehen, dass die Defaulteinstellungen sich bei neueren Versionen nicht ändern würden. Updates sollten übrigens ohnehin nie ungeprüft eingespielt werden.

Bevor wir die Passwort basierte Anmeldung mittels PasswordAuthentication no und UsePAM no vollständig deaktivieren, muss zuerst die Anmeldung über PubKey konfiguriert und getestet werden – sonst laufen wir Gefahr uns selbst auszusperren.

Dazu ergänzen wir /etc/ssh/sshd_config wie folgt:

PubkeyAuthentication yes
Damit wird die Authentifizierungs per RSA- oder DSA-Schlüssel aktiviert.

AuthorizedKeysFile %h/.ssh/authorized_keys

Gibt an, wo die öffentlichen Schlüssel auf dem Server gespeichert werden.
Per Default im Homeverzeichnis des jeweiligen Benutzers unter .ssh/authorized_keys.

Nun sollte der der SSH-Dämon neu gestartet werden: sudo /etc/init.d/sshd restart

Damit ist der Server vorbereitet für den passwortfreien Login über Schlüssel. Was fehlt ist der Schlüssel, oder genauer gesagt das Schlüsselpaar. Da der private Teil des Schlüssels auf dem Client verbleibt und nur der öffentliche auf den Server kopiert wird, empfiehlt es sich das Schlüsselpaar auf dem Client zu erzeugen. Unter UNIX-Derivaten starten wir dazu unter dem Useraccount, der sich später auf dem Server einloggen können soll, ssh-keygen.

ssh-keygen -t dsa

Wenn die Voreinstellung bestätigt wird, legt ssh-keygen den private Schlüssel id_dsa als auch den öffentlich id_dsa_pub unter ~/.ssh ab. Die Frage nach der Passphrase kann mit 2x Return übergangen werden, wenn man den Schlüssel nicht mit einem Passwort schützen möchte. Eine generelle Empfehlung ob es sinnvoll ist den Schlüssel mit einem Passwort zu schützen oder nicht, ist schwer möglich. Wird kann Passwort vergeben, kann jeder sich auf dem Server anmelden, der in Besitz des Schlüssels ist. Soll heißen: Wird der Rechner, auf dem der private Schlüssel hinterlegt ist geknackt oder gerät in falsche Hände, steht dem Angreifer auch der Zugang zum Server offen.
Sind die Schlüssel mit einem Passwort zusätzlich geschützt, müsste der Angreifer erst das Passwort per Bruteforce knacken – was bei ausreichend starken Passwort nicht in angemessener Zeit möglich ist.
Das höhere Maß an Sicherheit erkauft man sich jedoch mit der lästigen Eingabe des Passworts beim Login über SSH.

Ist der Schlüssel je nach Gusto mit oder ohne Passpharse erzeugt, muss er auf den Server übertragen werden.

Zuerst prüfen wir, ob es in unserem Homeverzeichnis auf dem Server einen Order .ssh bereits gibt. Wenn nicht, legen wir ihn an. Dazu kann folgender Einzeiler vom Client aus abgesetzt werden:

ssh domain.tld -p2222 "test -d .ssh || mkdir .ssh && chmod 700 .ssh"

Wie oben erwähnt, gehe ich davon aus, dass der User auf dem Client den gleichen Namen trägt wie auf dem Server.
Aus Sicherheitsgründen ist es unerlässlich, dass die Zugriffsrechte des .ssh-Verzeichnisses auf 700 und die für authorized_keys auf 600. Ferner müssen sowohl Datei als auch Verzeichnis dem anzumeldenden User gehören.
Letztere Bedingung erfüllen wir, indem wir Verzeichnis und Datei selbst anlegen, die Zugriffsrechte indes sollten wir explizit setzen.
Auch das lässt sich zu einem Befehl zusammenfassen:
cat ~/.ssh/id_dsa_pub | ssh domain.tld -p2222 "cat >> .ssh/authorized_keys && chmod 600 .ssh/authorized_keys"

Der passwortlose Login sollte damit funktionieren.

Zu den Möglichkeiten von SSH lässt sich noch eine Menge schreiben. Zu gegebener Zeit an dieser Stelle mehr.

Tom goes C#

Ich arbeite mich momentan in C# ein und bin von der Sprache begeistert. Sie bietet alle Merkmale, die ich mir von einer modernen, objektorientierten Programmiersprache wünsche und bringt in der .NET-Umgebung Standardbibliotheken für nahezu alle Probleme mit, die sich im Alltag eines Programmierers stellen.
Da ich – vor allem bedingt durch mein Studium – geübt im Umgang mit Java bin, brauchte ich nicht mehr als dieses Wochenende, um mich mit Syntax und Konzepten von C# vertraut zu machen.

1&1 löscht Domain und kassiert für brachliegenden Webspace

Wäre es rechtens wenn ein Mobilfunkanbieter die Handynummer eines Kunden vor Ablauf des Vertrags löschen würde, aber weiterhin über Monate bis zur Wirksamkeit der Kündigung auf seine Vergütung bestünde? Was selbst die größten Raubritter unter den Mobilfunkanbietern nicht wagen, scheint bei 1&1 gängige Praxis zu sein: Eine Domain wurde durch Versagen des Kundenservice vorzeitig gelöscht. Ohne Domain kann ich den Webspace bei 1&1 nicht mehr nutzen, werde aber von 1&1 bis zum 22.11.07 monatlich mit 13,33 Euro zur Kasse gebeten. Der Support speit mich – ganz im Trend der Zeit – mit Standardantworten ab.

Derzeit überlege ich, ob ich solch ein Geschäftsgebaren ohne Widerspruch hinehmen soll oder es tatsächlich auf einen Rechtsstreit ankommen lasse. Mir geht es dabei nicht um die paar Euro, sondern vielmehr ums Prinzip. De facto entstehen 1&1 durch meinen brachliegenden Webspace, den ich ob der fehlenden Domain nicht mehr nutzen kann, keinerlei Kosten. Selbst wenn die besagte Domain auf meinen expliziten Wunsch hin rund vier Monate vor Ablauf der Kündigungsfrist gelöscht worden wären, könnte 1&1 mich als Akt der Kullanz aus dem Vertrag entlassen – zumal ich seit über 6 Jahren Kunde bin.
Doch in diesem Fall wäre es keine Kullanz, sondern eine Selbstverständlichkeit den Vertrag vorzeitig aufzuheben: Hat doch nachweislich der Kundenservice von 1&1 versagt und die Löschung der besagten Domain verursacht. Prinzipiell könnte ich sogar gegen die vorzeitige Löschung meiner Domain juristisch vorgehen, glaubte ich an die Logik von Gerichten.

Wenn der 1&1-Mitarbeiter wie in der unten abgedruckten Mail behauptet tatsächlich meine Unterlagen geprüft hat, hätte er gut daran getan meinen Wunsch auf sofortiger Kündigung des Vertrags zu entsprechen. Denn wenn ein Kunde schon keinen Schadensersatz für die vorzeitige Löschung seiner Domain geltend macht, sollte man ihn nicht durch absurde Forderungen verärgern.

Am 01.08.07 schrieb support@1und1.de :

> Die Kündigung Ihres Vertrages ist zum 22.11.2007 eingetragen. Daraus
> resultiert die Rechnung über Ihre Grundgebühr vom 01.08.2007

Meine Frage war: Welche Leistung wird mir in Rechnung gestellt. Da die
bei Ihnen gehosteten Domains bereits gelöscht wurden, kann ich
den Webspace nicht mehr nutzen.

Mit freundlichen Grüßen
Thomas Falkner

Sehr geehrter Herr Falkner,

vielen Dank für Ihre Anfrage.

Nach Überprüfung Ihrer Unterlagen darf ich Ihnen mitteilen, dass Sie den
1&1 Business 5.0 Vertrag bei uns haben, welcher zum 22.11.2007 gekündigt
wird.

Die Berechnung des Vertrages ist unabhängig von den enthaltenen Domains.
Auch wenn dieser Vertrag keine Domains enthält, die Vertragslaufzeit
aber noch läuft, wird dieser berechnet.

Wir bitten um Ihr Verständnis.

Mit freundlichen Grüßen

xxxxxx xxxxxxxxxx
Rechnungsstelle
1&1 Internet AG

a+b = a*b

Ist es nicht bemerkenswert, dass 2+2 das gleiche wie 2×2 ergibt? Tatsächliche ist die 2 die einzige natürliche Zahl mit dieser Eigenschaft. Doch es finden sich zahlreiche Zahlen

{N} \setminus \{0\}

für die gilt:

a+b = a*b

Wer kann passende Werte für a und b nennen? Wieviele Lösungen sind möglich?
Kleiner Tip: Es gibt nicht nur natürliche Zahlen.