Thomas Wölfers Baustatik-Blog

Thomas Wölfers Baustatik Blog

Zurück-Button: Geht leider doch noch nicht


Im letzten Beitrag habe ich geschrieben das man www.die.de jetzt auch wieder mit dem 'Zurück' Button verlassen kann. Das stimmt auch - aber leider nur für die Startseite. Dummerweise gibt es eine Variante des gestern angesprochenen Skriptes auch auf anderen Seiten bei die.de - und da ist es leider nicht ganz ohne weiteres zu entfernen.

Bemerkbar macht sich das, wenn man per Link direkt auf eine andere Seite als die Startseite kommt: In dem Fall kommt man mit 'Zurück' nicht wieder weg... Ich möchte da nicht allzu viel Versprechen: Die Lösung für die Startseite war schnell eingebaut - bei dieser Sache wird das nicht so schnell gehen.

Update: Diese Sache so ans laufen zu bekommen wie man sich das eigentlich wünschen würde ist deutlich aufwendiger als ich zunächst angenommen hatte. Ich habe aber nun einen Workaround eingebaut, mit dem man den Back-Button zumindest benutzen kann - man kommt allerdings nicht sofort zurück, sondern erst auf die Startseite, und dann erst auf die eigentliche 'letzte' Seite. (Hinweis: Das tritt natürlich alles nur dann auf, wenn man über einen externen Link zu unserer Site gelangt ist, und nicht, wenn man einfach nur so auf der Site surft.)


Wieso geht der Zurück-Button bei die.de nicht?


Kurz und schmerzlos: Der geht ab sofort wieder...

Die etwas längere Version

Wenn Sie bisher die Webseite für unsere Baustatikprogramme besucht haben, dann passierte was ärgerliches. Die Seite kam zwar, aber wenn man dann den 'Zurück' Button des Browsers benutzen wollte, dann ging das nicht.

Der Grund war dabei nicht etwa der, das wir unsere Besucher nicht wieder gehen lassen wollen, sondern einfach ein Versehen auf meiner Seite: Ursprünglich gab es nämlich mal eine Version der Webseite mit einer Browser-Weiche die per JavaScript funktionierte und einen nach www.die.de schob: Das JavaScript existierte leider bis gerade noch - und darum ging der Back-Button nicht.

Das hat sich jetzt erledigt, und man kann uns nuch auch wieder per 'Zurück' verlassen... :-)


Generics sind bald zu haben - aber keine Templates


Lange dauert es nicht mehr: die .Net Version 2.0 wird definitiv im nächsten Jahr kommen. In den 'Express' Betas ist auch schon ein .Net 2.0 Beta dabei. Das wichtigste was drin sein wird: Generics.

Man kann sich Generics in .Net als sowas ähnliches vorstellen wie Templates in C++, und es gibt auch in der BCL diverse Collection-Klassen die die gängigsten Collections in Form von Generics zur Verfügung stellen. Es gibt also dann beispielsweise endlicher wieder eine generische, typensichere Listenklassen. Die Schreibweise (in C#) ist extrem ähnlich wie die Template-Schreibweise in C++:

List< int> list1; // liste aus integern
List< Command> list2;  // liste aus Objektem vom Typ 'Command'

Der Rest der Generics-Nutzung erklärt sich von selbst, wenn man einmal mit Templates in C++ gearbeitet hat. Der wichtigste Unterschied zu C++ ist der, das Generics zum Zeitpunkt der Übersetzung des Generic schon typensicher sein muss. Bei Templates muss das erst dann der Fall sein, wenn das Template konkretisiert wird. Hm .... ich glaube das braucht ein Beispiel. :-)

Die folgende Template-Klasse ist in C++ möglich:

template class<T> Foo
{
   public bool IsBar( T theT)
   {
       if( theT.HasBar()) return true;
       return false;
   }
};

