FKN-Systems
EDV, Netzwerk und Internet Services
0531 - 28 50 90 40
Abschnitt: Kurznavigation, wechseln zu: [1] Kurznavigation, [2] MiniNav, [3] Inhalt, [4] Fusszeile, [5] Vollnavigation, [m] Weiterblättern, [n] Zurückblättern
![[kontakt]](_db/FKN-Systems/_pic/icon_mail_blue.gif){kind=icon}
![[information]](_db/FKN-Systems/_pic/icon_info.gif){kind=icon}
Abschnitt: Inhalt
FKN-Nettikette
Goldene Regeln für den Email-Verkehr
- Du sollst einen aussagekräftigen Betreff verwenden [mehr]
- Du sollst eine Webadresse immer ausschreiben [mehr]
- Du sollst nicht unüberlegt an alle schreiben [mehr]
- Du sollst keinen TOFU machen [mehr]
- Du sollst nicht unötig zitieren [mehr]
- Du sollst auf korrekte Rechtschreibung achten [mehr]
- Du sollst nicht unbearbeitet Dateianhänge versenden [mehr]
- Du sollst keine Word-Dokumente (DOC) versenden [mehr]
Beschreibung
Dieses Dokument beschreibt die wichtigsten Regeln, auf die es bei der Email- und News-Kommunikation ankommt. Sie sind als Regelsatz gedacht, nach denen man sich nach Möglichkeit richten sollte, um anderen aber auch sich selbst den Umgang mit Nachrichten möglichst komfortabel zu gestalten. Man verfährt also nach der Regel: Was mir nicht angetan werden soll, tue ich auch keinem anderen an!Das gesamte Dokument hat folgenden Aufbau: On Top stehen die wichtigsten Regeln, wobei "mehr..." auf den vollständigen Text führt. Darunter stehen weitere Regeln nach Kategorien geordnet. Über das Inhaltsverzeichnis können die einzelnen Beiträge direkt angesprungen werden. Sicher ist nicht alles für jeden interessant und relevant. Der Vollständigkeit halber enthält das Dokument aber alle Umgangsregeln für Email- und News-Kommunikation.
Dieses Dokument befindet sich in ständiger Bearbeitung, die jeweils aktuellste Version ist unter [download] oder auf http://www.fkn-systems.de/_nettikette zu bekommen. Kommentare und Anregungen für Erweiterungen können jederzeit an untestehende Adresse geschickt werden, sie sind Herzlich willkommen!
!! Leerzeichen werden in diesem Text mit einem Unterstrich ,,_'' gekennzeichnet.
!! Wer sich berufen fühlt, an diesem Text mitzuarbeiten oder Fragen dazu hat, kann diese unter [kontakt] loswerden.
Dieser Text kann nach den Bestimmungen der GPL_2.0 verbreitet werden: [download]
$VER: FKN-Systems_Nettikette 0.7.45.5 (20120328140352) (20010316) FKN-Systems/Ng $ FKN-Systems / [kontakt]
$VER: FKN-Systems_Nettikette 0.7.45.5 (20120328140352) (20010316) FKN-Systems/Ng $ FKN-Systems / [kontakt]
Inhaltsverzeichnis
Kopfzeilen (Header)Gute Subjects (Betreffzeilen)
Thread entspricht Thema
Der Reply-Prefix
Kennzeichnung bei Mail-Forwarding
Adressierung
Antwort-Adresse
Schreibweise von URL's
Broadcasting (Mail an Alle)
Crosspostings und Kopien
Crossposting und Spamming
Test-Nachrichten
Wichtigkeit der Nachricht
Typ der Newsgroup
Zitieren (Quoting)
Copyright und Sensibilität
Signaturen
Editieren
Korrekte Vorgehensweise beim Zitieren
Quoting-Prefix
TOFU und deren Unterformen
Signaturen (Signatures)
Prägnanz
Die Unterschrift
Größe der Signatur
Layout
Zeilenumbruch
Umlaute (nur fremdsprachige Newsgroups oder Mailpartner)
Leerraum
Sprache
Anrede
Persoenliche Ansprache
Englisch/Deutsch
Großbuchstaben
Emoticons
Layout und Rechtschreibung
Verschiedenes
Erst lesen, dann schreiben
Aufforderungen zu illegalen Dingen
Präzise Fragen
Flame-Wars
Kill-File und Mail-Filter
Transferzeiten
Volltext-Archivierung
Usenet-Slang
Dateianhänge
Emfangsbestätigung und Priorität
Hoax der Pseudo-Virus
Dateitypen
Warum PDF, wann Text, warum nicht DOC
Allgemeines zur Email
GnuPG/PGP, EMail Verschlüsseln und Signieren
Kopfzeilen (Header)
Gute Subjects (Betreffzeilen)
| Immer darauf achten, kurze und aussagekräftige Subjects zu nutzen. Denn viele Leser entscheiden alleine aufgrund des Subjects, ob der Artikel lesenswert ist oder nicht. Ausser dem Oberbegriff sollten ggf. auch Typenbezeichnungen genannt werden. Darüber hinaus können Emails bzgl. Projekt oder Kunde in Unterordner gruppiert werden und dokumentieren so z.B. den Verlauf eines Vorgangs. Aussagekräftige Betreffs helfen beim Archivieren und Wiederfinden. Dazu kann z.B. auch ein aussagekräftiges Prefixing gehören: z.B. vorangestelltes TODO:_, INFO:_, ADMIN:_, PROJECT:_, ORDER:_, ... Häufig gebraucht in Newsgroups: S: (Suche), B: (Biete), V: (Verkaufe), T: (Tausche). |
Falsch:
| Subjects der Form ,,Help me!'' oder mehrere Emails mit gleichem Betreff, oder gar keinen Betreff anzugeben. |
Richtig:
|
Thread entspricht Thema
| Ein Thread ist die Beziehung mehrerer Mails, die von den Mailprogrammen meist als Baumstruktur dargestellt wird. Bei Themenwechsel innerhalb eines Threads (auch bei Mail) NICHT auf die original Nachricht antworteten, stattdessen die Funktion 'neue Nachricht' aufrufen und dort das alte Subject u.U. mit ,,_(was: ...)'' an das neue anhängen und somit einen neuen Thread erzeugen. |
Falsch:
| Themenwechsel innerhalb des alten Threads ohne Kennzeichnung |
Richtig:
|
Der Reply-Prefix
| Ein Reply jeglicher Art wird im Subject immer und ausschließlich mit nur einem ,,Re:_'' eingeleitet. |
Falsch:
| ,,Re:'' statt ,,Re:_'', ,,AW'' oder ähnliches statt ,,Re'', oder gar ,,AW: AW: AW: AW: ...'' statt einem einzigen Prefix. |
Richtig:
| Bettreffzeile (Subject) lautet z.B.: 'Re: Silvesterparty' |
Kennzeichnung bei Mail-Forwarding
| Weitergeleitete (forwarded) Mails werden im Subject mit ,,_(fwd)'' am Ende oder alternativ mit ,,Fwd:_'' oder ,,[FWD]_'' am Anfang gekennzeichnet. Falls eigener Kommentar im Text hinzugefügt wird, muß der Originaltext gequotet werden. |
Falsch:
| Weglassen der Kennzeichnung ,,Fwd:_'', wodurch die Weiterleitung nicht Erkennbar ist. |
Adressierung
Antwort-Adresse
| Auf korrekte Adressierung der Antwort-Artikel achten, indem man korrekte ,,Reply-To:'' Header setzt und zusätzlich bei News einen ,,Followup-To:'' Header. |
Falsch:
| Fehlende Header, wodurch die Antworten bei Mail (durch Gateways) aufgrund falsch konvertierter ,,From:'' Header nicht ankommen (Bouncing) und bei News die Antworten auf alle Newsgroups (Crossposting) verteilt sind. |
Schreibweise von URL's
| URL's (Web- oder Emailadressen) sind immer in der Form 'http://meine.do.main' oder 'mailto:name@do.main' anzugeben. Dadurch wird a) die Erkennung von URL's im Text erleichtert. b) werden sie auch in der Text-Version in vielen Browsern 'klickbar'. |
Falsch:
| Durch falsche Screibweise von URL's muß der Empfänger erst umständlich damit hantieren. |
Broadcasting (Mail an Alle)
| Beim Broadcasting (Versenden von Mail 'An Alle') sollte auf eine "intelligente" Adressierung geachtet werden. So sollten bei existierenden Verteilern (z.B. mailto:alle@irgendwas.do.main) darauf geachtet werden, dass nicht auch noch alle Adresssaten des Verteilers (mailto: |
Falsch:
| Durch falsches Adressieren wird mehr Datenmüll produziert und die Empfänger werden mit Duplikaten überhäuft. |
Crosspostings und Kopien
| Wenn man Artikel an mehrere Adressen (Mail) oder Newsgroups (News) verschicken will, so sollte man darauf achten, statt jeweils einer Kopie der Nachricht pro Ziel, nur eine einzige Kopie an alle Ziele zu versenden. Bei Mail bedeutet dies, im ,,BSS:_'' Header alle Adressen mit Komma getrennt anzugeben, anstatt die Mail mehrmals zu versenden. Auf die Verwendung der ,,TO:_'', ,,CC:_'' Header sollte man hier verzichten, da sonst jeder (!)alle Adressen sehen kann, und dies ausserdem unötigen Traffik erzeugt. Durch verwenden des Header ,,BCC:_'' erhält jeder Adressat eine BlindCarbonCopy, also einen 'Blinden Durchschlag'; damit kann er nur seine eigene Adresse sehen, was sowohl der Übersichtlichkeit hilft sowie Adresssammlern vorbeugt. Bei den viel benutzten ,,TO/CC:_'' kann dagegen jeder alle Adressen sehen, was idR. nicht erwünscht ist. Und falls die Möglichkeit einer Mailing-Liste besteht, noch besser: statt dieser Adressaten-Liste die Adresse der Mailing-Liste nutzen. Bei News bedeutet dies, statt den Artikel jeweils neu in verschiedene Newsgroups zu posten, die Newsgroups alle mit Komma getrennt im ,,Newsgroups:_'' Header anzugeben und somit ein Crossposting zu erstellen. |
Falsch:
Versenden von vielen Einzelnachrichten, bzw. versenden von TO/CC üsten. |
Richtig:
| Mehrere Empfänger in einer Mail zusammenfassen: Mit BCC: für Rundschreiben bei denen nur der Empfang wichtig ist, und nicht wer noch alles einen Durchschlag erhält. Mit CC: z.B: für Schreiben an Verwaltung und Arbeitnehmner, wo ein Durchschlag (CC  an den Chef geht, damit der Empfänger weiss; dies hat jetzt auch mein Chef bekommen. |
Crossposting und Spamming
| Bei News generell zu ,,breite'' Crosspostings vermeiden. Stattdessen lieber die Newsgroup-Liste auf wenige (2-4) Newsgroups reduzieren. |
Falsch:
| Zuviele Newsgroups, weil man denkt, dies würde den Verbreitungsgrad erhöhen und zu mehr Antworten führen. |
Test-Nachrichten
| Test-Nachrichten nur in dafür vorgesehene Test-Newsgroups posten. Diese tragen i.d.R. das Wort ,,test'' in ihrem Namen. |
Falsch:
| Posten einer ,,Please ignore'' Nachricht. |
Wichtigkeit der Nachricht
| Weniger wichtige Nachrichten niemals an ganze Container-Mailing-Listen (solche, die automatisch Personenkreise zusammenfassen, d.h. die Personen haben sich nicht explizit bzw. persönlich dort eintragen haben lassen) versenden oder gar weltweit in eine Newsgroup posten. Außerdem nie zeitbedingte oder ausschließlich lokale Nachrichten in weltweite Newsgroups posten. Denn die News werden weltweit verbreitet und brauchen dazu zwischen ein und vier Tagen. |
Falsch:
| Posten eines kurzfristigen Veranstaltungtermins oder die Info des lokalen Kegelklubs in den News oder "Suche Naturposter" an ,,SDM@sdm.de'', etc. |
Typ der Newsgroup
| Manche Newsgroups sind moderiert! Manche nur fuer Announcements (,,*.announce''), andere nur fuer Diskussionen (,,*.d'') und manche nur für ganz spezielle Themen. Man sollte sich vorher die Charta oder andere Informationen der Newsgroup durchlesen, bevor man postet. |
Falsch:
| Announcements in dedizierten Diskussionsforen |
Zitieren (Quoting)
Copyright und Sensibilität
| Niemals eine Mail (in einer anderen Mail) an einen dritten oder gar in den News zitieren, auch nicht auszugsweise. Dies ist nur mit vorheriger persönlicher Rücksprache mit dem Original-Autor möglich. |
Falsch:
| Abdrucken von persönlicher Mail in einem News-Posting |
Signaturen
| Niemals die Signatur eines Autors im Antwort-Artikel quoten. Denn der Autor kennt seine Signatur auswendig, manchmal (bei echten Hackern) sogar bis auf die exakte Bytegröße genau. Die eigene Signatur gequotet ist ärgerlich und verursacht zusätzlichen Datenmüll. In den meisten Mailprogramen kann eingestellt werden, dass grundsätzlich Antworten ohne Quoting geöffnet werden; idR. kann dann über eine Tastenkombination oder das Menu das Quoting - sollte es nötig sein - veranlasst werden. |
Falsch:
| Reply mit gequoteter Signature |
Editieren
| Nur das Wesentliche zitieren, d.h. alles löschen, bis auf die Stellen, die der Empfänger unbedingt benötigt, um den Zusammenhang zu erkennen. Denn der Empfänger hat nicht nur einen Thread, den er verfolgen muß, sondern viele. Er kann sich also weder alle Diskussionsstände merken, noch möchte er alle Diskussionsbeiträge jedesmal gequotet bekommen. Man sollte also ausreichend Zeit investieren, um die Nachricht so verständlich wie möglich aufzubauen. Manche News-Systeme und -Reader (z.B. INN) können sogar so konfiguriert werden, dass sie solche Artikel abweisen. Denn zuviel Zitate werden immer als störend empfunden. Es ist außerdem guter Stil, die gelöschten Textpassagen durch ,,>_[...]'' Zeilen zu markieren. Häufigste Erscheinungsform solcher falsch gequotete Mails heissen dann auch TOFU (Text Oben Fullquoting Unten). Siehe auch: TOFU |
Falsch:
| Versenden von Replies, wo prozentual mehr zitierter Text drin steht, als neuer Text |
Korrekte Vorgehensweise beim Zitieren
| Korrekt zitiert man wie folgt: 1. Man quotet den gesamten Original-Text (wird meist durch das Mailprogramm automatisch getan). 2. Man beginnt am Anfang mit dem Lesen. 3. Wenn man auf einen Absatz nicht antworten will, wird er gelöscht und durch ,,>_[...]'' ersetzt. Wenn man auf einen Absatz antworten will, überspringt man den gequoteten Absatz, fügt danach den Antwort-Absatz ein und sorgt dafür, dass sowohl vor als auch nach diesem neuen Antwort-Absatz eine Leerzeile ist. |
Falsch:
| Antwort komplett am Anfang, danach gesamter Original-Text gequotet. Antwort-Absatz direkt (ohne Leerzeile) nach dem gequoteten Original-Absatz oder gar (bei Exchange-Usern) Antwort-Absatz direkt nach dem Original-Absatz mit der Ersten Zeile beginnend mit ,,>...''. |
Richtig:
| z.B.: > ... > ausserdem haben wir schönes Wetter! NACK! Es schüttet doch aus Eimern... |
Quoting-Prefix
| Als Quoting-Prefix gilt per Konvention ,,>_''. Viele Mail- und News-Reader erkennen dies sogar automatisch (für Statistik oder farbiges Markieren, etc.) |
Falsch:
| Nutzung von Nicht-Standard Prefix, wie z.B. ,,%'' |
TOFU und deren Unterformen
| Als TOFO bezeichnet man Quotings (Antworten auf eine Mail) bei denen das Format 'Text Oben, Fullquote Unten' Verwendung findet. Es handelt sich dabei i.d.R. um ein Fullquote, also ein Vollzitat, bei dem der Text (also die Antwort) oben steht und die gesamte Nachricht darunter zitiert wird; Hier kann man sich leicht vorstellen, dass sich diese Nachricht nur noch von unten nach oben richtig (verständlich) lesen lassen würde. Unterformen des TOFU sind beispielsweise das Fullquote bei dem die ganze originäre Mail (meist sogar mit Signaturen und/oder Header) zitiert (also wieder) versendet wird. Beim ungekürtzten Sinnquote ist die Verzahnung von Zitat und Antwort (aus denen sich ja der Pseudodialog für den uneingeweiten Leser ergibt) im Prinzip richtig, nur ist das Zitat nicht wirklich bzw. nur unwesentlich eingekürzt. Beim Nullquote dagegen fehlt jeder Zusammenhang völlig, da hier der Schreiber gar nicht erst zitiert sondern nur (s)eine Antwort schreibt; fehlt also die Ursprungsmail (da sie nicht empfangen wurde, verloren ging, oder sich dank fehlerhaften Thread irgendwo im Mailordner herumtreibt) ist die Antwort ebendso unverständlich wie auf Klatchianisch geschrieben. Von einem Kammzitat spricht man dann, wenn durch die Einrückungszeichen (Quotings-Prefix) ,,>_'', der Text soweit erweitert wurde das er über den Zeilenumbruch (bei ca. 75 Zeichen) hinausgedrückt und zum Umbruch gezwungen wird. Dadurch entsteht eine neue Zeile mit dem Rest der vorhergegangenen welche nicht mehr gequotet ist. Für den Leser ergibt sich der Eindruck das dies vom Schreiber (Antworter) stammen, was dann aber alles nicht wirklich zusammenpasst. Als Antwort darauf gilt das zusammengefasste Zitat (also ein wirkliches Zitat im sprichwörtlichen Sinne) als anzustrebende Lösung, zeigt sie doch das was der Schreiber (Antworter) verstanden hat und stellt somit auch seine Antwort verständlich dar. |
Falsch:
| Einfach drauflos antworten ohne die ziterten Stellen sinnvoll z.B. durch ,,>_[...]'' einzukürzen oder sinnlich zusammzufassen. |
Signaturen (Signatures)
Prägnanz
| Die Signatur sollte nach Möglichkeit den Autor vollständig identifizieren, um einerseits Verwechslungen auszuschließen und andererseits die Kontaktaufnahme zu erleichtern. Aber sie sollte keine Information beinhalten, die entweder irrelevant oder gar redundant ist. Einzige Ausnahme bilden die seit jeher akzeptieren Cookies (bekannte Zitate anderer Personen, hat nichts mit den in Browsern verwendeten Keksen zu tun.), wenn sie klein und dezent plaziert werden. |
Falsch:
| Angabe von mehr als einer Email-Adresse aus Gründen der Profilierung, wenn sowieso alle per Mail-Forwarding zum selben Ziel führen. Oder Angabe von Adress-Informationen, wie z.B. "RFC822: foo@bar.com". Denn dass es sich hierbei um eine Adresse handelt, die im Standard RFC822 definiert ist, wissen die Insider sowieso und die anderen brauchen es auch gar nicht wissen |
Die Unterschrift
| Die Signatur ersetzt die Unterschrift (Ausnahme: echte digitale Unterschriften mit GnuPG/PGP) und das persönliche Erscheinungsbild des Autors. Man sollte also darauf achten, dass man keinen schlechten Eindruck hinterläßt. Eine Signatur sollte möglichst nur 4-6 Zeilen umfassen, un als TEXT eingebunden sein. Also immer merken: ,,USENET is a wonderful mechanism for making a fool of yourself in front of a very large audience. --Lars Poulsen''. Vielleicht sollte man also darüber nachdenken, ob die Signatur von manchen Autoren bewußt so ist, wie sie ist und warum sie genau so ist. Siehe auch: GnuPG/PGP |
Falsch:
| Signaturen mit großen ASCII-Art Bildern, kommerziellen Hinweisen, oder gar wenn die Sig vollständig aus einer Grafig besteht, etc. |
Richtig:
| ------------------------------------------------------------ Ruebezahl AG / Wir retten Ihre Katze mailto:info@ruebezahl.de http://www.ruebezahl.de ------------------------------------------------------------ oder -- Manfred Müller Rübezahl AG / Wir retten Ihre Katze Wertweg 15, 12345 Entenhausen, Anfahrt: http://www.anfahrt.de fon +49-123-45678, fax +49-123-45678, DATA+49-123-76543(8n1) ------------------------------------------------------------ |
Größe der Signatur
| Eine Signatur sollte nicht mehr als 4 Zeilen haben. Der Hintergrund ist einerseits die verschwendete Bandbreite des Netzes und andererseits die Aufdringlichkeit beim Lesen. |
Falsch:
| Signatur mit mehr als 4 Zeilen |
Layout
Zeilenumbruch
| Der Zeilenumbruch sollte etwa bei Spalte 72 erfolgen. Denn damit kann der Text mindestens noch zweimal gequotet werden, ohne künstliche Zeilenumbrüche auf den gängigen Bildschirmen hervorzurufen. |
Falsch:
| Zeilenumbruch bei Spalte 80 oder gar keinerlei Umbrüche (alles in einer Zeile, gerade bei Windows-Frontends wegen den Newlines) |
Umlaute (nur fremdsprachige Newsgroups oder Mailpartner)
| Wird Mail an einen Fremdsprachigen Empfänger gesand, ist zu bedenken, das dieser den Text ggf. nicht korrekt darstellen kann. So sollten Umlaute entweder als ,,oe, ae, ue, sz'' codiert werden (sicherste Methode), mit Hilfe von MIME-Backends zu MIME-Entities konvertiert werden (beste Methode) oder bei der direkten Nutzung von Umlauten dafür gesorgt werden, dass diese im ISO-Latin-1 Format (und nicht Windows-Format) gespeichert werden. Bei letzterem sollte man sicher sein, dass die genutzen Mail-Transfer-Agents (MTAs) 8-Bit-clean sind und der Empfänger ISO-Latin-1 auch darstellen kann. |
Falsch:
| Durch falsche Kodierung der Umlaute wird der Text beim Empfänger unleserlich. |
Leerraum
| Weder zuviel noch zu wenig Leerzeilen in den Text einfügen. Zuviel dehnt den Artikel unnötig und macht in somit unhandbar. Zu wenig führt dazu, dass der Leser sich beim Lesen anstrengen muß. Dies gilt besonders beim Quoting: Zwischen gequotetem Text und eigenem Antwort-Teil gehört idr. nur eine Leerzeile. |
Falsch:
| Irgendwo mehr als zwei Leerzeilen im Text, es sei denn man will unbedingt einen Absatz besonders hervorheben. |
Sprache
Anrede
| Mail-Artikel werden üblicherweise wie Briefe mit einer kurzen persönlichen Anrede begonnen. News-Artikeln wird keine Anrede vorangestellt. |
Falsch:
| Anrede "Hallo liebe Usenet'ler..." in News-Posting |
Persoenliche Ansprache
| In Mail-Artikeln wird der/die Empfänger entweder mit Sie oder Du angesprochen (wie im Brief). In News-Artikeln werden die Empfänger immer mit Du angesprochen. |
Falsch:
| Anrede mit Sie in News-Posting |
Englisch/Deutsch
| In Mail-Artikeln wird die Sprache entsprechend dem Empfänger gewählt. In News-Artikeln wird grundsätzlich Englisch geschrieben, es sei denn man schreibt nach ,,de.*'' oder in eine lokale Newsgroup (z.B. ,,sdm.*''). |
Falsch:
| Deutsche Sprache in internationaler Newsgroup |
Großbuchstaben
| Niemals einen ganzen Satz oder gar Absatz komplett in Großbuchstaben (All-Caps) schreiben. Es sei denn, man will einen Satz (aber wirklich nur einen Satz!) besonders hervorheben und gleichzeitig ein Schreien zum Ausdruck bringen. Ansonsten sollte man zur Hervorhebung einzelner Wörter die Varianten ,,*...*'' und ,,_...._'' (<= das sind diesmal echte Unterstriche!) bzw. für Sätze die Einrückung nutzen. |
Falsch:
| Ganzer Absatz in Großbuchstaben |
Emoticons
Witzig gemeinte, bedrückende oder ironische Textpassagen immer mit Emoticons (Smileys ,,'', frowns ,, '' oder winks ,,'', etc.) kennzeichnen, um Mißverständnisse auf Seiten des Lesers zu vermeiden. Stellenweise auch als Schriftabkürzung (LOL, ACK, ...).
|
Falsch:
| z.B. ironische Aussage ohne ,,'' |
Layout und Rechtschreibung
| Im Usenet ist das Layout des Artikels generell wichtiger als die Rechtschreibung. Aber nach Möglichkeit sollte man dennoch wenigstens mit Hilfe von Spellcheckern versuchen, eine korrekte Rechtschreibung zu nutzen. |
Falsch:
| Korrekte Rechtschreibung, aber schlechtes Layout und Stil |
Verschiedenes
Erst lesen, dann schreiben
| Erst die FAQs (Liste der häufig gestellten Fragen) einer Newsgroup lesen und mindestens 2 Wochen lang passiv die dort auftretenden Artikel mitlesen, bevor man etwas postet. |
Falsch:
| Posten in eine Newsgroup, die man nicht kennt. Vielleicht sogar noch Posten einer FAQ. |
Aufforderungen zu illegalen Dingen
| In Newsgroups etwas posten ist wie etwas publizieren: Deshalb keine Anregungen für illegale Dinge. |
Falsch:
| Die dauernd auftretenden Postings mit dem Subject ,,MAKE MONEY FAST'' |
Präzise Fragen
| Wenn man eine Frage stellt, diese so einfach und kurz halten wie möglich, aber auch so präzize und vollständig wie möglich. Immer an den Spruch denken: ,,Wissenschaft ist die Kunst einfache Sachverhalte so kompliziert auszudrücken, das niemand sie versteht!''. Man braucht sich also in so einem Fall nicht zu wundern, wenn man keine Antworten bekommt. |
Falsch:
| Bugreport an einen Autor per Email senden, ohne die Versionsnummer des Programms zu erwähnen |
Flame-Wars
| Flame-Wars vermeiden! Auch wenn es heißt: ,,The flame war is a specific Usenet art form. -- G. Wolfe Woodbury''. |
Falsch:
| Auf eine Kritik mit Beschimpfungen reagieren |
Kill-File und Mail-Filter
| Anstatt einen nervigen Sender zu beschimpfen, sollte man ihn lieber in Zukunft ignorieren. Dies kann man automatisch durch sog. Kill-Files erreichen. Aber aufpassen, denn es gibt nicht umsonst folgenden Witz: ``Der User Fred K. wundert sich darüber, wohin all der News-Traffic verschwunden ist, und der Rest des Netzes stellt sich die gleiche Frage bezüglich Fred K. Beide Seiten beschließen, ihre Kill-Files auszumisten.'' Selbiges gilt für sog. Spams, d.h. (meist kommerzielle) Massenversendungen per Email. Auch hier sollte man lieber Mail-Filter nutzen. |
Falsch:
| Flame-War eingehen anstatt den Sender ins Kill-File einzutragen |
Transferzeiten
| Die Transferzeiten sind sehr unterschiedlich. Also nicht ungedulig sein, wenn nach 1 Stunde noch keine Antwort auftritt. Mail: 1-10 min (Lokal), 10 min - 8 Stunden (Internet), News: 1-10 min (Lokal) 1 - 4 Tage (Internet). |
Falsch:
| Ungeduld und sofortiges Re-Posten der Nachricht |
Volltext-Archivierung
| Nie vergessen: Im Internet werden an vielen Stellen alle Artikel des Usenet archiviert und man kann sogar über Suchformulare Volltext-Recherchen tätigen. Also sollte man darauf achten, was man von sich gibt, denn der (nächste) Chef braucht nur deinen Namen einzugeben und schon sieht er, was du die letzten Jahre so von dir gegeben hast. |
Falsch:
| Persönliche Ansichten (besonders wenn gefährlicher Art) in den News posten |
Usenet-Slang
Das Usenet hat eine lange Tradition und deshalb auch seine eigene Sprache. Man sollte sich diese wenigstens zum Teil aneignen, um nicht ständig im Regen zu stehen. Ein paar Hinweise zu Sprachabkürzungen:
|
Falsch:
| Auf ,,RTFM'' Reply mit ,,Was ist das für eine blöde Antwort'' antworten |
Dateianhänge
| Dateianhänge (Attachements) also Daten/Dateien, die als Email verschickt werden, sollten grundsätzlich vorher in ein "sprechendes" Verzeichnis kopiert werden, welches anschließend mit Winzip/Stuffit/o.ä. gepackt wird. Erst dann wird das so entstandene Archiv an die Email angehängt. In der Email selber hat sich ein deutlicher Verweis auf den Anhang, ggf. auch seinen Inhalt u.o. die Dateigrösse zu finden. So braucht vom Empfänger nur noch _eine_ Datei von der Mail 'abgehängt' zu werden (Einfacheres Handling), und auch beim Auspacken besteht nie die Gefahr, das es unübersichtlich wird, da nur _ein_ Verzeichnis mit entsprechendem Namen entsteht; dieses und das Archiv kann auch einfacher archiviert werden. Ausserdem müssen, durch die Komprimierung, weniger Daten übertragen werden. So ist es auch völlig unnötig z.B. eingescannte Clippings als Powerpointvortrag zu versenden, sie sind als Bitmap (*.bmp) oder JPEG (*.jpg) auf obrige Weise verpackt wesentlich Platzsparender und einfacher zu handeln. |
Falsch:
| Mehrere Dateien einfach an die Mail anhängen. Und/oder BMP/TIFF o.ä. statt JPG/GIF zu benutzen. |
Richtig:
| Bilder erst zuschneiden, dann als GIF (für Comichafte Bilder) oder JPG (für Fotos) in ein Verzeichnis mit sprechendem Namen (z.B: 'Beates_Urlaub_2006/') speichern, dieses dann in ein Archiv (ZIP) verpacken (z.B. mit 7zip siehe http://www.fkn-systems.de/?c=virus) und an die Mail anhängen. |
Emfangsbestätigung und Priorität
| Emfangsbestätigung und Priorität kann man je nach verwendeten Mail-Client einstellen, leider obliegt deren Auswertung ebenfalls den Einstellungen/Möglichkeiten des Ziel-Clients, so dass man sich nicht unbedingt auf diese Funktion verlassen kann. Die Emfangsbestätigung wird dabei besser unterstützt als die Priorität; im Zweifel einfach verwenden, wo es sinnvoll ist. |
Falsch:
| Sich auf die Funktion der Emfangsbestätigung und Priorität verlassen. |
Hoax der Pseudo-Virus
| Pseudo-Viren sind Programme, die einem Viren- Suchprogramm einen echten Virus vorgaukeln, ansonsten aber harmlos sind. Sie enthalten für Viren typische Bitfolgen. Im Unterschied zu einem Virus (im engeren Sinn), der immer Teil des verseuchten Wirtprogrammes ist, ist ein Pseudo-Virus ein eigenständiges Programm. Solche Programme werden zum Testen von Viren-Scannern eingesetzt. Und dann gibt es noch Viren, die es gar nicht gibt. Im Netz vagabundieren - zum Teil seit Jahren - nur Warnungen davor, die jeder Grundlage entbehren. Diese Warnungen werden als Hoax bezeichnet, was Schlechter Scherz, Schwindel oder blinder Alarm bedeutet. Beispielweise soll eine Email mit dem Subject Good Times beim Gelesenwerden die Platte ruinieren. Man möge sie ungelesen löschen und dieWarnung an alle Bekannten weitergeben. Dieser Hoax ist so bekannt, dass sogar eine FAQ dazu im Netz steht. Weitere bekannte Hoaxe sind Irina, Penpal Greetings, Internet Cleanup Day (der ist wenigstens witzig), Join the Crew und Win A Holiday. Der Schaden eines Hoax liegt in der Belästigung der Netzteilnehmer. Eine ähnliche Belästigung wie die falschen Virenwarnungen sind die Kettenbriefe vom Typ A Little Girl Dying oder Hawaiian Good Luck Totem. Woran erkennt man eine Virenwarnung als Hoax? In obigem Fall daran, dass technischer Unsinn verzapft wird.Weiter gibt es im Netz Stellen, die sich intensiv mit Viren befassen und früher informiert sind als die Mehrheit der Benutzer. Warnungen solcher Stellen - aus erster Hand und nicht über zweifelhafte Umwege - sind ernst zu nehmen, alles andere sollte einen Benutzer nur dazu bringen, seine Sicherheitsmaflnahmen zu überdenken, mehr nicht. Insbesondere soll man die Hoaxe oder Kettenbriefe nicht weiter verteilen. |
Falsch:
| Mail unverlangt an andere Addressaten weiterzuleiten. |
Dateitypen
| Grundsätzlich sollte man sich Gedanken um den Versand von Daten machen. Frei nach der Regel 'Weniger ist Mehr' gilt dies eigentlich für alle Bereiche. Das heisst, Daten sollten immer auf den kleinsten gemeinsamen Nenner herunterskaliert werden. Es nützt niemanden, eine Email mit 'alles dreht sich und alles Bewegt sich' zu bekommen wenn: a) nur drinsteht '...bin aus dem Urlaub zurück...' b) sich die Daten mangels passendem Programm gar nicht anzeigen lässt. Gleiches gilt beispielweise auch für Dokumente. Das Format DOC (Word) hat sich zwar weit verbreitet, aber Textboxen, Layer und anderer Schnickschnack, ändert nichts daran, dass ein Dokument eigentlich nur aus Text, Absätzen, Schriftarten und -grössen und Formatanweisungen wie Fett, Kursiv, Unterstrichen,.. enthält. Der eigentliche Inhalt (Text) lässt sich auch als Text lesbar darstellen, der Rest ist vielleicht hübsch, verhindert aber mitunter den Import in andere Programme (und damit das Anzeigen) und bläht die Datei unnötig auf. Beispiel: 5000 Zeichen Text ergeben ein 5 MegaByte grosses DOC. Zum Vergleich; Die Bibel mit Altem und Neuem Testament nebst Anmerkungen ist gerade mal ~ 6 Megabyte gross, also 6.000.000 Zeichen. Welch eine Verschwendung in den Worddokumenten.  Ausserdem stehen meisst in solchen Dokumenten Ausschnitte/Teile von vorangegangenen Dokumenten, und man will doch nicht das andere lesen können was man noch so schreibt oder? Möglicherweise erreichen solche Mails auch nicht den Empfänger weil unterwegs oder beim Empfänger Mails von anhängenden Word (&Co.) Dokumenten befreit, bzw. gelöscht werden. |
Falsch:
| Daten im Format seines supertollen, hypermega Progammes YXZ_V15.0-4000 versenden, und sich aufregen wenns keiner sehen kann. |
Warum PDF, wann Text, warum nicht DOC
Häufig werden Daten versand, welche der Empfänger nicht mehr bearbeiten muss. Beispielsweise Urlaubsgrüsse, Bekanntmachungen, Einladungen, etc. Diese Daten kann man mit folgendem Frageschema einfach in drei Kategorien einteilen:
Alle diese Punkte lassen sich elegant umgehen wenn Sie Ihr Dokument vorher nach PDF konvertieren und es erst dann an die Email anhängen. Durch PDF wird sichergestellt das Ihr Dokument überall gleich aussieht, genauso gedruckt wird, es ist vergleichsweise klein, das Layout bleibt bestehen. Und die meissten Benutzer haben den Acrobatreader (==>http://www.adobe.de/products/acrobat/readstep2.html), oder ein vergleichbares Programm installiert. Sie können kein PDF exportieren? Am einfachsten und (Lizens-)Kostensparenden ist die Benutzung von Openoffice (==>http://de.openoffice.org/ [Download]), dort reicht ein Knopfdruck um aus Ihrem Dokument ein PDF zu machen. Ausserdem ist das Programm Lizenskostenfrei, Sicherer als Word/Excel/Powerpoint und ein vollwertiger Ersatz für genannte Programme. Um nur unter Windows PDFs erzeugen zu können bietet sich z.B. PDF-Creator (Drucken Sie Ihre PDFs aus jeder Anwendung, ==> http://sector7g.wurzel6.de/pdfcreator/download.htm) an. Der hier dargestellte Bezug auf Word-Doc ist beispielhaft und soll nicht das Programm schlechtmachen, sondern für die Problematik sensibelisieren, und Alternativen aufzeigen. |
Falsch:
| Daten im Format Word-DOC (o.ä.) versenden, welche nicht mehr vom Empfänger zu verändern werden müssen, anstatt ein Plattform unabhängiges Format wie PDF zu benutzen. |
Richtig:
|
Allgemeines zur Email
Hier ein paar allgemeine Worte zum Thema Email
|
isten besser BCC: verwenden, Überlegen statt sinnlos alles weiterzuleiten. Falsch:
| Von Annahmen ausgehen ohne sich zu informieren. |
GnuPG/PGP, EMail Verschlüsseln und Signieren
Vorab: Die Signatur (auch Unterschrift siehe: Die Unterschrift) hat nichts mit dem elektronischen Signieren von Nachrichten zu tun. Im ersten Fall handelt es sich nur um eine an den Text angehängte Textpassage mit der Kennung/Adresse des Versenders. Beim signieren von Nachrichten wird diese komplett (also einschliesslich anhängender Signatur und/oder anhängender Daten) mit dem privaten elektronischen Schlüsel des Versenders unterschrieben. Dazu wird über die zu signierenden Daten eine Prüfzumme gebildet und diese, nach Verschlüsselung mit dem Private-Key, unten an die Daten gehängt. Beim verschlüsseln non Nachrichten oder Daten werden nach gleichem Prinzip alle Daten verschlüsselt und diese in eine sogenannte ASCII-Hülle verpackt. Diese gewährleistet den Transport, da nur druckbare Zeichen verwand werden.
|
FIN
FKN-Systems.de Nettikette / Created at: 2024-11-21/09:44.31
