Hallo, Am Mit, 27 Aug 2008, Sandy Drobic schrieb:
David Haller wrote:
Am Mit, 27 Aug 2008, Sandy Drobic schrieb:
David Haller wrote:
- Die Message-ID ist ungültig [..] Für die Message-ID muss der Hostname, der für die Erzeugung der Message-ID verwendet wird, kein öffentlich gültiger FQDN sein. Zumindest kann ich in RFC 2822 nichts dergleichen herauslesen. Die einzige Anforderung ist, dass die Message-ID einzigartig sein muss und dafür EMPFOHLEN wird, das in der Message-ID auf der rechten Seite der Hostname steht.
Wo hast du diese Info her?
Das habe ich auch nicht behauptet. Aber *.priv ist ungültig, da man diesen Namensraum nicht kontrolliert. Mein Vorschlag ist ja auch kein
Uhm, und da bin ich wieder mit der Frage, warum *.priv in einer Message-ID ungültig ist.
Ganz einfach: foo.priv "gehört" dir nicht, du hast keinerlei Kontrolle oder Handhabe, wer 'foo.priv' noch verwendet. Du kannst somit den "MUST"-Anforderungen des RfC nicht entsprechen.
Anders herum argumentiert: Angenommen, ich kontrolliere den Namensraum für die Domain example.com und habe dort 100 Backend-Server, die im Cluster die Domain example.com bedienen. Dann habe ich zwar eine FQDN Domain, wenn ich jedoch die Server intern alle mx.example.com nenne und nur im DNS die Rechner über mx001..mx100 anspreche, dann habe ich trotzdem das Risiko von Kollisionen, da ich 100 Rechner habe, die für die Message-ID den Hostnamen mx.example.com verwenden.
Aber du hast die Kontrolle über den Namensraum 'example.com' und DU kannst und mußt dafür sorgen, daß die Server gültige IDs generieren können. Wie ist egal.
Es hat also nichts mit dem ungültigen Namen zu tun, ob es eine einzigartige Message-ID ist oder nicht. Es muss nur ein einzigartiger Name sein.
Und genau das kannst du bei '*.priv' nicht garantieren.
Vergleiche z.B. mit dem Vorgehen von individual.de, die geben den Usern '<eigeneID>.user.individual.de' als "Hostnamensteil" zur Generierung der Messgage-IDs frei. Das ist genau die gleiche Vorgehensweise wie die von mir vorgeschlagene, "user.individual.de" ist auch kein öffentlicher FQDN, aber ein Namensraum unter Kontrolle von individual.de.
Nur dann gültig, wenn individual.de ein FQDN ist (und das ist es) und die <eigeneID>.user einzigartig ist. Dieses Schema funktioniert in der Tat.
Nicht, weil individual.de ein FQDN ist, sondern weil der FU-Berlin der Namensraum individual.de gehört, die Kontrolle über den Namensraum individual.de ausübt und jedem User eine eindeutige ID zuteilt, und diesem User dann jew. den Namensraum <ID>.user.individual.de um Message-IDs zu erstellen. Was der User dann "unter" <ID>.user.individual.de anstellt ist Sache des Users -- nur muß wiederum er garantieren können, daß die generierten IDs eindeutig sind. Es spricht z.B. nix dagegen, 1000 User über einen lokalen Server zu versorgen, und alle eigene IDs generieren zu lassen, z.B. durch: <left-part>@<localUID>.<ID>.user.individual.de Das demonstriert auch wieder, daß der Namensraum einer Message-ID eben genau gar nichts mit realen hostnamen oder IPs zu tun hat, und nur in so weit mit DNS zu tun hat, daß die second (third) level Domain und die TLD registriert sind -- aber auch dazu muß kein Eintrag im DNS sein, nur im Whois.
Auch die großen Mailprovider haben meist ein Schema, ähnliches das man für Msg-IDs verwenden kann. Oder man besorgt sich bei dyndns.org etc. einen Namensraum, der (auch, hauptsächlich) als Subdomain / Hostname fungiert. Man könnte dann z.B. auch nur.fuer.msgids.<NAME>.dyndns.org für die Message-IDs verwenden, Hauptsache eben "unterhalb" von "<NAME>.dyndns.org".
Hier jedoch hinkt der Vergleich. Die Empfehlung der Aufnahme des Hostnamens als Teil der Message-ID beruht auf der Annahme, dass der Host eine offizielle IP hat und diese unter einem öffentlichen Hostnamen eingetragen ist und deshalb einzigartig ist.
Nein. Du schmeißt DNS und Namensraum zusammen.
Einziges echtes Kriterium für die Message-ID ist, dass sie eindeutig sein muss und der Algorithmus zur Erzeugung dies sicherstellen muss. Wegen NAT und mehrerer Rechner hinter dem Router ist dies jedoch nicht gesichert bei einer DynDNS-Domain oder auch größeren Installation hinter einer öffentlichen IP.
Das ist kein Problem. Du registrierst bei dyndns 'example.dyndns.org'. Damit hast du die Kontrolle über diesen Namensraum, und kannst ihn für MsgIDs verwenden. Wie du das machst, ist egal -- du mußt nur dafür sorgen, daß die IDs, die du in diesem Namensraum generierst eindeutig sind. Du kannst z.B. das Schema '@<interner_hostname>.example.dyndns.org' verwenden. Das hat mit IPs, DNS und NAT überhaupt gar nichts zu tun. Es geht nur um die Kontrolle, die du über den Namensraum deiner von dir registrierten (sub-)domain hast.
Zusammenfassung: Egal, ob der Hostname nun ein öffentlich kontrollierter ist oder nicht, es muss sichergestellt werden, dass der Hostname einzigartig ist.
Und genau das meine ich. Das geht nur, wenn du die Kontrolle über den Namensraum hast.
"localhost.localdomain" erfüllt dies mit Sicherheit nicht, bei pahlke.pahlke-online.priv sehe ich die Gefahr einer Kollision außer in theoretischer Theorie nicht.
Du kannst es aber nicht _GARANTIEREN_ wie im RfC gefordert. Nimm einen weniger exotischen domain-part, dann stellt sich die Praxis auch ein (wobei .priv ist schon eher exotisch)... Ob du nun localhost.local[domain] oder foo.bar.priv verwendest ist irrelevant, du kannst die Eindeutigkeit nicht garantieren, da du den Namensraum nicht kontrollierst, ergo ist die Message-ID ungültig. Und - wenn man schon eine Domain _hat_ die man als Namensraum verwenden kann (und die sowieso in den Headern auftaucht)... Achso: guck mir mal in den Header. Die ID is speziell für dich. -dnh -- Mit wine läuft ständig irgendwas jetzt endlich, während irgendwas anderes nicht mehr läuft. In dieser Hinsicht emuliert es Windows perfekt... :-) -- ratti -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org