Das Template geht hier davon aus, das der konkrete Typ der später für 'T' verwendet wird, auch tatsächlich eine Methode HasBar() hat. Das Template als solches wird nicht angemeckert. Erzeugt man aber später eine Konkretisierung für einen bestimmten Typ ( Foo<int> aFoo; ) der eben keine Methode HasBar() hat - dann wird diese Konkretisierung vom Compiler angemeckert. Mit anderen Worten: Das Meckern geht erst recht spät los, nämlich bei der Benutzung des Template.

Bei Generics ist das anders: Dort muss die Generic-Klasse selbst (also das Code-Fragment von oben)  bereits typensicher sein. Nachdem der Compiler aber keinerlei Aussage darüber machen kann ob 'T' nun eine HasBar() Methode hat oder nicht, kann man das obige Beispiel auch nicht übersetzen.

Will man diese Funktionalität, dann muss man dem Compiler passende Informationen mitgeben. Das geht in Form sogenannter 'Constraints', die per 'where' Keyword festgelegt werden. Angenommen man hat einen Typ namens 'IHaveBar' der eine Methode namens HasBar() hat - dann müsste man den Template - Code von oben wie folgt ändern, damit gültiger Generics-Code entsteht.

template class<T> Foo where T : IHaveBar
{
   public bool IsBar( T theT)
   {
       if( theT.HasBar()) return true;
       return false;
   }
}

Es gibt noch eine Reihe weiterer Unterschiede - aber das ist in meinen Augen der wichtigste. Letzten Endes sind Generics etwas weniger flexibel als Templates, die Implikationen von Generics sind aber deutlich leichter zu verstehen: Und typensichere Collections kann man damit auch prima bauen.


Probleme mit gmx.de Accounts - nicht nur für Studenten


Ich hatte vor einiger Zeit schonmal einen Beitrag zu den kostenlosen Studentenversionen geschrieben - den man besser nicht ganz so ernst nimmt wie er klingt... :-)

In letzter Zeit habe ich aber häufiger ein Problem mit gmx.de - eMail-Accounts festgestellt: Bei Gmx scheint es mehrere Sorten von Anti-Spam Maßnahmen zu geben die teilweise wohl ganz gut, und teilweise weniger gut funktionieren. (Gmx testet momentan SPF - das funktioniert ganz gut, ist dort aber leider noch nicht vollständig im Einsatz.)

Jedenfalls ist es so, das Gmx zumindest bei einigen Accounts der Meinung ist, das die eMails mit den Lizenzen (für Studentenversionen oder Work&Cash Versionen) der Statikprogramme als Spam zu behandelt sind. Die Newsletter zu den Statikprogrammen findet Gmx hingegen völlig ok. Warum das so ist ist mir zwar nicht klar - aber seis drum: Es ist ja auch nicht bei jedem Gmx-Account so. Das macht es ein bischen schwer, die Sachlage einzugrenzen.

Worauf das hinausläuft ist folgendes: Wenn Sie ein Gmx-Mailkonto haben, und auf Lizenzdateien von uns warten - bitte schauen Sie einmal in Ihr Spam-Fach, denn da findet sich die Mail unter Umständen recht schnell. Meistens schneller, als wenn Sie nochmals bei uns per eMail nachfragen - und die erneut versendeten Lizenzen dann wieder im Spam-Fach untergehen... :-)


Dank an Robert Scoble: MSDN Subscriber Downloads beschleunigen


Seit dem letzten Wochenende gibt es eine Beta-Version von Visual Studio 2005 per MSDN Subscriber Downloads: Wer ein MSDN Abo hat, da das Beta einfach runterladen. Dummerweise ist der Download nicht gerade klein, sondern schlägt mit etwa 3.5 GB zu Buche. (Da kommt man sich mit unseren knapp 40 MB Downloads für die Statiksoftware ja schon etwas dürftig vor...:-))

