7

Anmerkung Newsletter

Das Newsletter-System scheint mit Umlaut-Domains nicht umgehen zu können (aber auch meine Mails an eine bestimmte Domain mit Umlaut kommen zurück). Falls also jemand versucht, sich z.B. mit adresse@äöü.de einzutragen, wird das nicht klappen.

7 Kommentare

  1. 01
    Jo

    Ich habe noch keine Anwendung gesehen die IDNs in E-Mails unterstützt… in decodierter (adresse@xn--4ca0bs.de) Form funktionierts natürlich alles.. klar.. aber meiner Meinung nach sind IDNs überflüssig wie ein Kropf, ich hatte mal zu Testzwecken eine registriert um das mal aus nächster nähe zu sehen… die Domain ist wieder gekündigt… naja, die 5 Euro hätte ich mir sparen können, aber seis drum…

  2. 02

    Jo, die IDNs sind bisher nur in Webclients unterstützt, überall sonst funktionieren sie nicht. Daran ist die saublöde Idee schuld, die Umlautwandlung nicht im Nameserverprotokoll selber zu verankern, sondern in den Clientsystemen. Natürlich führt das genau dazu, das diese Domains völlig unbrauchbare Spoiler fürs Web sind.

    Ich hab meine (ürl.de) behalten, einfach weil es ein gutes Testobjekt für diverse Content-Management-Programme ist. Denn bisher habe ich noch keines gefunden das komplett damit klar kommt – entweder kodieren die die Domains falsch oder durch utf-8-Wandlung treten Probleme auf oder JavaScript kommt nicht damit klar – irgendeines der bekannten Probleme gibts immer. Ein ziemliches Trauerspiel diese ganze IDN-Geschichte. Dank der saublöden Implementierungen jetzt auch mit extra Phishing-Möglichkeiten. Egal, wird ja erstmal wieder aus den Browsern rausfliegen, zumindestens im Mozilla-Umfeld haben die sich ja dazu entschieden.

  3. 03

    Damn, der Newsletter ist echt spitze, aber die senden/abbrechen-Knöpfe sind falsch herum angeordnet. Zumindest sagt mir das meine Bequemlichkeit.

    grüße
    tobe

  4. 04
    HagK

    Warum registriert alle Welt zum Testen eine IDN-Domain? Das geht doch viel billiger mit einer Subdomain: email@wäreschön.example.com, fertig.

    Hätte man Umlaute-Co- und Decodierung in das DNS-Protokoll aufgenommen, wären wohl noch 10 Jahre vergangen – DNSSec ist seit 2000 als RFC standardisiert [www.faqs.org/rfcs/rfc3008.htm] und hat sich bisher auch nicht durchgesetzt. Warum sollte ein DNS-Provider so mal eben seinen Nameserver updaten? Für eine schnelle Einführung war daher eine Implementation in den clients notwendig. Und es zeigt uns, dass es eben keine Umlaute-Domains gibt, der client muss sich kümmern. Genauso, wie man bei Outlook Mails an den Namen verschickt (welche eMail-Adresse sich dahinter verbirgt, würde den geneigten MS-user nur verunsichern), hat ein client (in diesem Fall wohl das Newsleter-Skript) libidn aufzurufen, oder eben die Konvertierung selbst vorzunehmen. So einfach ist das. IDN ist derzeit nicht in die offizielle PHP-release eingeflossen, aber es gibt einen Patch den man vor dem Kompilieren anwenden kann [http://php-idn.bayour.com] ansonsten hilft, sofern erlaubt, ein system-call auf libidn – das muss dann natürlich installiert sein. Via PEAR/PECL kann man sein PHP auch erweitern [http://pecl.php.net/package/idn/].

    Ob man das alles will, bleibt natürlich dahingestellt.
    hagen

  5. 05

    Hagen, Du bist so ein tüpischer technisch daherschwafelnder Microsoft-doof-Finder.

    Du bist bestimmt cool.

  6. 06
    HagK

    Mit Sicherheit bin ich nicht ‚cool‘. Ein typischer (mit Ypsilon), pedantischer Techniker bin ich wohl, mit Microsoft habe ich meine Bauchschmerzen, ja.
    Schuld ist die Lebenserfahrung der letzten 10 Jahre – mein nächstes Leben ist ohne Computer. Back to the wood, root.

    Obiges Post erklärte nur, warum es eben sehr wohl sinvoll ist, IDN in die Applikationen zu verlagern, nicht in das Protokoll und zeigte die drei üblichen Ansätze auf. Geht nicht, gibt’s nicht.

  7. 07

Diesen Artikel kommentieren