[Mailtechnik]: Pointer zwischendurch
Hallo Liste, insbesondere: Hallo Listenneulinge! In letzter Zeit häufen sich die Entführungen hier und ich kann nachvollziehen, warum das so ist. Mail ist ein überaus technisches Produkt, auch wenn es nicht so aussieht. Jede eMail schleppt unsichtbar mit sich herum Verwaltunginformationen. Darin sind enthalten Hinweise darüber, ## wer die Mail geschickt hat ## Hinweise des Listenmanagers ## der Spamstatus ## wie die Mail codiert ist ## welche Identität die Mail hat (Message-ID) und noch einiges mehr. Wer Probleme mit seinen Mails hat, guckt in diese Informationen (Mailheader). Im Falle der suse-linux-Liste kann man einen dieser Header (List-Post) zum Filtern der Mail nehmen. Das ist sehr praktisch, denn dieser Header bleibt immer gleich, daher ist auch das Filterergebnis immer richtig, unabhängig davon, ob in der Mail sonst noch eine Anweisung steckt, die das zunichte machen könnte. Die From:-Zeile wird vom Mailprogramm (MUA: Mail User Agent) gelesen und ausgegeben. Hier trägt man üblicherweise Vor- und Nachnamen ein. Ein Nick oder ein Vorname kann schon einmal der Grund für den Spamfilter sein, hier ein kleines Minus-Pünktchen zu setzen. Wenn es dann noch mehr zu mäkeln gibt, landet die Mail im Spamordner. Also: Vor- und Nachname verwenden. Ist unter Kollegen so üblich und wird als höflich empfunden. Die Message-ID (eine eindeutige Nummer zur Mailidentifikation) dient dazu, Mails zu identifizieren und Mails des gleichen Themas zusammenzustellen. Dieser Vorgang heißt Thread(ing). Die meisten MUAs können das. Sie werten die Message-ID aus und, falls sie hier nichts finden, das Subject. Wer nun das Threading aktiviert (nach diesem Schalter wird öfter mal gefragt, also wird diese Technik auch benutzt), erhält Mails eines Themas untereinander und zusammen präsentiert. Meist kann man diese Ansicht auch noch zuklappen, das macht die Mailbox übersichtlich. Was überhaupt nicht beliebt ist, ist das Kidnapping/Hijacking eines solchen Threads. Man nimmt sich eine alte Mail her, löscht den Inhalt und schreibt eine komplett neue Mail. Allerdings, der Schein trügt. Die Verwaltungsinformationen der ursprünglichen Mail sind noch vorhanden. Die Mail wird in den alten Thread einsortiert. Und dann gibt's mehr oder weniger herbe Reaktionen aus der Liste und keine Antwort. Abhilfe schafft ein Blick in die Konfigurationsmöglichkeiten des bevorzugten MUAs. Die meisten kennen den Punkt 'Neue Mai an Mailingliste'. Dann reicht ein Shortcut oder ein Klick auf ein Icon der Werkzeugleiste aus, um eine leere Mail mit dem Empfänger Mailingliste zu erzeugen einschließlich einer noch nicht gebrauchten Message-ID. Diese Mail erhält dann ihren eigenen Thread und jeder ist's zufrieden. Damit der Mailaustausch möglichst reibungslos von statten geht, die Liste lesbar bleibt und ein gewisses Gefühl der Zusammengehörigkeit entsteht, sind Technik und erwünschtes Verhalten in der 'Etikette' zusammengefaßt. Hinweise dazu laufen wöchtentlich über die Liste und wollen genau das verhindern, was immer wieder vorkommt - gekaperte Threads und unleserliche Mails. Die Etikette hat eine eigene Website: http://www.suse-etikette.de.vu/ (Ergänzungen und sonstige Anmerkungen bitte an mich persönlich; eine eigene ML für Fragen der Etikette gibt's auch. Wer also mitmachen will, ist willkommen). Das Einrichten von KMail und Thread-Hijacking habe ich auf meiner Website hinterlegt: http://www.eschkitai.de/linux/listreply.html http://www.eschkitai.de/linux/thread.html Have a lot of fun, Helga -- ## Content Developer OpenOffice.org: lang/DE ## Office-Suite für Linux, Mac, Windows -- http://de.openoffice.org/ ## Werkstatt & Information zu OpenSource -- http://www.eschkitai.de/ ## Etikette, nein Danke? -- http://www.suse-etikette.de.vu/
Hallo, Am Tue, 24 Aug 2004, Helga Fischer schrieb:
Die Message-ID (eine eindeutige Nummer zur Mailidentifikation) dient dazu, Mails zu identifizieren und Mails des gleichen Themas zusammenzustellen. Dieser Vorgang heißt Thread(ing). Die meisten MUAs können das.
Das Thema Message-ID ist komplexer. U.a. weiger(te?)n sich die Evolution-Programmierer, die RfCs korrekt zu implementieren. Wichtig ist nicht, _dass_ ein MUA[1] eine ID generiert, denn das wuerde unterwegs der erste SMTP-Server, der eine gueltige ID generieren kann, uebernehmen. Wichtig ist, dass die ID _EINDEUTIG_ ist! [2] Und das ist nur gewaehrleistet, wenn man die Kontrolle ueber den verwendeten Namensraum, i.d.R. den "domain-part" (dem hinter dem '@') hat. Verwendet nun der MUA einen domain-part wie 'linux.local' o.ae., dann ist die Eindeutigkeit _NICHT_ gewaehrleistet, die MsgID sollte also besser nicht generiert werden. Hier sollte man den MUA besser so einstellen, dass _KEINE_ Msg-ID generiert wird. Denn das kann der naechste SMTP-Server besser. -dnh, der hier zu dem Thema schon oefter geschrieben hat, und der ggfs. mal wieder die relevanten RfCs raussucht... BTW@Helga: wenn du "FAQiges" hast, kannst du das nicht (ggfs. mit nem kurzen Kommentar) an die FAQ-ML mailen? PS: diesmal keine Zufallssig [1] MUA := "Mail User Agent", siehe auch die Etikette und die FAQ [2] und wer mal per Google oder sonstwie nach einer bestimmten Mail oder einem Newsbeitrag gesucht hat, sollte das nachvollziehen koennen. Auch wenn es bei Mails selten zu Kollisionen kommt, die IDs sollten _garantiert_ eindeutig sein, zumindest solange nicht boeswillig versucht wird, eine Msg-ID zu kopieren o.ae. -- [Evolution - Message-ID] Oh ja... Apropos: die libcamel (die fuer diesen Muell verantwortlich ist) ist, aehm. "interessant" zu lesen... Und NEIN! Ich habe keine Lust, den Muell zu fixen. Es sei denn, man zahlt mir Schmerzensgeld. [David Haller in suse-linux, gef. von C. Boltz]
Hallo David, David Haller schrieb:
Am Tue, 24 Aug 2004, Helga Fischer schrieb:
Die Message-ID (eine eindeutige Nummer zur Mailidentifikation) dient dazu, Mails zu identifizieren und Mails des gleichen Themas zusammenzustellen. Dieser Vorgang heißt Thread(ing). Die meisten MUAs können das.
Das Thema Message-ID ist komplexer. U.a. weiger(te?)n sich die Evolution-Programmierer, die RfCs korrekt zu implementieren.
Wichtig ist nicht, _dass_ ein MUA[1] eine ID generiert, denn das wuerde unterwegs der erste SMTP-Server, der eine gueltige ID generieren kann, uebernehmen.
Das ist interessant. Generiert also auch der MTA, der installiert ist? So habe ich das bisher verstanden.
Wichtig ist, dass die ID _EINDEUTIG_ ist! [2]
Und das ist nur gewaehrleistet, wenn man die Kontrolle ueber den verwendeten Namensraum, i.d.R. den "domain-part" (dem hinter dem '@') hat.
Wenn man bei mir schaut, sieht man einen Instrumentennamen. So eindeutig ist das wohl nicht, aber so heisst nun mein Rechner.
Verwendet nun der MUA einen domain-part wie 'linux.local' o.ae., dann ist die Eindeutigkeit _NICHT_ gewaehrleistet, die MsgID sollte also besser nicht generiert werden.
Ja, linux.local scheint die SuSEsche Voreinstellung zu sein. Gruss Sven
Hallo, Am Thu, 26 Aug 2004, Sven Rodenbeck schrieb:
David Haller schrieb:
Wichtig ist nicht, _dass_ ein MUA[1] eine ID generiert, denn das wuerde unterwegs der erste SMTP-Server, der eine gueltige ID generieren kann, uebernehmen.
Das ist interessant. Generiert also auch der MTA, der installiert ist? So habe ich das bisher verstanden.
Ein korrekt konfigurierter MTA sollte das machen. Das ist in den relevanten RfCs eindeutig festgelegt. Es kommt aber vor, dass unterwegs ueberall defekte MTAs sind, so ist hier IIRC schonmal ne (SPAM-) Mail aufgeschlagen, wo erst mein lokaler sendmail die ID generiert hat.
Wichtig ist, dass die ID _EINDEUTIG_ ist! [2]
Und das ist nur gewaehrleistet, wenn man die Kontrolle ueber den verwendeten Namensraum, i.d.R. den "domain-part" (dem hinter dem '@') hat.
Wenn man bei mir schaut, sieht man einen Instrumentennamen. So eindeutig ist das wohl nicht, aber so heisst nun mein Rechner.
Die ID ist ungueltig, da der domain-part keine gueltige Domain ist. Dein MUA ist also falsch konfiguriert, zumal das mit Mutt ja wirklich einfach ist. set hostname="host.domain.tld" ==== RfC 2822 ==== 3.6.4. Identification fields [..] The message identifier (msg-id) itself MUST be a globally unique identifier for a message. The generator of the message identifier MUST guarantee that the msg-id is unique. [..] Though other algorithms will work, it is RECOMMENDED that the right hand side contain some domain identifier (either of the host itself or otherwise) such that the generator of the message identifier can guarantee the uniqueness of the left hand side within the scope of that domain. ====
Verwendet nun der MUA einen domain-part wie 'linux.local' o.ae., dann ist die Eindeutigkeit _NICHT_ gewaehrleistet, die MsgID sollte also besser nicht generiert werden.
Ja, linux.local scheint die SuSEsche Voreinstellung zu sein.
Und ist auch kein gueltiger domain-part.
==== RfC 2606 ====
2. TLDs for Testing, & Documentation Examples
[..]
To safely satisfy these needs, four domain names are reserved as
listed and described below.
.test
.example
.invalid
.localhost
".test" is recommended for use in testing of current or new DNS
related code.
".example" is recommended for use in documentation or as examples.
".invalid" is intended for use in online construction of domain
names that are sure to be invalid and which it is obvious at a
glance are invalid.
The ".localhost" TLD has traditionally been statically defined in
host DNS implementations as having an A record pointing to the
loop back IP address and is reserved for such use. Any other use
would conflict with widely deployed code which assumes this use.
====
BTW: falls du nicht weisst, was du als domain-part verwenden sollst:
Du kannst z.B. wenn du einen Account bei news.individual.de (ex
news.cis.dfn.de) kannst du das verwenden
("ID-
Hallo David, David Haller schrieb:
Am Thu, 26 Aug 2004, Sven Rodenbeck schrieb:
David Haller schrieb:
Wichtig ist nicht, _dass_ ein MUA[1] eine ID generiert, denn das wuerde unterwegs der erste SMTP-Server, der eine gueltige ID generieren kann, uebernehmen.
Das ist interessant. Generiert also auch der MTA, der installiert ist? So habe ich das bisher verstanden.
Ein korrekt konfigurierter MTA sollte das machen. Das ist in den relevanten RfCs eindeutig festgelegt. Es kommt aber vor, dass unterwegs ueberall defekte MTAs sind, so ist hier IIRC schonmal ne (SPAM-) Mail aufgeschlagen, wo erst mein lokaler sendmail die ID generiert hat.
Aha, hier bin ich auch erwischt worden. Habe meinem MasqMail auch nichts dazu mitgeteilt. Das muss ich mir tatsächlich mal ansehen, genauso auf einer anderen SuSE Postfix.
Wichtig ist, dass die ID _EINDEUTIG_ ist! [2]
Und das ist nur gewaehrleistet, wenn man die Kontrolle ueber den verwendeten Namensraum, i.d.R. den "domain-part" (dem hinter dem '@') hat.
Wenn man bei mir schaut, sieht man einen Instrumentennamen. So eindeutig ist das wohl nicht, aber so heisst nun mein Rechner.
Die ID ist ungueltig, da der domain-part keine gueltige Domain ist. Dein MUA ist also falsch konfiguriert, zumal das mit Mutt ja wirklich einfach ist.
set hostname="host.domain.tld"
Das hatte ich doch glatt übersehen. Jetzt sollte es stimmen. Nur *@svenrodenbeck.de müsste aber doch auch reichen?!
BTW: falls du nicht weisst, was du als domain-part verwenden sollst: Du kannst z.B. wenn du einen Account bei news.individual.de (ex news.cis.dfn.de) kannst du das verwenden ("ID-
.user.uni-berlin.de"), dann gibt es bei vielen Providern aehnliche Schemata, meist <userid>.<praefix>.provider.tld, dann kannst du deinen dyndns hostnamen verwenden und und und. Oder man konfiguriert MUA und MTA so, dass _keine_ Message-Id generiert wird, das sollte dann der SMTP-Server machen, bei dem du deine Mails ablieferst.
Danke für die Tips, ein schönes Feld zu Probieren. -- Gruss Sven
Hallo, Am Sun, 29 Aug 2004, Sven Rodenbeck schrieb:
David Haller schrieb: [..] Nur *@svenrodenbeck.de müsste aber doch auch reichen?!
Ja. Besser ist es aber schon, den hostnamen mit reinzunehmen, u.a. weil du dann weniger Spam bekommst bzw. den leichter ausfiltern kannst. Die Spammer mailen ja an alles was ein @ drin hat... -dnh -- Auch wieder richtig, aber zum bloed posten brauch ich kein Hirn. Ausserdem tipp ich schneller, als ich denke :). -- Klaus Muth
Am Donnerstag, den 26.08.2004, 09:47 +0200 schrieb David Haller:
Die ID ist ungueltig, da der domain-part keine gueltige Domain ist. Dein MUA ist also falsch konfiguriert, zumal das mit Mutt ja wirklich einfach ist.
IMHO muß eine Mail-ID gar keinen Domainpart enthalten - das ist nur ein Trick, um Eindeutigkeit zu garantieren. Oder? Gruß, Ratti -- -o) fontlinge | Fontmanagement for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/
Hallo, Am Sun, 29 Aug 2004, Joerg Rossdeutscher schrieb:
Am Donnerstag, den 26.08.2004, 09:47 +0200 schrieb David Haller:
Die ID ist ungueltig, da der domain-part keine gueltige Domain ist. Dein MUA ist also falsch konfiguriert, zumal das mit Mutt ja wirklich einfach ist.
IMHO muß eine Mail-ID gar keinen Domainpart enthalten - das ist nur ein Trick, um Eindeutigkeit zu garantieren. Oder?
Jein. Es ist eben wohl die einzige Moeglichkeit. Schau dir die schon
erwaehnten RfCs mal an... ;)
BTW: Wann flickst du mal deine Msg-ID? Kann man die in Evolution nicht
mal abstellen? So das dein MTA das machen kann?
Denn diese %#!@ libcamel verwendet(e?) nur 'gethostname'. Und das
liefert AFAIK generell nur den hostnamen, und nicht den FQDN. Es fehlt
das 'gethostbyname':
ACHTUNG: UNGETESTET! Ich habe Evolution nie verwendet! Und will es
auch nicht!!!1eins!
==== ~/src/Evolution/evolution-1.0.8.use_fqdn.dh.patch ====
--- evolution-1.0.8.orig/camel/camel-mime-utils.c Thu Jun 6 22:36:29 2002
+++ evolution-1.0.8/camel/camel-mime-utils.c Sat Jul 27 06:24:50 2002
@@ -33,6 +33,7 @@
#include
Hallo Ratti, Joerg Rossdeutscher schrieb:
Am Donnerstag, den 26.08.2004, 09:47 +0200 schrieb David Haller:
Die ID ist ungueltig, da der domain-part keine gueltige Domain ist. Dein MUA ist also falsch konfiguriert, zumal das mit Mutt ja wirklich einfach ist.
IMHO muß eine Mail-ID gar keinen Domainpart enthalten - das ist nur ein Trick, um Eindeutigkeit zu garantieren. Oder?
Genau darum dreht es sich. Wie garantiert man die Eindeutigkeit? Wahrscheinlich könnte es doch sein, daß mein Rechner aus unerfindlichen Gründen auch ratti heißt. ;-) Wenn ich nun so dreist bin, auch den User camel zu nehmen, und damit eine Mail-ID zu kreieren... Ok, die Wahrscheinlichkeit ist gering, aber eben gegeben. Davids Hinweise habe ich so aufgefasst, dass es besser ist, eine registrierte Domain zu nehmen (zumindest treibt man dann keinen Unfug). Richtig ist wohl, Du könntest einen eindeutigen Zeichensatz nach dem @ folgen lassen. Die grosse Frage nach der Eindeutigkeit ist aber anscheinend, wie man das kontrolliert / kontrollieren kann! -- Gruss Sven
Moin, Am Montag, den 30.08.2004, 01:35 +0200 schrieb David Haller:
BTW: Wann flickst du mal deine Msg-ID? Kann man die in Evolution nicht mal abstellen? So das dein MTA das machen kann?
Nein. Geht nicht. Ein Feature von Evolution besteht darin, daß dort so gut wie gar nichts einzustellen ist.
==== ~/src/Evolution/evolution-1.0.8.use_fqdn.dh.patch ====
Ohgottogott. 1.0.8... Ich benutze 1.5, der Patch findet nicht einen einzigen Hook.
Denn diese %#!@ libcamel verwendet(e?) nur 'gethostname'. Und das liefert AFAIK generell nur den hostnamen, und nicht den FQDN. Es fehlt das 'gethostbyname':
retval = gethostname (host, sizeof (host)); if (retval == 0 && *host) h = camel_gethostbyname (host, NULL); else host[0] = '\0'; COUNT_LOCK (); msgid = g_strdup_printf ("%d.%d.%d.camel@%s", (int) time (NULL), getpid (), count++, h ? h->h_name : (*host ? host : "localhost.localdomain")); COUNT_UNLOCK (); if (h) camel_free_host (h); return msgid; ...ich schätze mal, das kriege ich auch noch gefixt, ohne C zu können...
Hattest du damals den patch nicht auch an (einen der) Hauptautoren von Evolution weitergegeben?
Ist ewig her, aber ich glaube, die wollten das Ding nicht haben, mit der Begründung, die Eindeutigkeit von MessageIDs sei technisch überholt, weil man sich ja doch nicht drauf verlassen könne. Tja. Da für meinen Geschmack kein Mailprogramm auch nur im entferntesten so brauchbar wie Evolution ist, bin ich wohl dran gebunden... Gruß, Ratti -- -o) fontlinge | Fontmanagement for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/
Hallo, Am Tue, 31 Aug 2004, Joerg Rossdeutscher schrieb:
Am Montag, den 30.08.2004, 01:35 +0200 schrieb David Haller:
BTW: Wann flickst du mal deine Msg-ID? Kann man die in Evolution nicht mal abstellen? So das dein MTA das machen kann?
Nein. Geht nicht. Ein Feature von Evolution besteht darin, daß dort so gut wie gar nichts einzustellen ist.
*grr*
==== ~/src/Evolution/evolution-1.0.8.use_fqdn.dh.patch ====
Ohgottogott. 1.0.8... Ich benutze 1.5, der Patch findet nicht einen einzigen Hook.
*hihi* Das hab ich mir gedacht ;)
Denn diese %#!@ libcamel verwendet(e?) nur 'gethostname'. Und das liefert AFAIK generell nur den hostnamen, und nicht den FQDN. Es fehlt das 'gethostbyname':
retval = gethostname (host, sizeof (host));
if (retval == 0 && *host) h = camel_gethostbyname (host, NULL); else host[0] = '\0';
COUNT_LOCK (); msgid = g_strdup_printf ("%d.%d.%d.camel@%s", (int) time (NULL), getpid (), count++, h ? h->h_name : (*host ? host : "localhost.localdomain")); COUNT_UNLOCK ();
if (h) camel_free_host (h);
return msgid;
Mal abgesehen davon, dass "localhost.localdomain" auch ungueltig ist... Das erweckt die Hoffnung, dass da jemand das Licht gesehen hat, und das mit dem "camel_gethostbyname" eingebaut hat. Damit koennte es evtl. durch eine Umkonfiguration in der /etc/hosts machbar sein s.u. Wie sieht deine "localhost" Definition in /etc/hosts aus? Was spuckt "gethostbyname"[1] bei dir aus? Evtl. reicht es, den FQDN als erstes zu nennen: 127.0.0.1 ratti.domain.tld localhost ratti Die Aliase "localhost" und "ratti" werden weiterhin funktionieren. Ich verwende hier z.B.: 127.0.0.1 slarty.dhaller.de localhost slarty Die Msg-Id wird bei mir aber eh anders, eben "richtig" und ueber die richtige Konfiguration (set hostname="...") in Mutt bzw. in sendmail (Dj... in der sendmail.cf) gemacht. Nur dass sich niemand wundert, warum meine Msg-IDs nicht zu Obigem passen. Ggfs. muesste ich mir also "camel_gethostbyname" anschauen.
...ich schätze mal, das kriege ich auch noch gefixt, ohne C zu können...
Ich kann mir das auch mal anschauen. Da ich mir Evolution eh nicht backen werde, kannst du mir die Definition von 'camel_gethostbyname' mal mailen?
Hattest du damals den patch nicht auch an (einen der) Hauptautoren von Evolution weitergegeben?
Ist ewig her,
Ja :)
aber ich glaube, die wollten das Ding nicht haben, mit der Begründung, die Eindeutigkeit von MessageIDs sei technisch überholt, weil man sich ja doch nicht drauf verlassen könne.
*HRRMPF* Die Frage, _warum_ man sich nicht darauf verlassen kann beantworten sie ja gleich selbst: weil die "Programmierer" der Mail-Clients wie OE und Evolution (sic!) und (mancher weniger) Mail-Server(?) die RfCs nicht korrekt implementieren.... Motto: "Andere machen es auch falsch, also machen wir es natuerlich auch falsch!!!" ??? "Wir muessen alle Bugs von Outlook implementieren!!!" ??? ___ _ _ ___ / _ \ __| |___ _ _ __ __ _(_)__|__ \ | (_) / _` / -_) '_| \ V V / / -_)/_/ \___/\__,_\___|_| \_/\_/|_\___(_) @@@@@@ @@@@@@@ @@@@@@@@ @@@ @@@ @@! !@@ @@@@@@@@ @@@@@@@@ @@@@@@@@@ @@@ @@@ @@! !@@ !@! @!! @@! @@@ @@! @@@ !@@ @@! @@@ !@! @!! !@@!@! !@! @!@ !@! @!@ !@! !@! @!@ !@@!@! @!@!@!!@!! @!@!@!@! @!@!!@! !@! @!@!@ @!@!@!@! @!@!@!!@!! !: :!! !!!@!!!! !!@!@! !!! !!@!! !!!@!!!! !: :!! :!: !:! !!: !!! !!: :!! :!! !!: !!: !!! :!: !:! ::: ::: :!: !:! :!: !:! :!: !:: :!: !:! ::: ::: :: ::: :: ::: ::: :::: :: ::: : : : : : : :: :: : : : : Du weisst spaetestens jetzt, was ich von Evolution halte (naemlich dass es nach /dev/null entsorgt gehoert). Oder dass man den Entwicklern mal _heftigst_ in den Hintern treten sollte, so dass sie sich auf eben diese Hintern setzen und ihren Scheiss endlich mal richtig machen. Und ja, an Unix/Linux und generell an OpenSource Software lege ich hoehere Masstaebe an! Da ist fuer mich die Moeglichkeit, die korrekte Generierung der Msg-ID konfigurieren zu koennen bzw. mindenstens die Generierung einer defekten ID abschalten zu koennen ein absolutes KO-Kriterium. Wobei, mir ist es eh schleierhaft, wie jemand, der viele Mails liest und schreibt, was anderes als Mutt oder Gnus verwenden kann.
Tja. Da für meinen Geschmack kein Mailprogramm auch nur im entferntesten so brauchbar wie Evolution ist, bin ich wohl dran gebunden...
Tja, das glaub ich dir nicht ganz... Fuer mich macht sich Evolution z.B. durch o.g. Defekt schlicht und final unbrauchbar. Egal was es sonst noch an Features bietet... Das war fuer mich IIRC damals, als Newbie, auch einer der Punkte, warum ich kmail nicht verwendet habe, sondern XFMail, weil ich noch keinen MTA aufgesetzt hatte... Aber, s.o., vielleicht gibt's ja Hoffnung fuer Evolution, IIRC hat es ja ein paar nette Features... -dnh [1] zur einfacheren Ueberpruefung: $ echo -e "FQDN: \t`hostname -f`"; \ for x in `hostname -a`; do echo -e "alias:\t$x"; done; \ echo -e "IP:\t`hostname -i`"; [beim Copy & Paste das fuehrende '$' weglassen!]. Die Ausgabe von 'hostname -f', ist vermutlich die, die Evolution verwendet. Vgl. obige Befehle jew. mit 'ltrace': 'hostname' ruft nur 'gethostname' auf (das was Evolution macht(e)), hostname -f ruft 'gethostbyname' mit dem Ergebnis von 'gethostname' auf. Um genaueres zu sagen muesste ich mir das 'camel_gethostbyname' anschauen. -- You are wise, witty, and wonderful, but you spend too much time reading this sort of trash.
Moin, Am Dienstag, den 31.08.2004, 05:43 +0200 schrieb David Haller:
Am Tue, 31 Aug 2004, Joerg Rossdeutscher schrieb:
if (retval == 0 && *host) h = camel_gethostbyname (host, NULL); else host[0] = '\0';
Das erweckt die Hoffnung, dass da jemand das Licht gesehen hat, und das mit dem "camel_gethostbyname" eingebaut hat. Damit koennte es evtl. durch eine Umkonfiguration in der /etc/hosts machbar sein s.u.
Wie sieht deine "localhost" Definition in /etc/hosts aus? Was spuckt "gethostbyname"[1] bei dir aus?
Den Rest deiner Mail werde ich morgen ausführlicher beantworten, nur soviel schon mal vorab: Mein Rechner heisst "ratti.local" im Netz "local" und hängt hinter dem (Mail)server "server.local". Der Server(!) schreibt die Adressen um. Das heisst: Der FQDN in der ID müsste "gesindel.de" sein - genau diese Domain findest du auf meinem Rechner aber nirgends. Nur der Mailserver kennt die. Es bleiben also mehrere Möglichkeiten: a) Eine Umgebungsvariable, die von $MUA verwendet wird. Schlecht, denn würden hier 30 Rechner stehen, könnten die ja Duplikate erzeugen. b) $MUA erzeugt überhaupt keine ID oder der lokale Server löscht sie raus, und dann b1) Der lokale Server generiert eine neue. b2) Der Mailserver des Providers generiert eine neue. c) Wir finden uns mit der Welt ab, wie sie ist und beerdigen das Konzept eindeutiger IDs. Es wird sie definitiv nie wieder geben. Ist Scheiße, ist aber so, und alle Mail-verarbeitende Programme generieren längst interne Checksummen, statt die ID zu verwenden. Allein schon deswegen, weil bei 80% Spam/Viren/Trojaner-Anteil für Otto Normaluser in den USA nichts verlässlich ist, was in so einem Mailheader drinsteht. Meine Gedanken kreisen nur um b2) und c). Gruß, Ratti -- -o) fontlinge | Fontmanagement for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/
Hallo, Am Tue, 31 Aug 2004, Joerg Rossdeutscher schrieb:
Am Dienstag, den 31.08.2004, 05:43 +0200 schrieb David Haller:
Am Tue, 31 Aug 2004, Joerg Rossdeutscher schrieb:
if (retval == 0 && *host) h = camel_gethostbyname (host, NULL); else host[0] = '\0';
Das erweckt die Hoffnung, dass da jemand das Licht gesehen hat, und das mit dem "camel_gethostbyname" eingebaut hat. Damit koennte es evtl. durch eine Umkonfiguration in der /etc/hosts machbar sein s.u.
Wie sieht deine "localhost" Definition in /etc/hosts aus? Was spuckt "gethostbyname"[1] bei dir aus?
Den Rest deiner Mail werde ich morgen ausführlicher beantworten, nur soviel schon mal vorab:
Mein Rechner heisst "ratti.local" im Netz "local" und hängt hinter dem (Mail)server "server.local". Der Server(!) schreibt die Adressen um.
Aber nicht die Msg-IDs. Und das ist auch gut so. Eigentlich. Sofern keine kaputten MUAs kaputte MIDs generieren.
Das heisst: Der FQDN in der ID müsste "gesindel.de" sein - genau diese Domain findest du auf meinem Rechner aber nirgends. Nur der Mailserver kennt die.
Ah. Das ist doof. Warum eigentlich? Das Konzept der subdomains ist dir bekannt? Und dass es fuer die MIDs nur auf den Namensraum, nicht auf's DNS ankommt? 127.0.0.1 ratti.local.gesindel.de localhost ratti.local ratti Das "local" im FQDN kannst du natuerlich auch weglassen oder durch was anderes ersetzen. Und IIRC gibt's nur eine kaputte App (welche das ist weiss ich aber grad nicht), die das 'localhost' an erster Stelle braucht. Alles andere sollte so funktionieren wie jetzt. Wobei das 'ratti.local' ja evtl. auch an die LAN-IP gebunden ist, und nicht an loopback.
Es bleiben also mehrere Möglichkeiten:
a) Eine Umgebungsvariable, die von $MUA verwendet wird. Schlecht, denn würden hier 30 Rechner stehen, könnten die ja Duplikate erzeugen.
Keine Moeglichkeit, richtig. Man kann den FQDN aber ausreichend qualifizieren (s.o.), durch 'hostname.domain.tld' oder 'hostname.subdomain.domain.tld' oder noch tiefer... Bes. in Laendern, bei denen z.B. '.ac.tld' oder '.co.tld.' ueblich sind, findet man sowas recht haeufig, z.B. "www.cl.cam.ac.uk". Und die Studenten/Mitarbeiter am "computer lab" der University of Cambridge haben vermutlich nochmal ne Stufe tiefer: username.stud.cl.cam.ac.uk, was sich dennoch wunderbar als domain-part fuer MIDs verwenden laesst, und falls der user mehrere rechner hat, ist der FQDN dann halt hostname.username.stud.cl.cam.ac.uk. Kein Problem das.
b) $MUA erzeugt überhaupt keine ID
Das waere vorzuziehen...
oder der lokale Server löscht sie raus, und dann
... denn das verstoesst gegen die RfCs. Und ich weiss nicht, ob / wie man z.B. sendmail so konfiguriert. Moeglich ist es aber sicherlich. Wie's bei postfix und anderen MTAs aussieht weiss ich nicht.
b1) Der lokale Server generiert eine neue.
Das waere vorzuziehen, s.o.
b2) Der Mailserver des Providers generiert eine neue.
Das waere auch gut.
c) Wir finden uns mit der Welt ab, wie sie ist und beerdigen das Konzept eindeutiger IDs. Es wird sie definitiv nie wieder geben. Ist Scheiße, ist aber so, und alle Mail-verarbeitende Programme generieren längst interne Checksummen, statt die ID zu verwenden.
NAK!
Allein schon deswegen, weil bei 80% Spam/Viren/Trojaner-Anteil für Otto Normaluser in den USA nichts verlässlich ist, was in so einem Mailheader drinsteht.
Ja? Und? Das ist ein hervorragendes Kriterium um Spam etc.
auszusortieren.
-dnh
--
"Being disintegrated makes me ve-ry an-gry!"
Am Mittwoch, den 01.09.2004, 01:37 +0200 schrieb David Haller:
Am Tue, 31 Aug 2004, Joerg Rossdeutscher schrieb:
Am Dienstag, den 31.08.2004, 05:43 +0200 schrieb David Haller:
Mein Rechner heisst "ratti.local" im Netz "local" und hängt hinter dem (Mail)server "server.local". Der Server(!) schreibt die Adressen um.
Aber nicht die Msg-IDs. Und das ist auch gut so. Eigentlich. Sofern keine kaputten MUAs kaputte MIDs generieren.
Nein, natürlich nicht die MessageID, aber da die FQDN Teil der ID ist, ist die ID falsch, weil die Domain unbekannt ist.
Das heisst: Der FQDN in der ID müsste "gesindel.de" sein - genau diese Domain findest du auf meinem Rechner aber nirgends. Nur der Mailserver kennt die.
Ah. Das ist doof. Warum eigentlich? Das Konzept der subdomains ist dir bekannt? Und dass es fuer die MIDs nur auf den Namensraum, nicht auf's DNS ankommt?
Das ist nicht sinnvoll, das gesamte Netzwerk auf "gültige" Namen umzustellen, nur weil ein Programm konzeptionell falsch arbeitet. Die Domain "local." ist ja extra für Rendezvous/ZeroConf vergeben, und das ist auch sinnvoll.
127.0.0.1 ratti.local.gesindel.de localhost ratti.local ratti
Das "local" im FQDN kannst du natuerlich auch weglassen oder durch was anderes ersetzen. Und IIRC gibt's nur eine kaputte App (welche das ist weiss ich aber grad nicht), die das 'localhost' an erster Stelle braucht.
Und alles, um Evolution eine ID beizubringen? Warum nicht gleich die glibc patchen? :-)))
Alles andere sollte so funktionieren wie jetzt.
Wobei das 'ratti.local' ja evtl. auch an die LAN-IP gebunden ist, und nicht an loopback.
Es bleiben also mehrere Möglichkeiten:
b) $MUA erzeugt überhaupt keine ID
Das waere vorzuziehen...
oder der lokale Server löscht sie raus, und dann
.. denn das verstoesst gegen die RfCs. Und ich weiss nicht, ob / wie man z.B. sendmail so konfiguriert. Moeglich ist es aber sicherlich. Wie's bei postfix und anderen MTAs aussieht weiss ich nicht.
Wo steht das? Meines Wissens ist es erlaubt, Mails ohne ID rauszugeben - Pflicht ist dann aber die Erzeugung einer solchen. Ich halte das für die allerbeste Lösung. Mit sowas soll sich der Provider rumschlagen. Im Falle der ID ist das zwar kein Argument, aber generell halte ich es konzeptionell für schlau, daß _der_ Rechner an dem Mails rumfummelt, der als "eigentlicher" Mailserver 24/7 im Netz ist und nicht bloß mein "Mailcache" zuhause, der den Clients die Post abnimmt oder abholt.
c) Wir finden uns mit der Welt ab, wie sie ist und beerdigen das Konzept eindeutiger IDs. Es wird sie definitiv nie wieder geben. Ist Scheiße, ist aber so, und alle Mail-verarbeitende Programme generieren längst interne Checksummen, statt die ID zu verwenden.
NAK!
Es gibt meines Wissens keine Software mehr, die die IDs wirklich auswertet. Mal abgesehen vom Threading der MUAs, wo mit einer Wahrscheinlichkeit von 1 zu x-Fantastillionen eine Mail schlimmstenfalls im falschen Thread landen könnte. Das passiert aber jetzt schon bei praktisch ALLEN Usern, die sich mit mehr als einem Benutzer eine Domain teilen und wo der MUA die ID generiert. Also ALLE*) Firmenuser, ALLE Haushalte mit T-Online-Mitbenutzer, etc. - dort generieren die MUAs IDs, bei denen mit exakt der gleichen Wahrscheinlichkeit einfach mal zwei MUAs die gleiche generieren könnten. Das siehst du nur nicht, weil hinten dran brav "@domain" steht. Da keine Firma ein "MessageID-Broadcast" fährt, kann jeder Rechner bereits (von anderen) verwendete IDs nochmal vergeben. *) natürlich ausgenommen die, die statt POP3/SMTP ganz andere Lösungen verwenden.
Allein schon deswegen, weil bei 80% Spam/Viren/Trojaner-Anteil für Otto Normaluser in den USA nichts verlässlich ist, was in so einem Mailheader drinsteht.
Ja? Und? Das ist ein hervorragendes Kriterium um Spam etc. auszusortieren.
Das die "irgendwas" formal korrektes reinklatschen, heisst ja nicht, daß es filterfähig wäre. Die lernen ja auch dazu. Gruß, Ratti -- -o) fontlinge | Fontmanagement for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/
Hallo, Am Wed, 01 Sep 2004, Joerg Rossdeutscher schrieb:
Am Mittwoch, den 01.09.2004, 01:37 +0200 schrieb David Haller:
Am Tue, 31 Aug 2004, Joerg Rossdeutscher schrieb:
Am Dienstag, den 31.08.2004, 05:43 +0200 schrieb David Haller:
Mein Rechner heisst "ratti.local" im Netz "local" und hängt hinter dem (Mail)server "server.local". Der Server(!) schreibt die Adressen um.
Aber nicht die Msg-IDs. Und das ist auch gut so. Eigentlich. Sofern keine kaputten MUAs kaputte MIDs generieren.
Nein, natürlich nicht die MessageID, aber da die FQDN Teil der ID ist, ist die ID falsch, weil die Domain unbekannt ist.
Eben.
Das heisst: Der FQDN in der ID müsste "gesindel.de" sein - genau diese Domain findest du auf meinem Rechner aber nirgends. Nur der Mailserver kennt die.
Ah. Das ist doof. Warum eigentlich? Das Konzept der subdomains ist dir bekannt? Und dass es fuer die MIDs nur auf den Namensraum, nicht auf's DNS ankommt?
Das ist nicht sinnvoll, das gesamte Netzwerk auf "gültige" Namen umzustellen, nur weil ein Programm konzeptionell falsch arbeitet. Die Domain "local." ist ja extra für Rendezvous/ZeroConf vergeben, und das ist auch sinnvoll.
Nicht umstellen. Nur ergaenzen.
127.0.0.1 ratti.local.gesindel.de localhost ratti.local ratti [..] Und alles, um Evolution eine ID beizubringen? Warum nicht gleich die glibc patchen? :-)))
Nein, wenn ich richtig vermute, was das camel_gethostbyname macht, dann reicht es _nur_ die /etc/hosts um den FQDN an erster Stelle nach der IP zu ergaenzen. Ausserdem finde ich "domains" wie .local einfach wiedersinnig, sofern man denn schon eine eigen domain hat, denn dann hat man die _hierarchische_ Struktur der Domains nicht verstanden. Ohne eigene Domain und mit kaputten MUA wird's natuerlich unaesthetisch. Aber das ist ja nicht der Fall. Jeder MUA sollte aber eigentlich sowas wie das 'set hostname' von Mutt haben. Und jeder MTA muss es (AFAIK) haben. Evolution ist einfach nur defekt. [..]
b) $MUA erzeugt überhaupt keine ID
Das waere vorzuziehen...
oder der lokale Server löscht sie raus, und dann
.. denn das verstoesst gegen die RfCs. Und ich weiss nicht, ob / wie man z.B. sendmail so konfiguriert. Moeglich ist es aber sicherlich. Wie's bei postfix und anderen MTAs aussieht weiss ich nicht.
Wo steht das? Meines Wissens ist es erlaubt, Mails ohne ID rauszugeben - Pflicht ist dann aber die Erzeugung einer solchen.
Ja. Aber man darf die ID nur erzeugen, wenn man die Eindeutigkeit im Sinne von (IIRC) RfC 2822 gewaehrleisten kann. Ansonsten _darf_ man keine ID generieren. Andererseits darf man IIRC keine bestehenden IDs aendern oder loeschen (weil es dann zu verschiedenen IDs unterwegs kommen kann). Das heisst im Klartext: die MID ist ein "write once" Header -- sobald vorhanden muss der Header unveraendert bleiben. Die Folgerung, die IIRC auch so im RfC steht ist also: kann man nicht die Eindeutigkeit gewaehrleisten, so darf man keine ID generieren. Evolution ist also eindeutig defekt. Aber das wussten wir ja schon.
Ich halte das für die allerbeste Lösung. Mit sowas soll sich der Provider rumschlagen.
Darf er aber nicht, falls die Mail schon mit einer MID daherkommt. Es ist schlimm genug, dass sich manche Provider erdreisten, den Sender / Envelope umzuschreiben.
Im Falle der ID ist das zwar kein Argument, aber generell halte ich es konzeptionell für schlau, daß _der_ Rechner an dem Mails rumfummelt, der als "eigentlicher" Mailserver 24/7 im Netz ist und nicht bloß mein "Mailcache" zuhause, der den Clients die Post abnimmt oder abholt.
s.o. Aber kannst du Evolution beibringen, keine IDs zu generieren? Nein. Kannst du Evolution beibringen korrekte IDs zu generieren? Vielleicht. s.o.: Teste das bitte mal mit deiner /etc/hosts. Du kannst ja nur eine Mail per PM an mich mailen und anschliessend die Aenderung wieder zuruecknehmen. BTW: ich generiere meine /etc/hosts beim online- bzw. offline gehen ;)
c) Wir finden uns mit der Welt ab, wie sie ist und beerdigen das Konzept eindeutiger IDs. Es wird sie definitiv nie wieder geben. Ist Scheiße, ist aber so, und alle Mail-verarbeitende Programme generieren längst interne Checksummen, statt die ID zu verwenden.
NAK!
Es gibt meines Wissens keine Software mehr, die die IDs wirklich auswertet. Mal abgesehen vom Threading der MUAs, wo mit einer Wahrscheinlichkeit von 1 zu x-Fantastillionen eine Mail schlimmstenfalls im falschen Thread landen könnte.
Hier im lokalen Mailinglisten Archiv suche ich nach Message-IDs. Und siehe http://groups.google.com dort gilt exakt das gleiche. Nur dass man bei Mailinglistenarchiven meist leider nicht nach den MIDs suchen kann.
Das passiert aber jetzt schon bei praktisch ALLEN Usern,
Das ist kein Grund es auch zu machen. Wenn du so argumentieren willst, wieso verwendest du dann nicht Windows mit IE und OE? Sondern Mac und Linux und Mozilla und ...? Dadurch, dass viele es (meist unwissentlich) faschl machen, wird es nicht richtiger. -dnh -- "Remember, not all spammers are annoying..... Some are dead!" -- Rob Adams
Hallo Ratti, hallo Leute, Am Mittwoch, 1. September 2004 20:36 schrieb Ratti: [eindeutige Message-IDs]
Es gibt meines Wissens keine Software mehr, die die IDs wirklich auswertet.
Und was ist mit grepmail -u ? Aus man grepmail: -u Output only unique emails, by analogy to sort -u. Grepmail determines email uniqueness by the Message-ID header. Sprich: Doppelte Id -> Datenverlust... (Nein, ich finde grepmail in diesem Punkt nicht optimal.) Außerdem: gab/gibt es nicht Mailserver, die anhand der Message-Id (Schein-)Duplikate wegwerfen? IIRC hab ich mal was in der Richtung gehört, kann mich aber auch täuschen. Gruß Christian Boltz -- 3.-5.9.2004: Hoffest der Landjugend Insheim www.landjugend-insheim.de
Moin, Am Freitag, den 03.09.2004, 00:51 +0200 schrieb Christian Boltz:
Hallo Ratti, hallo Leute,
Am Mittwoch, 1. September 2004 20:36 schrieb Ratti: [eindeutige Message-IDs]
Es gibt meines Wissens keine Software mehr, die die IDs wirklich auswertet.
Und was ist mit grepmail -u ?
Aus man grepmail: -u Output only unique emails, by analogy to sort -u. Grepmail determines email uniqueness by the Message-ID header.
Sprich: Doppelte Id -> Datenverlust... (Nein, ich finde grepmail in diesem Punkt nicht optimal.)
Fehler "by design": Wer heutzutage noch MessageIDs als "eindeutig" verwendet, sitzt auf einem dünnen Ast. :-)
Außerdem: gab/gibt es nicht Mailserver, die anhand der Message-Id (Schein-)Duplikate wegwerfen? IIRC hab ich mal was in der Richtung gehört, kann mich aber auch täuschen.
Das wäre mir neu - und ehrlich gesagt, auch egal. Die Wahrscheinlichkeit, daß sich: Message-Id: <1093808348.5574.1.camel@ratti> wiederholt, ist so gering, daß ich mich vorher lieber um eine unterbrechnungsfreie Stromversorgung, einen Wachdienst vor der Haustür und einen Atombunker kümmern sollte, weil die Wahrscheinlichkeit eines Mailverlusts durch diese Ereignisse deutlich größer ist. Gruß, Ratti -- -o) fontlinge | Fontmanagement for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/
Hallo Ratti, Am Sonntag, 5. September 2004 09:09 schrieb Joerg Rossdeutscher:
Moin,
Am Freitag, den 03.09.2004, 00:51 +0200 schrieb Christian Boltz:
Hallo Ratti, hallo Leute,
Am Mittwoch, 1. September 2004 20:36 schrieb Ratti: [eindeutige Message-IDs] [...]
Darf ich das siggen?? -> Die
Wahrscheinlichkeit, daß sich: Message-Id: <1093808348.5574.1.camel@ratti> wiederholt, ist so gering, daß ich mich vorher lieber um eine unterbrechnungsfreie Stromversorgung, einen Wachdienst vor der Haustür und einen Atombunker kümmern sollte, weil die Wahrscheinlichkeit eines Mailverlusts durch diese Ereignisse deutlich größer ist.
ist goil Peter
Moin, Am Donnerstag, den 02.09.2004, 05:37 +0200 schrieb David Haller:
Am Wed, 01 Sep 2004, Joerg Rossdeutscher schrieb:
Am Mittwoch, den 01.09.2004, 01:37 +0200 schrieb David Haller:
Am Tue, 31 Aug 2004, Joerg Rossdeutscher schrieb:
Am Dienstag, den 31.08.2004, 05:43 +0200 schrieb David Haller:
Das ist nicht sinnvoll, das gesamte Netzwerk auf "gültige" Namen umzustellen, nur weil ein Programm konzeptionell falsch arbeitet. Die Domain "local." ist ja extra für Rendezvous/ZeroConf vergeben, und das ist auch sinnvoll.
Nicht umstellen. Nur ergaenzen.
127.0.0.1 ratti.local.gesindel.de localhost ratti.local ratti [..] Und alles, um Evolution eine ID beizubringen? Warum nicht gleich die glibc patchen? :-)))
Nein, wenn ich richtig vermute, was das camel_gethostbyname macht, dann reicht es _nur_ die /etc/hosts um den FQDN an erster Stelle nach der IP zu ergaenzen.
Nope. Wenn ich nur an evolution rumschraube, dann sehe ich das "sportlich", aber ich werde nicht an meiner /etc/hosts rumspielen und damit mein Netzwerk umkonfigurieren, um diese MessageID zu reparieren, die im praktischen Einsatz uneingeschränkt funktioniert.
Ausserdem finde ich "domains" wie .local einfach wiedersinnig, sofern man denn schon eine eigen domain hat, denn dann hat man die _hierarchische_ Struktur der Domains nicht verstanden.
Guck dir mal Rendezvous/ZeroConf an. Die Domain "local" ist nicht /irgendeine/ absichtlich "ungültige" Domain wie "zuhause.foo", sondern ein feststehender Identifier, den die Geräte verwenden, die das unterstützen. Und hierarchische Domains sind nicht in jedem Fall sinnvoll. Ich halte überhaupt nichts davon, rein interne Geräte mit Namen zu versehen, die nach "draussen" aussehen, aber gar nicht erreichbar sind. Warum sollte man sein internes Netzwerk auf das Internet ausrichten?
.. denn das verstoesst gegen die RfCs. Und ich weiss nicht, ob / wie man z.B. sendmail so konfiguriert. Moeglich ist es aber sicherlich. Wie's bei postfix und anderen MTAs aussieht weiss ich nicht.
Wo steht das? Meines Wissens ist es erlaubt, Mails ohne ID rauszugeben - Pflicht ist dann aber die Erzeugung einer solchen.
Ja. Aber man darf die ID nur erzeugen, wenn man die Eindeutigkeit im Sinne von (IIRC) RfC 2822 gewaehrleisten kann. Ansonsten _darf_ man keine ID generieren. Andererseits darf man IIRC keine bestehenden IDs aendern oder loeschen (weil es dann zu verschiedenen IDs unterwegs kommen kann). Das heisst im Klartext: die MID ist ein "write once" Header -- sobald vorhanden muss der Header unveraendert bleiben.
Die Folgerung, die IIRC auch so im RfC steht ist also: kann man nicht die Eindeutigkeit gewaehrleisten, so darf man keine ID generieren.
Dann wäre das rauslöschen in Ordnung, da es in Konsequenz wieder Eindeutigkeit generiert. Ich würde es aber trotzdem nicht machen, weil mein MUA davon nichts erfährt und die Mail im Ausgangsordner mit einer anderen ID liegt als beim Rücksenden aus der Liste.
s.o. Aber kannst du Evolution beibringen, keine IDs zu generieren? Nein. Kannst du Evolution beibringen korrekte IDs zu generieren? Vielleicht. s.o.: Teste das bitte mal mit deiner /etc/hosts. Du kannst ja nur eine Mail per PM an mich mailen und anschliessend die Aenderung wieder zuruecknehmen.
BTW: ich generiere meine /etc/hosts beim online- bzw. offline gehen ;)
Mein Rechner glaubt, er sei "always online", weil er hinter einem Router-Rechner steht, der das bei Bedarf tut. Flatrate. :-)
Es gibt meines Wissens keine Software mehr, die die IDs wirklich auswertet. Mal abgesehen vom Threading der MUAs, wo mit einer Wahrscheinlichkeit von 1 zu x-Fantastillionen eine Mail schlimmstenfalls im falschen Thread landen könnte.
Hier im lokalen Mailinglisten Archiv suche ich nach Message-IDs. Und siehe http://groups.google.com dort gilt exakt das gleiche.
Und du wirst wahrscheinlich auch dort keine zwei gleichen IDs finden, kannst das also ruhig tun. Die allerschlimmste Katastrophe wäre, daß du zwei verschiedene Fundstellen hast. Aber mit welcher astronomischen Wahrscheinlichkeit...
Das passiert aber jetzt schon bei praktisch ALLEN Usern,
Das ist kein Grund es auch zu machen. Wenn du so argumentieren willst, wieso verwendest du dann nicht Windows mit IE und OE? Sondern Mac und Linux und Mozilla und ...?
Dadurch, dass viele es (meist unwissentlich) faschl machen, wird es nicht richtiger.
Es gibt immer eine Grenze. Beispiel: Ich bemühe mich auf einer Website, daß alle halbwegs aktuellen Systeme draufkommen. Ich bemühe mich, daß ganze auch blindenlesbar zu halten. Ich werde aber weder auf JavaScript verzichten noch auf CSS, und ich werde nicht die borken Netscapes <=4.8 unterstützen, und ich werde auch keine Rücksicht nehmen auf Surfer mit weniger als 256 Farben im Display, und lynx interessiert mich nur soweit, wie es in der Blindenlesbarkeit mit abgefeiert werden kann. Weil alles andere einfach vorbei, vorbei, tot, aus, weg ist. Diese Art Technik ist einfach egal geworden. Das mag man bedauern. Manchmal sind es gerade die besten Dinge, die wegbrechen. Aber die Rückkehr dieser Technologien ist ebenso wahrscheinlich wie eine Renaissance des Mittelhochdeutschen - sprich: Null. Zuerst verwenden es noch 0,5% der Leute, dann kommt irgendwann eine Fernsehsendung über den letzten Kerl, der das noch sprichst. Danach nur noch Audioaufzeichnungen im Museum. Und irgendwann weiss man nicht mehr, wie es klang - zum Beispiel Babylonisch. Ab einer bestimmten Sinngrenze kippe ich eine Technologie in die Tonne. Und die ist bei weltweit eindeutigen MIDs überschritten. Das war übrigens nicht meine Entscheidung, sondern die der Welt. :-) Gruß, Ratti -- -o) fontlinge | Fontmanagement for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/
David Haller
Das Thema Message-ID ist komplexer. U.a. weiger(te?)n sich die Evolution-Programmierer, die RfCs korrekt zu implementieren.
Wichtig ist nicht, _dass_ ein MUA[1] eine ID generiert, denn das wuerde unterwegs der erste SMTP-Server, der eine gueltige ID generieren kann, uebernehmen.
Dann steht die ID aber nicht im 'Sent'-Folder. Das heißt, es ist lokal kein richtiges Threading möglich, und wenn die E-Mail noch einmal versendet wird, bekommt sie eine neue ID. Beides ist nicht wünschenswert, und ein MUA-Programmierer sollte es im Interesse seiner User wie der Empfänger wenn möglich vermeiden und IDs im Client generieren.
Wichtig ist, dass die ID _EINDEUTIG_ ist! [2]
Und das ist nur gewaehrleistet, wenn man die Kontrolle ueber den verwendeten Namensraum, i.d.R. den "domain-part" (dem hinter dem '@') hat.
Nein, das ist auch dann nicht absolut gewährleistet, u. a. weil es keinen Standard gibt, der per Programm eindeutige Namespaces für local-Parts generiert. Es kann deshalb prinzipiell durchaus vorkommen, dass z. B. nach einem Wechsel von Server-Admin und Server-Software auch SMTP-Server IDs zum zweiten Mal generieren. Oder glaubst Du im Ernst, jeder MTA würde überprüfen, was auf derselben Domain vor 20 Jahren von ganz anderer Software für Message-IDs generiert wurden? Debatten, ob es nun standardkonform ist, Kollisionen von Message-IDs mit statistischen oder Namespace-Methoden unwahrscheinlich zu machen, sind deshalb bestenfalls von akademischem Wert. Gunnar -- http://omnibus.ruf.uni-freiburg.de/~gritter
participants (7)
-
Christian Boltz -
David Haller -
Gunnar Ritter -
Helga Fischer -
Joerg Rossdeutscher -
Peter Baumgartner -
Sven Rodenbeck