Wie auch immer - auch 3.5 GB sind mit einer gängigen DSL Verbindung nicht wirklich ein Problem. In meinem Fall war es allerdings so, das ich von MSDN eine Transferrate von gerade mal 10 KBit/sec (!) bekam. Der FileTransfer Manager (FTM) zeigt das ja dankbarerweise an. Mit dieser Transferrate würde der Download etwa 3 bis 5 Tage brauchen. Soviel Geduld habe ich dann auch wieder nicht... - also gabs eine kurze Beschwerdemail an Robert Scoble mit der Bitte, die doch an eine passende Stelle weiterzuleiten. (Das ist eigentlich nicht sein Job, ich empfehle daher auch nicht das jedermann ab sofort seine Probleme bei Robert ablegt... :-))

Was dann passierte fand ich reichlich erstaunlich:

Robert (der sitzt in den USA, in Redmond, und damit in einer deutlich anderen Zeitzone) meldete sich in wenigen Stunden und hatte die Mail bereits weitergeleitet. Zwar auch nicht an die richtige Person, sondern an Dan Fernandez vom C# Team. Nach kurzem hin- und her (der ganze Mail-Austausch dauerte vielleicht 3 Stunden) ging die Anfrage dann weiter an Andy Boyd von MSDN. Der erklärte zunächst das die MSDN Subscriber Downloads nicht über Akamai verteilt werden (wovon ich ausgegangen war, da Microsoft sonst auch jede Menge Kram über Akamai verteilt.), stimmte mir aber zu das 10 kbit/sec ein bisschen dürftig sind.

Noch eine Mail später gab es dann eine Klärung: Offenbar wird bei MSDN momentan an den Servern rumgeschraubt, was bestimmte Download-Arten deutlich langsamer macht. Andy hatte aber auch einen Workaround zur Hand (der kommt gleich). Auch wenn ich es etwas nervig finde das man bei einer doch eher wichtigen Sache erst hinterherlaufen muss damit es dann geht, muss ich gestehen das ich doch stark beeindruckt davon bin, wie hilfreich die 3 Microsofties waren und wie schnell und unkompliziert die Sache aus der Welt geräumt werden kann. Für eine Firma mit deutlich über 50.000 Beschäftigten ist das in meinen Augen echt beeindruckend.

Und so gehts: MSDN Subscriber Downloads schneller machen

Die ganze Sache hängt an einer Einstellung in den Optionen des FileTransfer Managers. Da muss man unter 'Connections' 2 Dinge tun:

1.) 'Maximum Concurrent Transfers' auf '2' stellen
2.) 'Protocol available to transfer files': Hier muss HTTP aus und HTTPS eingeschaltet sein.

Nach der Aenderung musste ich den FTM einmal neu starten - aber dann war die Transferrate von 10 auf 200 kbit/sec gestiegen. 20-fache Geschwindigkeitssteigerung finde ich schon ganz gut... :-)


Update: Habe gerade - also etwa nochmal 8 Stunden später - festgestellt das Andy Boyd den Workaround über den Subscriber Downloads RSS-Feed veröffentlicht hat. Ursprüngliches Problem hin- oder her: Bin wirklich beeindruckt in welcher Geschwindigkeit das passiert.


Systemsteuerung verwenden: Probleme als Nicht-Admin


Hier und hier habe ich bereits darauf hingewiesen das es aus Gründen der Sicherheit sinnvoll ist, nicht mit unter einem administrativem Account zu arbeiten. Dabei hatte ich auch schon angesprochen, das das nicht immer ganz einfach ist, weil einige Programme unbedingt unter einem administrativem Account laufen wollen. Das kann man mit dem 'run as' (ausführen als) Dienst aber meist in den Griff bekommen.

