Mail Content-Transfer-Encoding
Hallo Liste, ich benötig mal ein wenig Hilfe bzgl. mail. Ich bin gerade dabei eine Programm zum einfügen von disclaimern zu schreiben. Wie altermime, nur wesentlich umfangreicher. Abhängig vo is_multipart und get_content_typ füge ich den disclaimer wie folget ein --> text = part.get_payload() new_text = text + txt_disclaimer part.set_payload(text) --< So weit so gut. Das funktioniert auch. Solange in der Mail der Tag Content-Transfer-Encoding nicht vorhanden oder 7bit ist. Wenn 'Content-Transfer-Encoding: base64' ist geht es nicht mehr. Dann ist ein teil der mail als base64 codiert und der disclaimer ist normaler text. Klar, kann auch nicht gehen. Also habe ich den diclaimer auch in base64 umgewandelt --> text = part.get_payload() txt_disclaimer_text_base64 = base64.encodestring(disclaimer_text) new_text = text + txt_disclaimer_base64 part.set_payload(text) --< Soweit meine Logik. Das klappt aber nicht wirklich gut. Eine so erstellt Mail zeigt Thinderbird richtig an, KMail zeigt den disclaimer nicht an. Nur die Originalmail. Ich nehme jetzt mal an, dass base64 ein 'endkennzeichen' hat und diese von Kmail ausgewertet wird und der Rest dann ignoriert wird. Wie kann ich das lösen? Wie verhält es sich mit quoted-printable und 8bit? Bin über jeden Tip dankbar. Danke schon mal im vorraus. -- cu Roland M. Kruggel System: Intel, Debian etch, 2.6.16.16, xfce4 KDE 3.5
Hi Roland, Am 17.08.2007 um 12:40 schrieb Roland M. Kruggel:
Ich bin gerade dabei eine Programm zum einfügen von disclaimern zu schreiben. Wie altermime, nur wesentlich umfangreicher.
hilft Dir vielleicht mein MailSigger weiter? <http:// www.karstenschulz.name/assets/de/mailsigger/mailsigger.html> Gruß Karsten
Am Freitag, 17. August 2007 13:51 schrieb Schulz Karsten:
Hi Roland,
Am 17.08.2007 um 12:40 schrieb Roland M. Kruggel:
Ich bin gerade dabei eine Programm zum einfügen von disclaimern zu schreiben. Wie altermime, nur wesentlich umfangreicher.
hilft Dir vielleicht mein MailSigger weiter? <http:// www.karstenschulz.name/assets/de/mailsigger/mailsigger.html>
Ich suche keine Alternative zu meinem Proogemmierproject sonder eine Lösung für mein Problem. Mailsigger leistet nicht im entferntesten das was mein programm leistet. Mailsigger ist nicht viel mehr wie altermime. -- cu Roland M. Kruggel System: Intel, Debian etch, 2.6.16.16, xfce4 KDE 3.5
hilft Dir vielleicht mein MailSigger weiter? <http:// www.karstenschulz.name/assets/de/mailsigger/mailsigger.html>
Ich suche keine Alternative zu meinem Proogemmierproject sonder eine Lösung für mein Problem. Mailsigger leistet nicht im entferntesten das was mein programm leistet. Mailsigger ist nicht viel mehr wie altermime.
Ich glaube nicht, dass Karsten meinte, Du sollst sein Programm übernehmen. Vielmehr meinte er, dass Du es studieren solltest um zu sehen, wie er das Problem gelöst hat. Wenn Du das gemacht hättest, hättest Du wohl auch eine Lösung gefunden. Ciao, Martin
Am Freitag, 17. August 2007 16:57 schrieb Martin v. Löwis:
hilft Dir vielleicht mein MailSigger weiter? <http:// www.karstenschulz.name/assets/de/mailsigger/mailsigger.html>
Ich suche keine Alternative zu meinem Proogemmierproject sonder eine Lösung für mein Problem. Mailsigger leistet nicht im entferntesten das was mein programm leistet. Mailsigger ist nicht viel mehr wie altermime.
Ich glaube nicht, dass Karsten meinte, Du sollst sein Programm übernehmen. Vielmehr meinte er, dass Du es studieren solltest um zu sehen, wie er das Problem gelöst hat. Wenn Du das gemacht hättest, hättest Du wohl auch eine Lösung gefunden.
Oh weie. Das war wohl ein Missverständniss in beider Hinsicht. So wie es rübergekommen ist war es eigentlich gar nicht gemeint. Ein grosses Sorry. Besonders an Karsten. Natürlich habe ich das Programm mir geholt und angesehen. Solche Tips 'wie haben es andere geacht' sind oft mehr wert als 1000 Seiten Api-Doku. -- cu Roland M. Kruggel System: Intel, Debian etch, 2.6.16.16, xfce4 KDE 3.5
Roland M. Kruggel schrieb:
eine Lösung für mein Problem. Mailsigger leistet nicht im entferntesten das was mein programm leistet. Mailsigger ist nicht viel mehr wie altermime.
Was ich jetzt noch nicht verstanden habe: was leistet Dein Programm dann mehr als mailsigger? (Und: Warum schreibst Du ein komplett neues Programm, statt das von Karsten weiter zu entwickeln?) -- Schönen Gruß - Regards Hartmut Goebel Goebel Consult Spezialist für IT-Sicherheit in komplexen Umgebungen http://www.goebel-consult.de
Am Freitag, 17. August 2007 22:51 schrieb Hartmut Goebel:
Roland M. Kruggel schrieb:
eine Lösung für mein Problem. Mailsigger leistet nicht im entferntesten das was mein programm leistet. Mailsigger ist nicht viel mehr wie altermime.
Was ich jetzt noch nicht verstanden habe: was leistet Dein Programm dann mehr als mailsigger?
* globale signaturen Sie werden unter jeder Mail geschrieben * user Signaturen Sie werden, in Abhängigkeit von dem user, unter die Mail geschrieben * Text/Html Es gibt für jede Signatur (globale Signaturen und User Signaturen) sowohl eine Text-Signatur als auch eine Html-Signatur. Sie wird automatisch gesetzt. * Codierung/Multipart/Type Sowohl die Codierung der Mail (dank an Martin für die Aufklährung) als auch die Multiparts als auch die verschieden Typen (Text/Html) werden berücksichtigt. In einer Multipartmail wird die Text-Signatur in den text-Part eingefügt und die Html-Signatur in dem Html-part * Multidomain fähig Es können Signaturen für mehrere Senderdomains erstellt werden. Sowohl Domain-Abhängig als auch User-Abhängig. * gruppendefinitionen Verschieden Gruppen von Usern können verschiedene globale Signaturen haben * Empfänger Verschiedene Empfänger können bestimmte Signaturen zugeordnet werden. Wenn ich z.b. meiner Frau eine Mail schreibe, brauche ich nicht 10 Zeilen Signatur unter der mail, wenn ich einem Kunden eine Mail schreibe dann schon. * verifikation der user Nicht jeder User darf die Signatur unter seiner mail schreiben. Das ist hilfreich beim umstellen auf disclaim. Bei Installation des programmes haben die meisten user ja schon eine Signatur die ihr Mailclient mitschick. Da ist es sinnvoll diesen user erst zu aktiveren wenn er seine client-signatur abgeschaltet hat. So ist auch eine Umstellung von mehrere tausend Usern stressfrei möglich * security Es ist gewährleistet das die Mail auf jedenfall versand wird. Auch wenn das Programm mal abstürzen sollte. * so ein paar Kleinigkeiten Signaturtrenner ein- und ausschaltbar, Variabler abstand zwischen den Signaturen und Text bzw. zwischen Signatur und Signatur, logging, ... * hmm. auf die schnelle fällt mir nix mehr ein.
(Und: Warum schreibst Du ein komplett neues Programm, statt das von Karsten weiter zu entwickeln?)
Weil das Programm fast fertig ist und ich das Programm von Karsten erst heute kennen gelernt habe -- cu Roland M. Kruggel mailto:rk.liste@bbf7.de http:www.bbf7.de System: Intel, Debian etch, 2.6.21, xfce4, KDE 3.5
Hallo Roland, keine Frage, dass mein Programm nicht die Lösung für Dein erwähntes Problem ist. Es war nur ein Angebot, sich einen anderen Lösungsansatz anzusehen. Es ging dazu ja schon einiges auf der ML hin und her. Ich nutze konsequent die Möglichkeit mime/multipart zu nutzen, um den Inhalt des "parts" der originalen Mail nicht anfassen zu müssen (es sei denn, es ist sowieso alles nur reiner Text!). So ist sichergestellt, dass jeder Teil der Mail eindeutig dem jeweiligen Sender zugeordnet werden kann: Original-Part = Absender, zentrale Signatur = MailSigger. Du wirst bei Deiner Methode außerdem Probleme bekommen, wenn Deine Absender Ihre Mails signieren oder verschlüsseln, weil Du deren Inhalt änderst. Die Multipart-Sache funktioniert mit MailSigger und RFC-Konformen MUAs zufriedenstellend. Einzige Einflußmöglichkeit ist die Anzeigeoption für Anhänge, die je nach EInstellung inline, als Datei oder überhaupt nicht angezeigt werden. Das ist aber egal, da kein Schwein interessiert, was in so einem Anhang steht ;-) Es geht bei Mailsigger ja nur darum, den Inhalt zu senden, der von unserem Gesetzgeber gefordert wird. Am 18.08.2007 um 00:43 schrieb Roland M. Kruggel:
Am Freitag, 17. August 2007 22:51 schrieb Hartmut Goebel:
Roland M. Kruggel schrieb:
eine Lösung für mein Problem. Mailsigger leistet nicht im entferntesten das was mein programm leistet. Mailsigger ist nicht viel mehr wie altermime.
Was ich jetzt noch nicht verstanden habe: was leistet Dein Programm dann mehr als mailsigger?
* globale signaturen Sie werden unter jeder Mail geschrieben
check.
* user Signaturen Sie werden, in Abhängigkeit von dem user, unter die Mail geschrieben
check
* Text/Html Es gibt für jede Signatur (globale Signaturen und User Signaturen) sowohl eine Text-Signatur als auch eine Html-Signatur. Sie wird automatisch gesetzt.
überflüssig (siehe oben, Darstellung ist MUA Angelegenheit)
* Codierung/Multipart/Type Sowohl die Codierung der Mail (dank an Martin für die Aufklährung) als auch die Multiparts als auch die verschieden Typen (Text/Html) werden berücksichtigt. In einer Multipartmail wird die Text-Signatur in den text-Part eingefügt und die Html-Signatur in dem Html-part
schlecht bei signierten/verschlüsselten Inhalten.
* Multidomain fähig Es können Signaturen für mehrere Senderdomains erstellt werden. Sowohl Domain-Abhängig als auch User-Abhängig.
* gruppendefinitionen Verschieden Gruppen von Usern können verschiedene globale Signaturen haben
* Empfänger Verschiedene Empfänger können bestimmte Signaturen zugeordnet werden. Wenn ich z.b. meiner Frau eine Mail schreibe, brauche ich nicht 10 Zeilen Signatur unter der mail, wenn ich einem Kunden eine Mail schreibe dann schon.
* verifikation der user Nicht jeder User darf die Signatur unter seiner mail schreiben. Das ist hilfreich beim umstellen auf disclaim. Bei Installation des programmes haben die meisten user ja schon eine Signatur die ihr Mailclient mitschick. Da ist es sinnvoll diesen user erst zu aktiveren wenn er seine client-signatur abgeschaltet hat. So ist auch eine Umstellung von mehrere tausend Usern stressfrei möglich
diese Punkte sind in Mailsigger nicht realisiert und werden es wohl auch nie, da MailSigger einem anderen Einsatzzweck dient.
* security Es ist gewährleistet das die Mail auf jedenfall versand wird. Auch wenn das Programm mal abstürzen sollte.
das erledigt der MTA. Wobei mir gerade auffällt, dass ich vielleicht noch einen Signal-Handler einbauen sollte. Danke für das Brainstorming ;-) Gruß Karsten
Am Sonntag, 19. August 2007 17:52 schrieb Schulz Karsten:
Hallo Roland,
keine Frage, dass mein Programm nicht die Lösung für Dein erwähntes Problem ist. Es war nur ein Angebot, sich einen anderen Lösungsansatz anzusehen.
Ja, danke. Das habe ich auch gerne angenommen. Wie gesagt, ein guten beispiel ist immer viel Wert.
Es ging dazu ja schon einiges auf der ML hin und her.
Yup. Mit einigen interessanten anmerkungen für mich.
Ich nutze konsequent die Möglichkeit mime/multipart zu nutzen, um den Inhalt des "parts" der originalen Mail nicht anfassen zu müssen (es sei denn, es ist sowieso alles nur reiner Text!). So ist sichergestellt, dass jeder Teil der Mail eindeutig dem jeweiligen Sender zugeordnet werden kann: Original-Part = Absender, zentrale Signatur = MailSigger. Du wirst bei Deiner Methode außerdem Probleme bekommen, wenn Deine Absender Ihre Mails signieren oder verschlüsseln, weil Du deren Inhalt änderst.
Jo. Da sagst du was. Das wird dann nicht mehr funktionieren. Hmmm. Habe ich nicht bedacht. Danke für den Tip. Ich habe den Mailsigger mal komplett durchgetraced und habe da auch gesehen. Dazu gleich mal eine kleine Frage: Wenn einen Mail aus zwei Parts besteht (oder mehr), der eine Part ist text/plain und der ander Part ist text/html. Wie bekomme ich dann den Text-Disklaimer unter den text/plain part und den Html-Disclaaimer unter den text/html part? Das ist mir nicht so ganz klar. [...]
* Text/Html Es gibt für jede Signatur (globale Signaturen und User Signaturen) sowohl eine Text-Signatur als auch eine Html-Signatur. Sie wird automatisch gesetzt.
überflüssig (siehe oben, Darstellung ist MUA Angelegenheit)
Da muss ich dir widersprechen. Das ist sogar sehr wichtig. Viele User versenden Html-Mail, da muss natürlich ein 'schöner' html-Disclaimer drunter. Manche User versenden nur text-Mail, Dort also soll der Text-Disclaimer eingefügt werde und dann gibt es noch die User, es sind die meisten, die versenden Mails als Text und Html. Dort _muss_ unter dem Text-part der Text-Disclaimer und unter dem Html-Part der Html-Disclaimer.
* Codierung/Multipart/Type Sowohl die Codierung der Mail (dank an Martin für die Aufklährung) als auch die Multiparts als auch die verschieden Typen (Text/Html) werden berücksichtigt. In einer Multipartmail wird die Text-Signatur in den text-Part eingefügt und die Html-Signatur in dem Html-part
schlecht bei signierten/verschlüsselten Inhalten.
Ja, hast recht. Siehe oben. [...]
* security Es ist gewährleistet das die Mail auf jedenfall versand wird. Auch wenn das Programm mal abstürzen sollte.
das erledigt der MTA. Wobei mir gerade auffällt, dass ich vielleicht noch einen Signal-Handler einbauen sollte. Danke für das Brainstorming ;-)
Na, dann habe ich ja auch noch eine Idee beigetragen ;) -- cu Roland M. Kruggel mailto:rk.liste@bbf7.de http:www.bbf7.de System: Intel, Debian etch, 2.6.21, xfce4, KDE 3.5 ------------ Zufallszitat Äußerer gemäßigter Stolz gibt dem Verdienst einen größern Schein. -- Jean Paul
Hi Roland, Am Sonntag, 19. August 2007 19:59 schrieb Roland M. Kruggel:
Dazu gleich mal eine kleine Frage: Wenn einen Mail aus zwei Parts besteht (oder mehr), der eine Part ist text/plain und der ander Part ist text/html. Wie bekomme ich dann den Text-Disklaimer unter den text/plain part und den Html-Disclaaimer unter den text/html part? Das ist mir nicht so ganz klar.
im Groben etwa so (freihändig, beim ersten Kaffee): Content-Type: multipart/alternative --alternative-- Content-Type: multipart/mixed Content-Type: text/plain; Textmail Content-Type: text/plain; Textsignatur --alternative-- Content-Type: multipart/mixed Content-Type: text/html; HTML-Mail Content-Type: text/html; HTML-Signatur Das ganze kann aber beliebig komplexer werden, wenn im HTML-Teil Bildchen usw. gesendet werden (Content-Type: multipart/related) Schau Dir mal die Familie der MIME-RFCs an (RFC2045ff). Insbesondere RFC2049 gibt viele wertvolle Hinweise für die Behandling von MIME-Mails. Gruß Karsten -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
Wenn 'Content-Transfer-Encoding: base64' ist geht es nicht mehr. Dann ist ein teil der mail als base64 codiert und der disclaimer ist normaler text. Klar, kann auch nicht gehen. Also habe ich den diclaimer auch in base64 umgewandelt
Das ist (im Prinzip) eine Möglichkeit. Eine andere ist, den Disclaimer in einen eigenen Part zu speichern, und den Originalpart in einen multipart-Teil umzuwandeln. "Im Prinzip" deshalb, weil es so nicht funktioniert, wie Du ja herausbekommen hast. Du kannst nicht einfach base64-Fragmente zusammenhängen und erwarten, dass das Ergebnis wieder base64 ist.
Ich nehme jetzt mal an, dass base64 ein 'endkennzeichen' hat und diese von Kmail ausgewertet wird und der Rest dann ignoriert wird.
Die Annahme ist (im Prinzip) falsch. In base64 werden Bitfolgen in Gruppen von 6 bits zu einem Zeichen zusammengefasst; damit ist ein kodierter Text immer das Vielfache von 6 Bits. Da die Eingabe aber in 8-er Bitgruppen (bytes) daherkommt, kann es sein, dass es nicht aufgeht: wenn man 5 Bytes kodieren will (40 Bit), macht das 6 Zeichen, und man hat am Ende noch 4 Bits übrig. base64 legt jetzt fest, dass die Eingabe immer ein Vielfaches von 24 Bits sein muss und notfalls mit Nullbits aufgefüllt wird. Wieviele Nullbits das waren, wird am Ende durch das Zeichen = ausgedrückt: kein =: 0 padding bits, "=": 8 padding bits, "==": 16 padding bits. Ein base64-Dekoder kann also anhand der =-Zeichen erkennen, ob die Eingabe zuende ist - allerdings werden nicht bei jeder Eingabe auch =-Zeichen ausgegeben: py> e=base64.encodestring py> d=base64.decodestring py> d(e("Hallo")+e("Welt")) 'Hallo' py> d(e("Hallo ")+e("Welt")) 'Hallo Welt' Wenn der erste String eine Länge hat, die ein Vielfaches von 3 ist, dann wird der zweite String als dazugehörig betrachtet, ansonsten nicht. Kurz: Du musst erst den Part dekodieren, beide Teile verknüpfen, und dann den Part wieder kodieren. Wenn Du dabei bist, solltest Du das auch für die anderen Content-Transfer-Encodings machen.
Wie kann ich das lösen? Wie verhält es sich mit quoted-printable und 8bit?
Bei quoted-printable im Prinzip genauso. Bei 8bit kannst Du die Inhalte direkt verketten (vorausgesetzt, der Content-type erlaubt eine solche Verkettung). Außerdem musst Du Content-Length aktualisieren, falls das in dem Part gesetzt war. Schließlich musst Du den Disclaimer in den charset von dem Part konvertieren, in den Du ihn einfügen willst.
Bin über jeden Tip dankbar.
Das scheint mir nicht wirklich der Fall zu sein - so, wie Du auf den ersten Tip reagiert hast. Ciao, Martin
Am Freitag, 17. August 2007 16:51 schrieb Martin v. Löwis:
Wenn 'Content-Transfer-Encoding: base64' ist geht es nicht mehr. Dann ist ein teil der mail als base64 codiert und der disclaimer ist normaler text. Klar, kann auch nicht gehen. Also habe ich den diclaimer auch in base64 umgewandelt
Das ist (im Prinzip) eine Möglichkeit. Eine andere ist, den Disclaimer in einen eigenen Part zu speichern, und den Originalpart in einen multipart-Teil umzuwandeln.
"Im Prinzip" deshalb, weil es so nicht funktioniert, wie Du ja herausbekommen hast. Du kannst nicht einfach base64-Fragmente zusammenhängen und erwarten, dass das Ergebnis wieder base64 ist.
Ich nehme jetzt mal an, dass base64 ein 'endkennzeichen' hat und diese von Kmail ausgewertet wird und der Rest dann ignoriert wird.
Die Annahme ist (im Prinzip) falsch. In base64 werden Bitfolgen in Gruppen von 6 bits zu einem Zeichen zusammengefasst; damit ist ein kodierter Text immer das Vielfache von 6 Bits. Da die Eingabe aber in 8-er Bitgruppen (bytes) daherkommt, kann es sein, dass es nicht aufgeht: wenn man 5 Bytes kodieren will (40 Bit), macht das 6 Zeichen, und man hat am Ende noch 4 Bits übrig.
base64 legt jetzt fest, dass die Eingabe immer ein Vielfaches von 24 Bits sein muss und notfalls mit Nullbits aufgefüllt wird. Wieviele Nullbits das waren, wird am Ende durch das Zeichen = ausgedrückt: kein =: 0 padding bits, "=": 8 padding bits, "==": 16 padding bits.
Ein base64-Dekoder kann also anhand der =-Zeichen erkennen, ob die Eingabe zuende ist - allerdings werden nicht bei jeder Eingabe auch =-Zeichen ausgegeben:
py> e=base64.encodestring py> d=base64.decodestring py> d(e("Hallo")+e("Welt")) 'Hallo' py> d(e("Hallo ")+e("Welt")) 'Hallo Welt'
Wenn der erste String eine Länge hat, die ein Vielfaches von 3 ist, dann wird der zweite String als dazugehörig betrachtet, ansonsten nicht.
Kurz: Du musst erst den Part dekodieren, beide Teile verknüpfen, und dann den Part wieder kodieren.
Ok. so habe ich es nun auch gemacht. Geht super. Der kern sieht nun so aus: --> text = part.get_payload(decode = True) # wird autom. decodiert cte = part.get('content-transfer-encoding', '').lower() text = self.setTextPayload(text, txt_txt) if cte == 'base64': text = base64.encodestring(text) elif cte == 'quoted-printable': text = quopri.encodestring(text) part.set_payload(text) --<
Wenn Du dabei bist, solltest Du das auch für die anderen Content-Transfer-Encodings machen.
ok
Wie kann ich das lösen? Wie verhält es sich mit quoted-printable und 8bit?
Bei quoted-printable im Prinzip genauso. Bei 8bit kannst Du die Inhalte direkt verketten (vorausgesetzt, der Content-type erlaubt eine solche Verkettung).
Ok.
Außerdem musst Du Content-Length aktualisieren, falls das in dem Part gesetzt war.
Oh. Wieder was dazugelernt. Danke für den Tip. Reicht da ein lenght(text)?
Schließlich musst Du den Disclaimer in den charset von dem Part konvertieren, in den Du ihn einfügen willst.
Ok.
Bin über jeden Tip dankbar.
Das scheint mir nicht wirklich der Fall zu sein - so, wie Du auf den ersten Tip reagiert hast.
Jo. *schäm* Die Entschuldigung ist schon raus. Ok Martin. Super Beschreibung und Erklährung. Herzlichen Dank. Ich bin an dieses Project zu anfang etwas blauäugig herrangegangen. Habe aber schnell gemerkt: 'Sooo einfach ist es doch nicht'. Aber ich habe viel dabei gelernt. Nicht zuletzt von solchen wie dir. :) Danke nochmal. Natürlich auch an Martin. -- cu Roland Kruggel mailto: rk.liste at bbf7.de System: Intel, Debian etch, 2.6.16.16, xfce4 KDE 3.5 -- cu Roland M. Kruggel System: Intel, Debian etch, 2.6.16.16, xfce4 KDE 3.5
Außerdem musst Du Content-Length aktualisieren, falls das in dem Part gesetzt war.
Oh. Wieder was dazugelernt. Danke für den Tip. Reicht da ein lenght(text)?
Ich nehme das zurück - Content-length ist ein HTTP-Feature, keins von MIME (nichtsdestotrotz findet man es oft in Email). In MIME geht jeder part bis zur boundary. Ciao, Martin
Am Freitag, 17. August 2007 17:44 schrieb Roland M. Kruggel:
Am Freitag, 17. August 2007 16:51 schrieb Martin v. Löwis:
Bin über jeden Tip dankbar.
Das scheint mir nicht wirklich der Fall zu sein - so, wie Du auf den ersten Tip reagiert hast.
Jo. *schäm* Die Entschuldigung ist schon raus.
So, nachdem die Etiquette einigermaßen wiederhergestellt ist, hier nochmal für alle eine Abhandlung zu Sinn und Unsinn von Disclaimern (was 'n deutsch, hrmpf): http://www.goldmark.org/jeff/stupid-disclaimers/ Vorsicht für Blasenschwache und Herzkranke, ich jedenfalls hatte am nächsten Tag Zwerchfellmuskelkater. Pete
Am Freitag, 17. August 2007 22:18 schrieb Hans-Peter Jansen:
Am Freitag, 17. August 2007 17:44 schrieb Roland M. Kruggel:
Am Freitag, 17. August 2007 16:51 schrieb Martin v. Löwis:
Bin über jeden Tip dankbar.
Das scheint mir nicht wirklich der Fall zu sein - so, wie Du auf den ersten Tip reagiert hast.
Jo. *schäm* Die Entschuldigung ist schon raus.
So, nachdem die Etiquette einigermaßen wiederhergestellt ist, hier nochmal für alle eine Abhandlung zu Sinn und Unsinn von Disclaimern (was 'n deutsch, hrmpf):
http://www.goldmark.org/jeff/stupid-disclaimers/
Vorsicht für Blasenschwache und Herzkranke, ich jedenfalls hatte am nächsten Tag Zwerchfellmuskelkater.
Hier sind die Lustigen: http://www.goldmark.org/jeff/stupid-disclaimers/fun.html
Hans-Peter Jansen schrieb:
So, nachdem die Etiquette einigermaßen wiederhergestellt ist, hier nochmal für alle eine Abhandlung zu Sinn und Unsinn von Disclaimern (was 'n deutsch, hrmpf):
Zu Pflichtangaben auf Geschäftsbriefen nach deutschem Recht siehe z.B. <http://www.hk24.de/produktmarken/recht_und_fair_play/allgemeine_rechtsauskuenfte/recht_der_unternehmensgruendung/pflichtangaben_briefe.jsp> Man könnte also auch sinnvolle Anwendungen für mailsigger und Rolands Tool finden. :-) -- Schönen Gruß - Regards Hartmut Goebel Goebel Consult Spezialist für IT-Sicherheit in komplexen Umgebungen http://www.goebel-consult.de
So, nachdem die Etiquette einigermaßen wiederhergestellt ist, hier nochmal für alle eine Abhandlung zu Sinn und Unsinn von Disclaimern (was 'n deutsch, hrmpf):
Ja, klar. Wenn ich meiner Frau eine Mail schreibe reicht als 'disclaimer' ein einfacher 'roland' oder so. Wenn ich aber einem Kunden eine Mail schreibe sollte, nein muss, da schon ein bisschen mehr drunter stehen. Gewisse Teile sind bei solchen Geschäftsmails Pflicht und müssen immer erscheinnen. Das jeder User seinen eigenen Namen, Position, Durchwahl, Faxnummer, Abteilung etc. noch unter der Mail haben sollte ist doch auch ersichtlich. Wir reden hier auch nicht über einen der zwei Familienmitglieder die Mails versenden sonder von Firmen mir mehreren Hunder/Tausend Mailusern. Die Firmen wollen nach aussen hin ein einheitliches und Rechtssicheres Auftreten haben. Also, disclaimer sind schon wichtig. Ausserdem ist ein nettes Zufallszitat unter einer Mail auch ganz schön. Allerdings nicht in Geschäftsbriefen. (Nur an Herbert von Firma xyz.de, Weil ich den persönlich kenne) So was muss abbildbar sein. -- cu Roland M. Kruggel mailto:rk.liste@bbf7.de http:www.bbf7.de System: Intel, Debian etch, 2.6.21, xfce4, KDE 3.5
participants (6)
-
"Martin v. Löwis" -
Hans-Peter Jansen -
Hartmut Goebel -
Karsten Schulz -
Roland M. Kruggel -
Schulz Karsten