Der geht aber leider bei einigen Dingen nicht - zum Beispiel bei den Anwendungen aus der Systemsteuerung. Dazu geht unter anderem auch das Applet zur Einstellung der Netzwerkverbindungen, und damit stellt man unter anderem die XP Firewall ein. Besonders mit einem Laptop muss man an dieser Konfiguration aber häufiger etwas ändern: Es braucht also einen Weg auch Applets aus der Systemsteuerung ausführen zu können, ohne sich jedesmal abmelden, und als Administrator anmelden zu müssen. In der Systemsteuerung findet sich auch das TimeWiseServer Control Panel, mit dem Sie die Work & Cash Einstellungen für unsere Statiksoftware konfigurieren - ein Grund mehr, die Systemsteuerung auch als nicht-Admin benutzen zu können.

Das geht aber erstaunlich einfach, wenn man einmal weiss wo die Stolpersteine liegen. Die Systemsteuerung wird im Kontext des Explorers (oder des Internet Explorers) ausgeführt. Es liegt also nahe, einfach eine Kopie des Explorers oder des Internet Explorers mit 'Ausführen als' zu starten. Aufrund eines bestimmten Verhaltens des normalen Explorers ist das damit nicht ganz einfach, mit dem Internet Explorer ist die Sache hingegen (fast) kein Problem: Man muss zunächst also herausfinden, wie man den IE per 'Ausführen als' startet.

Das wiederum ist einfach, wenn man folgendes weiss: Es gibt nicht überall einen “Ausführen Als' Befehl beim IE. So gibt es bei einem Rechtsklick auf das IE Icon am Desktop keinen solchen Befehl, und auch das Icon links oben im Start-Menü hat den Befehl nicht. Das Icon im 'Progamme' Teil des Startmenüs, und auch das Icon in der Schnellstartleiste hat hingegen diesen Befehl.

Mit anderen Worten: Sie klicken mit der rechten Maustaste auf das IE Icon in der Schnellstart-Leiste und starten dann den IE als Administrator.

Dann geben Sie in der Adress-Leiste einfach einen Laufwerksbuchstaben an, z.b.: 'c:\\'. Der IE verändert sich dann leicht und sieht schon sehr ähnlich aus wie der normale Explorer. Wenn Sie dann noch in der Werkzeuleiste auf 'Ordner' klicken, haben Sie einen ganz normalen Explorer vorliegen. Und der hat in seinem Baum unter anderem einen Eintrag für die Systemsteuerung - und darüber können Sie dann auch wieder alle Applets, einschließlich dem zur Konfiguration des Netzwerkes und der Firewall erreichen.

Dann bleibt noch eine Sache zu klären: Sie können nun (Internet) Explorer Fenster mit und ohne administrative Privilegien öffnen. Da wäre es hilfreich, wenn man sehen könnte welches Fenster mit welchen Rechten ausgestattet ist. Dafür gibt es einen einfachen Trick: Es gibt eine 'per User' Einstellung, mit der man den Hintergrund des (Internet) Explorer-Toolbars einstellen kann. Vergeben Sie einfach ein (vielleicht rot signalisierendes?) Bild als Hintergrund für den Explorer mit dem Admin-Account: Dann ist das immer sofort sichtbar.

Das geht am einfachsten mit dem Programm TweakUI aus den Powertoys.


Mehr zu sicheren eMail-Passworten


Gestern habe ich erklärt wie wichtig es ist, das man seine Sitzungen mit dem eMail-Server nur mit einem SSL-Schutz durchführen sollte. Dabei bin ich über einen recht wichtigen Punkt fast hinweggegangen: Das Server-Zertifikat.

SSL aktivieren - leider schwieriger als man denkt

Um SSL in Outlook (Express) zu aktivieren brauchen Sie bei den Einstellungen zum eMail-Konto nur die gestern angegebene Option einzuschalten. Wenn Sie dann aber versuchen eMail abzuholen, dann gehts nicht: Sie erhalten eine Fehlermeldung.

Es wäre ja schon schön, wenn einmal etwas so einfach wäre wie es aussieht: Ein Option einschalten - schwupps - schon ist die Sache sicher. Tja, wäre schön - so ist es aber eben nicht.

Grund fürs Problem

Es gibt aber einen guten Grund, wieso das so sein muss: Sinn der Sache ist ja, das Ihre Account-Daten nicht mehr im Klartext übertragen werden. Statt dessen sollen diese Daten von Ihrem eMail-Programm verschlüsselt werden, und dann in der verschlüsselten Form an den Mailserver übertragen werden. Dadurch ist sichergestellt, das niemand durchs abhören von Netzwerk-Paketen an die Daten drankommt - denn die sind ja verschlüsselt.

Das ist aber auch genau das Problem: Die Daten sind verschlüsselt worden. Und zwar von Ihnen. Wenn also kein anderer die Daten entschlüsseln kann (zumindest nicht in absehbarer Zeit) - wie soll das dann der Mailserver tun? Und wenn der Mailserver die Daten nicht entschlüsseln kann - wie soll er dann überprüfen ob Ihre in verschlüsselter Form vorliegenden Account-Daten richtig sind?

Gute Frage. :-)

Des Rätsels Lösung

Der Trick an der Sache besteht darin, das Sie vorher einmal Informationen mit dem Mailserver austauschen - bzw. der Mailserver mit Ihnen. Wie das im Detail funktioniert würde etwas weit führen, aber im Kern läuft die Sache so ab:

Sie erhalten vom Betreiber des Mailservers eine Datei mit Informationen über den Mailserver. Diese Datei nennt man auch 'Zertifikat'. Ein Teil dieser Informationen gibt dabei an, wie Ihr Computer Daten verschlüsseln muss, damit der Mailserver Sie entschlüsseln kann.

Was Sie also tun müssen ist das folgende: Sie müssen das Zertifikat in Ihrem Computer installieren. Das tun Sie (bei XP), indem Sie mit der rechten Maustaste auf das Zertifikat klicken, und dann den Befehl 'Zertifikat installieren' wählen. Der Befehl öffnet einen Assistenten, denn Fragen Sie alle mit den vorgegebenen Vorschlägen beantworten können. Ist der Assistent durchgelaufen, dann ist das Zertifikat installiert.

Jedesmal wenn Outlook dann Kontakt mit Ihrem Mailserver aufnimmt, überprüft das Programm ob es ein Zertifikat für diesen Mailserver kennt. Nachdem das Zertifikat installiert ist, wird es von Outlook auch gefunden. Anhand des Zertifikates kann Outlook dann ermitteln wie Ihre Account-Daten zu verschlüssen sind. Und der Mail-Server kann die derart verschlüsselten Daten auch wieder entschlüsseln. Mit anderen Worten: Sie können dann wieder Mails abholen und versenden.

Lange Rede kurzer Sinn...

Sie sollten Ihren eMail-Verkehr auf jeden Fall per SSL schützen. Dazu müssen Sie in Outlook eine Option aktivieren - und ein SSL-Zertifikat vom Mailserver installieren. Das Zertifikat erhalten Sie von Ihrem ISP (oder Sie suchen sich einen neuen... :-))


Ist Ihr eMail Passwort sicher?


Sichere eMail ?

Wenn Sie Ihr eMail-Programm einrichten - also zum Beispiel Outlook oder Outlook Express - dann müssen Sie für das Mail-Konto ein Passwort eingeben. Nur mit diesem Passwort können Sie die eigene Mail vom Mail-Server abholen und auf Ihrem eigenen Rechner lesen. Nachdem es unpraktisch ist das Passwort jedesmal neu eingeben zu müssen, speichert Outlook das Passwort ab, und überträgt es beim nächsten Mal automatisch.

Wenn Sie das Passwort eingeben, dann erscheinen im zugehörigen Fenster nur Sternchen ( **** ). Das vermittelt den Eindruck das die Sache schon recht sicher ist: Wie sollte schon jemand an das Passwort gelangen, wenn man das noch nicht einmal lesen kann während es eingegeben wird?

Leider täuscht dieser Eindruck - und zwar mehr als Sie vermutlich erahnen. Das Protokoll zum abholen von eMail vom Mailserver ist wie so viele Protokolle eines aus der Steinzeit der vernetzten Rechner: POP3 (Post Office Protocol Version 3). Und wie für alle der uralt-Protokolle gilt auch für POP3: Die Uebertragung von Texten - und von zwar von allen Texten - erfolgt im Klartext.

Das bedeutet: Wenn Ihr eMail-Programm Ihre Mail vom Mail-Server abholt, dann sendet es zuvor Ihre Account-Daten (also Benutzername und Passwort) an den Mail-Server: Und zwar als unverschlüsselter, direkt lesbarer Text.

Passworte als Klartext

Das klingt noch nicht so dramatisch, denn schließlich ist dabei ja nur Ihr eigener Rechner und der eMail-Server beteiligt, richtig? Falsch! Sogar ganz falsch: Alle Daten die zwischen Ihrem Rechner und dem Mailserver ausgetauscht werden - und dazu gehören auch die Benutzerdaten - können von jedermann mitgelesen werden der sich in Ihrem Subnetz, dem Subnetz des Mailservers oder irgend einem der Subnetze zwischen den beiden Mail-Rechnern befindet.

Mit anderen Worten: Wenn Ihr Rechner in einem Firmen-LAN steht, dann kann jedermann in diesem LAN Ihr Passwort im Klartext lesen.

Dazu braucht es auch keine speziellen 'Hacker' Tools oder besonders tiefgreifende Kenntnisse... ein bisschen Grundwissen über TCP und eines der gängigen und frei verfügbaren Tools reichen aus. Ganz ehrlich: Das mithoeren ist auch nicht wesentlichen schwieriger als das eigentliche versenden der eMail.

Wenn Ihr LAN dann über einen ISP ans Internet angeschlossen ist, dann läuft dieser Anschluss über einen Rechner des ISP. Jedermann der dort sitzt kann mithoeren. Ferner kann natürlich jedermann mithoeren der sich in dem LAN befindet, in dem auch der Mailserver steht. Und schließlich kann auch noch jederman mithoeren, der sich in irgendeinen Netz dazwischen befindet. Und nein - der Lauscher muss nicht direkt am belauschten Rechner sitzen - es reicht, wenn er sich im gleichen LAN befindet.

Das ist übrigens kein Sicherheitsproblem von Outlook oder Microsoft, sondern eines von POP3: Und damit eines der Industrie im Ganzen.

Was kann man dagegen tun

Wenn man nun nicht möchte das das eigene eMail-Passwort in fremde Hände gelangt, kann man sich aber schützen: Dazu gibt es SSL (Secure Socket Layer) für POP3 und SMTP. Das wird von allen ernst zu nehmenden eMail-Clients unterstützt. Bei POP3 über SSL werden die Verbindungsdaten verschlüsselt an den Mail-Server übertragen: Die Daten können weiterhin mitgelesen werden - nur eben nicht mehr im Klartext. Wer lauscht, der muss zunächst die Verschlüsselung umgehen, und das schafft einen durchaus ernst zu nehmenden Schutz für Ihre Mail-Kommunikation.

Die Aktivierung von SSL für POP3 (und SMTP) ist dabei ganz einfach: Meist muß man nur eine Option einschalten. In Outlook-Express (und Outlook) findet man die unter den 'Erweiterten' Eigenschaften der Mail-Konten mit der Beschriftung 'Dieser Server erfodert eine sichere Verbindung (SSL).

Der Haken

Der Haken an der Sache ist dabei: Ihr Mail-Server muss ebenfalls SSL unterstützen, und Sie benötigen ein Zertifikat vom Mail-Server, das Sie in Windows installieren müssen. Die Installation des Zertifikates ist kein Problem - und auch praktisch alle Mail-Server Programme die es gibt unterstützen POP3 über SSL. Die Frage ist aber: Unterstützt Ihr eMail-Provider das auch - bzw.: gibt der diese Möglichkeit an Sie weiter?

Das gilt es herauszufinden. Unterstützt Ihr Mail-Provider diese Möglichkeit nicht, dann ist das in meinen Augen ein guter Grund, sich einen anderen Provider zu suchen. Und zwar sofort. Würde die Post nur noch Briefe ohne Umschlag befördern, dann würden Sie Ihre Post ja auch mit einem alternativen Dienst wie UPS verschicken.


eMail-Adressen bei D.I.E.


Offenbar ist es so, das wir unsere eMail-Adressen auf der Webseite nicht klar genug darstellen, weil es immer wieder passiert, das Mails nicht an den optimalen Stellen ankommt. Das ist zwar kein großes Problem weil wir natürlich intern sicherstellen das die Mails dann schon bei den richtigen Personen landen - es ist aber natürlich viel einfacher (und für Sie auch unter Umständen deutlich schneller) wenn die Mails von vornherein an die richtigen Personen geschickt werden. Daher versuche ich hier einmal in Kürze zu erklären wie das mit den Mail-Adressen bei D.I.E. funktioniert.

Zunächst einmal muss man wissen, das es bei uns Mail-Adressen für Personen - und solche für bestimmte Dienste gibt. Wenn man eigentlich ein Anliegen hat das an eine Person gerichtet ist - und das haben Sie eigentlich immer - dann verwendet man am besten auch deren oder dessen Mail-Adresse statt eine 'allgemeine' wie 'support@die.de'. Die 'Dienst' Adressen haben immer den Dienst als Account-Namen, die 'Personen'-Adressen setzen sich immer aus den Anfangsbuchstaben des Vor- und des Nachnamens zusammen.

Es gibt zwar eine ganze Reihe an Mail-Adressen von Personen bei D.I.E., aber die folgenden sind wohl die, die Sie am häufigsten brauchen:

Herr Andreas Glücks: ag@die.de
Herr Andreas Wölfer: aw@die.de
Herr Jürgen Nass: jn@die.de
Frau Doris Kock: dk@die.de
und meine (Thomas Wölfer): tw@die.de

'Dienst' Adressen sind solche die entweder vorgeschrieben sind, oder solche, die wir für (teilweise automatisierte) Prozesse verwenden:

'info@die.de' ist die Adresse aus dem Impressum - das muss laut Gesetz nämlich eine eMail-Adresse enthalten. Nachdem es hier nur darum geht überhaupt einen Kontakt aufzunehmen (und nachdem das aufgrund der Gesetzeslage auch die Adresse ist, die von Spammern bevorzugt verwendet wird) - ist das eben die 'info' Adresse. Wenn Sie irgend ein wichtiges Anliegen haben, dann senden Sie da besser nichts hin: Gesetze sind ja schön und gut, nur in diesem Fall eben irre unpraktisch, und darum haben Mails die über 'info' reinkommen auch keine sonderlich hohe Priorität.

Dann gibt es die 'support@die.de' Adresse: Die kann man verwenden wenn man nur irgendwen vom Support finden will und es eigentlich egal ist, wen. Letztlich landen mails an diese Adresse aber irgendwann bei mir - und ich schicke die dann an die 'passendste' Person. (Tipp: Das ist in 99% aller Fälle Herr Glücks... :-))

Dann gibt es noch 'räumlich' gebundene Adressen: oberhausen@die.de, muenchen@die.de und erfurt@die.de - dabei gehts darum, einen Ansprechpartner zu finden, der sich irgendwo in der Nähe befindet...

Und dann sind da noch Adressen für die Mailling-Listen Verwaltung, für den Versand von Lizenzen und so weiter und so fort... Man kann da natürlich was hinschicken - und das kommt auch irgendwann irgendwo an - aber schneller ist es ganz sicher, wenn Sie sich direkt an eine Person wenden.