Wieder ein Mailwurm: W32/Aliz (whatever.exe)
Alexand...@univie.ac.at
Es ist wieder ein neuer Mailwurm im Umlauf. Dieser wird von den
zentralen Virenscannern erst seit Do, 22.11, 20:10 entdeckt. Zu
erkennen ist er am Attachment "whatever.exe", das moeglicherweise
von Outlook Express bereits in der Vorschau ausgefuehrt wird.
Nach den bisher vorliegenden Informationen enthaelt der Wurm keine
Schadensfunktion, ausser der, dass er sich selbst weiterleitet, was
aber schon Schaden genug ist.
Zu erkennen ist Aliz am Subject, das sich aus vier Teilen
zusammensetzt:
Ein Wort aus der Liste:
'Cool' 'Nice' 'Hot' 'some' 'Funny' 'weird' 'funky' 'great' 'Interesting'
'many'
gefolgt von einem weiteren aus:
'website' 'site' 'pics' 'urls' 'pictures' 'stuff' 'mp3s' 'shit' 'music'
'info'
gefolgt von:
'to check' 'for you' 'i found' 'to see' 'here' '- check it
und schliesslich eines von:
'!!' '!' ':-)' '?!' 'hehe' ';-) '
Das Subject kann also zum Beispiel lauten:
"Cool website to check !!"
"Funny pictures for you hehe"
"Interesting shit to see ?!"
...
Der Text der Nachricht lautet schlicht und einfach: peace.
Weitere Informationen veroeffentlichen wir, wie gewohnt, unter "Aktuell"
auf der Homepage des ZID: http://www.univie.ac.at/ZID/
Neueste Versionen von Outlook Express sollen davon nicht mehr betroffen
sein. Weitere Informationen und Patches bietet der Hersteller unter:
http://www.microsoft.com/windows/ie/downloads/critical/patch9/default.asp
an.
* * *
Hintergrundinformation fuer technisch Interessierte:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Der Wurm kann, obwohl er dem von uns eingesetzten McAfee Virenscanner
bekannt ist, deshalb den Filter passieren, weil das boesartige
Attachment, das von den Mailclients ausgefuehrt wird, eigentlich keines
sein duerfte.
Aufbau der Virenmail:
'''''''''''''''''''''
In der versandten eMail-Nachrichten steht:
|---8<--------------------------------------------------------------
| [...]
| MIME-Version: 1.0
| Content-Type: multipart/mixed;
| boundary="bound"
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Mailer: Microsoft Outlook Express 5.50.4522.1300
| X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1300
|
| This is a multi-part message in MIME format.
|
| --bound
| Content-Type: text/html;
| charset="iso-8859-1"
| Content-Transfer-Encoding: quoted-printable
|
| <HTML><HEAD></HEAD><BODY><iframe src=3Dcid:SOMECID height=3D0 width=3D0>
| </iframe>
| <font>peace</font></BODY></HTML>
|
| --bound
| Content-Type: audio/x-wav;
| name="whatever.exe"
| Content-Transfer-Encoding: base64
| Content-ID: <SOMECID>
|
| TVoAAAIAAAACAB4AHgAAAAACAAAAAAAAAAAAAMWnLuEOH7oOALQJ
| zSG4/0zNIVdpbjMyIG9ubHkhDQokQAAAAFBFAABMAQQAwipthgAA
| AAAAAAAA4ACOgQsBAhkACgAAAAQAAAAAAAAAEAAAABAAAAAgAAAA
| [...]
|---8<--------------------------------------------------------------
Der Header:
Content-Type: multipart/mixed;
boundary="bound"
wird von eMail-Klienten so verstanden, dass die einzelnen Teile der
Nachricht, also der (HTML-)Text und die Attachments, durch eine Zeile
mit dem Inhalt "--bound" voneinander getrennt sind. Der erste Teil,
vom Typ text/html, wird als Text, naemlich "peace" angezeigt. Der
zweite Teil ist deklariert als Sound-Datei (WAV), heisst
"whatever.exe", und die seltsame Buchstabenfolge darunter ist die
fuer den Transport verpackte Form eines Attachments.
Das Verstaendnis der eMail-Klienten ist zwar im Sinne des Wurms, aber
nicht standardkonform: Der Header ist fehlerhaft und daher gibt es
eigentlich keine Attachments, weshalb sie der Virenscanner nicht
als infiziert erkennen kann.
Die Outlook-Sicherheitsluecke:
''''''''''''''''''''''''''''''
Aliz nutzt eine Sicherheitsluecke in Outlook Express, die bereits
seit langem bekannt ist, und sich durch eine Analogie gut beschreiben
laesst:
Eine finstere Gestalt will beim Flughafen einchecken. Deutlich zu
erkennen ist der Schulterhalfter mit der geladenen Pistole. Am
Guertel haengen ein paar Handgranaten und ein Krummsaebel. Der
Security-Beauftragte fragt: "Sind Sie Terrorist?" Die Gestalt
antwortet: "Ich bin ein harmloser Tourist" und darf daraufhin
ohne weitere Kontrolle das Flugzeug besteigen.
Eine undenkbare Geschichte - in der Welt der Software ist das aber
ein verbreitetes Produkt:
Das als audio/x-wav deklarierte Attachment whatever.exe wird von
Outlook Express als Hintergrundmusik zur eMail verstanden und
automatisch abgespielt. Aufgrund eines schwer verzeihlichen
Designfehlers wird der vermeintliche Sound whatever.exe zwar als
Programm erkannt - weil er eben kein Sound ist - aber dennoch ohne
Rueckfrage - weil ja behauptet wurde, es sei bloss ein Soundfile -
ausgefuehrt. Und damit ist der Wurm ohne weiteres Zutun des Users
aktiv geworden.
Warum die Virenscanner Aliz nicht erkennen konnten
''''''''''''''''''''''''''''''''''''''''''''''''''
Beim zentralen Virenscan werden die Attachments jeder Mail extrahiert
und von McAfee untersucht. Findet dieser einen Virus, wird die Mail
mit einer Fehlermeldung, die auch den Namen des gefundenen Virus
enthaelt, vom Mailserver abgewiesen.
In diesem Fall spiesst es sich beim Extrahieren der Attachments: Da
die Boundary-Deklaration nicht, wie es vom Mime-Standard (RFC 2045,
Seite 12, "5.1 Syntax of the Content-Type Header Field") vorgeschrieben
wird, mit einem Strichpunkt abgeschlossen wird, wurde beim Extrahieren
der Trenner zwischen den einzelnen Teilen anders interpretiert (dass
eine neue Zeile beginnt, spielt hier keine Rolle), womit die Attachments
nicht erkannt wurden und das Scannen vereitelt wurde.
Die Software wurde inzwischen dem Bug der gaengigen Mailklienten
angepasst und somit wird auch W32/Aliz nun erkannt.
Mit freundlichen Gruessen,
Alexander Talos
Boris 'pi' Piwinger
> Es ist wieder ein neuer Mailwurm im Umlauf.
> Hintergrundinformation fuer technisch Interessierte:
> Aufbau der Virenmail:
> Die Outlook-Sicherheitsluecke:
> Warum die Virenscanner Aliz nicht erkennen konnten
Whow, ich habe noch nie eine derart liebevolle Analyse eines neuen
Microsoft-Virus gesehen. Respekt!
Nur eines habe ich noch nicht verstanden. Warum nutzen Leute derart
kranke Reader? (Dies war eine rhetorische Frage, NRN.)
pi
Martin Wernig
der Vorschau ausführt?
Die einzige Vorschaudatei in OE ist das HTML ohne Script, JPG und
BMP-Format!
Da muss man schon die Büroklammer anklicken und die Warnung ignorieren um
die Datei zu starten.
lg,
Martin
Alexand...@univie.ac.at
>> erkennen ist er am Attachment "whatever.exe", das moeglicherweise
>> von Outlook Express bereits in der Vorschau ausgefuehrt wird.
>Wie kommt ihr eigentlich immer auf die Idee, das OE die Datei immer schon in
>der Vorschau ausführt?
Berechtigte Frage.
[Disclaimer: Ich bin so vorsichtig gewesen, "moeglicherweise"
dazuzuschreiben, und zwar nicht ohne Grund: Ich selbst bin ein
Einwohner der Unix-Welt und verwende selbst kein Windows. Outlook
(mit oder ohne Express) habe ich selbst noch nie benutzt. Logisch -
meine Aufgabe ist ja, die Server am Leben zu erhalten, die laufen
klarerweise unter Unix.
Weil wir aber die Server fuer unsere User betreiben, die fuer die teils
erschreckend armselige Qualitaet der marktbeherrschenden Software
allerhoechstens mittelbar etwas koennen, gehoert es bis zu einem
gewissen Grad dazu, auch die Dummheiten dieser Software auszubuegeln
(zu versuchen). Dazu zaehlt das Abfangen spektakulaerer Artefakte des
beliebten Mailzertruemmerers Exchange ebenso wie die Virenscannerei.
Kurz: Ich kenne zwar die Software nicht persoenlich, aber ich sehe
tagtaeglich sehr genau, was sie ueber die Leitung schickt.
Es muss an dieser Stelle aber auch gesagt werden, dass der Patch, der
diese Luecke schliesst, von Microsoft bereits am 29. Maerz 2001
veroeffentlicht wurde: <URI:http://www.microsoft.com/technet/treeview
/default.asp?url=/technet/security/bulletin/MS01-020.asp>]
Der Outlook-Bug ist mir aus den einschlaegigen Quellen bekannt, und
dort immer wieder in verschiedenen Varianten besprochen worden.
http://www.cert.org/advisories/CA-2001-06.html:
"This vulnerability allows an intruder to construct malicious content
that, when viewed in Internet Explorer (or any program that uses the
IE HTML rendering engine), can execute arbitrary code. It is not
necessary to run an attachment; simply viewing the document in a
vulnerable program is sufficient to execute arbitrary code."
"There have been reports that simply previewing HTML content (as in a
mail client or filesystem browser) is sufficient to trigger the
vulnerability. The impact of viewing malicious code in this manner is
being evaluated."
Dazu ist zu sagen, dass CERT seinem Namen (Computer Emergency Response
Team) zum Troz ausgesprochen behaebig und bedaechtig reagiert.
Anlaesslich des Nimda-Wurms hat aber auch CERT erkannt:
http://www.cert.org/advisories/CA-2001-26.html
"Thus, in vulnerable configurations, the worm payload will automatically
be triggered by simply opening (or previewing) this mail message."
Hier wurde auf Nimda bzw. allgemein auf die Vulnerability bezug
genommen, konkret ueber den Aliz-Wurm behaupten es immerhin:
Symantec:
http://securityresponse.symantec.com/avcenter/venc/data/w32.aliz.worm.html
Norman:
http://www.norman.com/virus_info/w32_aliz_4096_mm.shtml
Nur selbst probiert habe ich es noch nicht (mangels Windows in sicherer
Umgebung).
Schoenes Wochenende,
Alexander Talos
Alexand...@univie.ac.at
Erst mal Danke fuer die Blumen...
>Nur eines habe ich noch nicht verstanden. Warum nutzen Leute derart
>kranke Reader? (Dies war eine rhetorische Frage, NRN.)
Mich wuerde das wirklich interessieren.
Oft ist es sicher einfach nur die Corporate Softwareausstattung, die
dem User womoeglich auch nicht die Option offenlaesst, etwas anderes
dazuzuinstallieren.
Viele haben den Rechner einfach mit dem vorinstallierten Outlook
bekommen und noch nicht genug Anlass gehabt, umzusteigen. Es fragt sich
auch, worauf.
Vielleicht ein Anreiz: Andere sehen nach dieser Zeile:
begin whatever.exe
noch Text. Outlook-User muessen aber leider auf meinen Gruss verzichten
- ihr Newsreadaer haelt - ohne triftigen Grund - alles nach
"begin Abstand Abstand Wort" fuer ein Attachment.
Schoene Gruesse,
Alexander Talos, der "Ich bin Signature Virus. Verbreite mich!" wohl
kennt.
Version 0.815. end
Martin Braun
news:3bfedf6c$0$91002$3b21...@news.univie.ac.at...
> begin whatever.exe
Da eine Zeile der Form "begin" + Abstand + Abstand + Wort mit hinreichend
hoher Wahrscheinlichkeit nicht in normalem Nachrichtentext vorkommt, kann
die Software trotz anderer (oder in deinem Fall: keiner) Content-
Deklaration davon ausgehen, dass die Kennzeichnung des Attachmentbeginns
auch tatsächlich die Kennzeichung eines Attachmentbeginns ist. Wer
absichtlich [!] einen Steuercode einfügt, von dem er zudem weiß [!], dass
er als Steuercode interpretiert wird (sei es, um irgendjemanden zu irgend
etwas zu bewegen, ihn zu belästigen, zu ärgern oder aus sonsteinem Grund)
macht sich der absichtlichen Irreführung oder Schlimmeren schuldig und
bewirkt lediglich, dass seine Nachrichten nicht mehr gelesen werden (weil
sie der Mühe einfach nicht wert sind). Dies gilt insbesondere für
Newsgroupbeiträge von Leuten, die die Kennzeichnung des Attachmentbeginns
gleich zu Beginn als "begin quoting" einfügen. - Das ist etwa so, also
würde ich ein End-of-file-Zeichen setzen. Alles, was nach dem Zeichen
Lukas Ertl
><Alexand...@univie.ac.at> schrieb im Newsbeitrag
>
>> begin whatever.exe
>
> Da eine Zeile der Form "begin" + Abstand + Abstand + Wort mit hinreichend
> hoher Wahrscheinlichkeit nicht in normalem Nachrichtentext vorkommt, kann
> die Software trotz anderer (oder in deinem Fall: keiner) Content-
> Deklaration davon ausgehen, dass die Kennzeichnung des Attachmentbeginns
> auch tatsächlich die Kennzeichung eines Attachmentbeginns ist. Wer
Wieso sollte eine Software (in dem Fall etwas relativ "simples" wie ein
Newsreader bzw. eMail-Client) sich auf irgendwelche
"Wahrscheinlichkeiten" verlassen und sich nicht an (gut eingeführte)
Standards halten?
lg,
le
--
+-- Lukas Ertl - Unix-Sysadmin -----------------------------------------------+
| "It is easier to port a shell than a shell script." -- Larry Wall |
+------------------------------- ZID Universität Wien - ++43 (1) 4277-14073 --+
Boris 'pi' Piwinger
>> begin whatever.exe
>
> Da eine Zeile der Form "begin" + Abstand + Abstand + Wort mit hinreichend
> hoher Wahrscheinlichkeit nicht in normalem Nachrichtentext vorkommt, kann
> die Software trotz anderer (oder in deinem Fall: keiner) Content-
> Deklaration davon ausgehen, dass die Kennzeichnung des Attachmentbeginns
> auch tatsächlich die Kennzeichung eines Attachmentbeginns ist.
Ad 1) Mails und Postings ohne Content-Type-Header sind sehr selten
und werden meistens von kaputter MS-Software erzeugt. Dennoch inter-
pretiert dieselbe kaputte Software etwas, was eindeutig als reinstes
text/plain deklariert ist, als Attachment.
Ad 2) Wieso sollte man etwas, was man fuer "mit hoher Wahrscheinlich-
keit" nicht fuer normalen Text haelt, als Attachment interpretieren?
Vor allem, da es nicht die geringste Aehnlichkeit mit irgend einer
bekannten Kodierung hat. Microsoft behauptet faelschlicherweise, dass
es nach UUencode aussehen wuerde. Das ist aber schlicht und ergreifend
blanker Unfug, da dort immer die Angabe der Permissions nach dem Wort
begin folgt -- erst dann kommt der Dateiname. Da kann man sich dann
auf den Kopf stellen, aber einen Grund gibt es da beim besten Willen
nicht.
> Wer absichtlich [!] einen Steuercode einfügt,
Was fuer ein Steuercode?
> von dem er zudem weiß [!], dass
> er als Steuercode interpretiert wird (sei es, um irgendjemanden zu irgend
> etwas zu bewegen, ihn zu belästigen, zu ärgern oder aus sonsteinem Grund)
> macht sich der absichtlichen Irreführung oder Schlimmeren schuldig und
> bewirkt lediglich, dass seine Nachrichten nicht mehr gelesen werden (weil
> sie der Mühe einfach nicht wert sind). Dies gilt insbesondere für
> Newsgroupbeiträge von Leuten, die die Kennzeichnung des Attachmentbeginns
> gleich zu Beginn als "begin quoting" einfügen. - Das ist etwa so, also
> würde ich ein End-of-file-Zeichen setzen. Alles, was nach dem Zeichen
ROTFL
pi
Andreas Metzler
>> begin whatever.exe
> Da eine Zeile der Form "begin" + Abstand + Abstand + Wort mit hinreichend
> hoher Wahrscheinlichkeit nicht in normalem Nachrichtentext vorkommt, kann
> die Software trotz anderer (oder in deinem Fall: keiner) Content-
> Deklaration davon ausgehen, dass die Kennzeichnung des Attachmentbeginns
> auch tatsächlich die Kennzeichung eines Attachmentbeginns ist.
Hallo!
Du ignorierst, dass eine Kennzeichnung fuer einen uu-kodierten Teil
nicht "begin 2*Space irgendwas" lautet sondern
begin <Space> drei-stellige-Zahl Dateiname
cu andreas
PS: Man kann auch ordentliche Newsreader, wie diesen, so
konfigurieren, dass uu-kodierten Text wie ein Attachment
dargestellt wird, und es funktioniert gut, dennoch bleibt
begin 2*Space wirkungslos.
PPS: Wenn man Blocksatz verwendet (autsch) oder zitiert (z.B.. aus
Unix-Manual-Pages) ist begin 2*Space nicht mehr unwahrscheinlich.
Martin Braun
news:3bffabb9$0$119726$3b21...@news.univie.ac.at...
> Dennoch inter-
> pretiert dieselbe kaputte Software etwas, was eindeutig als reinstes
> text/plain deklariert ist, als Attachment.
Dass OLE Fehler aufweist, ist nicht anders zu erwarten. Und dass er sich
nicht an Standards hält, ist auch schwer erträglich. Kritik an einem
Programm ist aber eine Sache, anderen Leuten absichtlich das Leben schwer
zu machen eine andere.
Grüße,
Martin
Alexand...@univie.ac.at
Martin Braun wrote:
>Da eine Zeile der Form "begin" + Abstand + Abstand + Wort mit hinreichend
>hoher Wahrscheinlichkeit nicht in normalem Nachrichtentext vorkommt, kann
>die Software trotz anderer (oder in deinem Fall: keiner) Content-
>Deklaration davon ausgehen, dass die Kennzeichnung des Attachmentbeginns
>auch tatsächlich die Kennzeichung eines Attachmentbeginns ist. Wer
Da gibt es von mir einen Einspruch, und wenn ich dafuer Stempelmarken
kleben muss.
1. Uuencode ist kein Standard fuer den Transport von Dateien in
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Internet-Nachrichten.
~~~~~~~~~~~~~~~~~~~~~
Dass bei uuencode noch hinter dem "begin" die permissions hinzukommen,
wurde bereits erwaehnt. Ich moechte noch einiges ergaenzen.
Es war immer klar, dass das uuencoden von Binaerdaten in mail und news
zwar eine leidlich brauchbare unmittelbare Notloesung, aber dennoch ein
Riesenpfusch ist. Es hat sicher nicht zufaellig nie einen RFC - sei es
standard, best current practice, experimental oder auch nur
informational gegeben, der "begin" und irgendetwas danach als
Filemarkierung normiert, empfiehlt, oder auch nur auf eine portable
Basis stellt. Das Wort "uuencode" kommt in 15 von ueber 3000 RFCs vor.
RFC 1154 (April 1990, proposal) und sein Nachfolger 1505 (August 1993,
Experimental, mit dem Vermerk: "IESG Note - Note that a standards-track
technology already exists in this area" (gemeint ist MIME)) befassen
sich mit einem Encoding header field, also gehen etwa in diese
Richtung. Auch hier, und das ist eigentlich selbstverstaendlich, war
stets von einem Header-Feld - also nicht einfach einem
"unwahrscheinlichen" Artefakt des transportierten Inhalts - die Rede,
das spezifiziert, welche Kodierung verwendet wird, von denen UUENCODE
eine von urspruenglich 16 ist.
Auch in RFC 1341 (Juni 1992, Standard), RFC 1521 (September 1993,
Standard, Nachfolger von RFC 1341) und RFC 2045 bzw. RFC 2049 (November
1996, Standard, Nachfolger von RFC 1521f), dem MIME Standard, wird
uuencode erwaehnt und zwar eher unter der Rubrik Naturkatastrophen.
"One of the notable limitations of RFC 821/822 based mail systems is
the fact that they limit the contents of electronic mail messages to
relatively short lines (e.g. 1000 characters or less [RFC-821]) of
7bit US-ASCII. This forces users to convert any non-textual data
that they may wish to send into seven-bit bytes representable as
printable US-ASCII characters before invoking a local mail UA (User
Agent, a program with which human users send and receive mail).
Examples of such encodings currently used in the Internet include
pure hexadecimal, uuencode, the 3-in-4 base 64 scheme specified in
RFC 1421, the Andrew Toolkit Representation [ATK], and many others."
[Erklaerung, welches Problem MIME loesen soll]
"It is impossible to be certain that a non-MIME mail message is
actually plain text in the US-ASCII character set since it might well
be a message that, using some set of nonstandard local conventions
that predate MIME, includes text in another character set or non-
textual data presented in a manner that cannot be automatically
recognized (e.g., a uuencoded compressed UNIX tar file)."
[Deutlicher Hinweis darauf, dass die Bedeutung von Texten, die mit
den guten alten Hacks codiert wurden, nicht eindeutig interpretierbar
sind]
"The following guidelines may be useful to anyone devising a data
format (media type) that is supposed to survive the widest range of
networking technologies and known broken MTAs unscathed. Note that
anything encoded in the base64 encoding will satisfy these rules, but
that some well-known mechanisms, notably the UNIX uuencode facility,
will not."
"(7) Many mail domains use variations on the US-ASCII
character set, or use character sets such as EBCDIC
which contain most but not all of the US-ASCII
characters. The correct translation of characters not
in the "invariant" set cannot be depended on across
character converting gateways. For example, this
situation is a problem when sending uuencoded
information across BITNET, an EBCDIC system. "
[Uuencode ist also nicht einmal robust]
Jetzt stellt sich natuerlich die Frage, wie uuencode ueberhaupt
definiert ist. In den RFCs wird immer nur gesagt "Du fuetterst das in
uuencode und der macht das schon." Kein Wort von begin mit ein, zwei,
oder hundert blanks.
Da mir Posix nicht zur Verfuegung steht, greife ich auf die Single Unix
Specification zurueck:
"The standard output is a text file (encoded in the character set of the
current locale) that begins with the line:
"begin %s %s\n", <mode>, decode_pathname and ends with the line:
end\n
In both cases, the lines have no preceding or trailing blank characters."
Nichtsdestotrotz behauptet Microsoft in:
http://support.microsoft.com/support/kb/articles/Q265/2/30.ASP
"SYMPTOMS
When you use Outlook Express, you may receive a message in which the
text is incorrectly interpreted as an attachment that does not have
any data.
CAUSE
The body of the message starts with the word "begin" followed by two
spaces. This sequence of characters is identical to that of the header
for a file attachment that is encoded in UUencode format. For this
reason, the message is incorrectly interpreted as an encoded attachment."
[...]
"MORE INFORMATION
In a Simple Mail Transfer Protocol (SMTP) e-mail message, a file
attachment that is encoded in UUencode format is defined when the word
"begin" is followed by two spaces and then some data, and the word
"end" appears on a line by itself. In cases where there is no "end" on
a line by itself, the "begin" statement should be treated as normal
text. However, Outlook interprets the following sequence
begin<space><space>data
as a file attachment that is encoded in UUencode format, even if there
is no matching "end" statement to define the end of the attachment
data."
Dazu ist zu sagen:
* Mit SMTP hat der interne Aufbau einer eMail-Nachricht nichts zu tun.
SMTP (RFC 2821) regelt den Transport von Nachrichten, keineswegs den
Inhalt. In SMTP kommt uuencode daher auch nicht vor.
* Kein anderer RFC oder Internet spezifiziert begin ... end als
Markierung eines uuencodeten Files. Im Gegenteil.
* Das uuencode-Format wird von Outlook zu oberflaechlich interpretiert.
Die Behauptung, begin blank blank sei von uuencode vorgeschrieben, ist
schlicht unrichtig.
Charmant ist uebrigens auch der von Microsoft empfohlene Workaround.
Zwar geht es um eine Nachricht, die man nicht selbst geschrieben hat
- "receive a message" -, deren Inhalt man also nicht mehr beeinflussen
und nicht einmal lesen kann, aber man moege sie doch bitte anders
formulieren:
"To workaround this problem:
* Do not start messages with the word "begin" followed by two spaces.
* Use only one space between the word "begin" and the following data.
* Capitalize the word "begin" so that it is reads "Begin."
* Use a different word such as "start" or "commence." "
2. Ein Programm soll nicht versuchen, schlauer zu sein, als der Anwender
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Die Programme uuencode und uudecode wurden spezifisch zu dem Zweck
erfunden, Binaerdaten als Text erscheinen zu lassen. Das ist deshalb
noetig, um die Daten vor der Interpretation durch Programme, die die
Intention des Absenders nicht kennen - koennen - zu schuetzen.
Daher sollte das Programm, in dem Fall also Outlook, nicht die Situation
dadurch verschlimmbessern, dass es sich anmasst, besser zu wissen, was
der Anwender will, als jener selbst.
Vor allem natuerlich nicht unter Anwendung eines voellig obsoleten
Verfahrens.
Fuer so etwas ist in der Computerei der Begriff der Verschlimmbesserung
gebraeuchlich - scheinbar eine Grundhaltung bei Microsoft, wie jeder
weiss, der schon einen Text ueber Sit (Sichere Informationstechnologie,
auch Schlosser-Immobilienteam und vieles mehr, ich weiss nicht mehr,
wovuer die Abkuerzung stand, als ich dieses Problem hatte) schreiben
wollte: Die Autokorrektur macht daraus "ist".
3. Feature sollte abschaltbar sein
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In den guten alten Zeiten, als uuencode noch vererbreitet war, hat es
wahrscheinlich Sinn gemacht, eine eueberhaupt zu implementieren. Heute
ist uuencode im Internet praktisch ausgestorben. Dennoch ist es
natuerlich nicht prinzipiell uebel, Features anzubieten.
Die Betonung liegt aber auf anbieten: Es muss abschaltbar sein, so wie
die Autokorrektur in Office.
Und da es sich um ein Feature handelt, das ein unkalkulierbares
Potential hat, Dinge zu "verschlimmbessern", sollte es per default
ausgeschaltet sein.
4. Egotrip-Standards sind schaedlich
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Gerade das Internet zeigt, dass von einer offenen Comunity betriebenes
Design ein enormes Potential hat. Gerade da, wo es darum geht, dass
verschiedene Systeme miteinander kommunizieren, sind wohldurchdachte,
diskutierte und klar spezifizierte Standards unerlaesslich.
Wer sich die RFCs ansieht, wird feststellen, dass in jedem Fall sehr
viel Bedacht darauf genommen wird, nicht durch eine Neuerung etwas zu
stoeren, das vorher funktioniert hat. Das faengt bereits bei der
Planung an: Erahnbare Neuerungen werden nach Moeglichkeit eingeplant
und allgemein werden Mechanismen vorgesehen, um Erweiterungen
einzufuegen, ohne dass Produkte, die diese Erweiterungen noch nicht
kennen, in ihrer Interoperabilitaet eingeschraenkt werden.
All das hindert niemanden, etwas neues asuzuprobieren und einen RFC
darueber zu schreiben. Ob daraus ein Standard wird, haengt von einer
laengeren Bebruetung ab, an der auch Leute teilnehmen, die aus ganz
anderen Perspektiven an die Sache herangehen. Danach und mit
Aenderungen entsteht ein Standard im Internet.
Adhoc-Loesungen in einzelnen Softwareprodukten hingegen haben schon
viel Unheil gebracht. In diesem Fall trifft es nur den Anwender selbst.
Ein andereres Unheil brachte die Idee mit sich, Microsofts Hauspoeten
doch das "Re: " im Subject uebersetzen zu lassen. Alle ernstzunehmenden
Mail- und Newsreader sowie Listserversoftware, die den Namen der
Mailingliste am den Anfang des Subjects einfuegt, wissen, dass sie
ein "Re: " einfach ignorieren bzw. nicht duplizieren sollen.
"AW: " fuer "Antwort" ist zwar vielleicht viel "deutscher", wird aber
von der gesamten restlichen Welt nicht erkannt. Wenn also ein
Outlook-User auf etwas antwortet, das bereits mit "Re: " beginnt, wird
daraus "AW: Re: ", dan "Re: AW: Re:" und so weiter statt nur eines
einfachen "Re: ". In der Mailingliste msbiaue (Microsoft-Bashing in
at.univie.edv) wuerde das so aussehen:
"Re: [msbiaue] AW: Re: [msbiaue ]..."
und irgendwo ganz rechts waere vielleicht das Subject zu lesen.
Fazit: Gerade bei Software, die mit anderer Software in Laendern mit
anderer Sprache zusammenarbeiten soll - was im Internet bekanntlich
nicht ganz auszuschliessen ist - ist eine gewisse Voraussicht und
Zurueckhaltung angebracht.
>absichtlich [!] einen Steuercode einfügt, von dem er zudem weiß [!], dass
>er als Steuercode interpretiert wird (sei es, um irgendjemanden zu irgend
>etwas zu bewegen, ihn zu belästigen, zu ärgern oder aus sonsteinem Grund)
>macht sich der absichtlichen Irreführung oder Schlimmeren schuldig und
>bewirkt lediglich, dass seine Nachrichten nicht mehr gelesen werden (weil
>sie der Mühe einfach nicht wert sind). Dies gilt insbesondere für
Dass ich keine Steuercodes eingefuegt habe, wurde bereits gesagt.
Dass ich mitunter einen Beitrag dazu zu leisten versuche, jemanden zu
etwas zu bewegen, damit die Welt vielleicht ein wenig besser wird, gebe
ich gerne zu. Belaestigen oder Aergern wollte ich niemanden.
Ich fuehre jedoch ganz sicher niemanden absichtlich in die Irre: Im
Gegenteil, ich bin stets bemueht, genau zu erklaeren, was sich abspielt,
und auch Belege fuer meine Behauptungen anzufuehren.
Schlimmeres als absichtliche Irrefuehrung habe ich hoffentlich auch
nicht begangen.
Dass das eine, kleine "begin end" bewirkt, dass meine Nachrichten nicht
mehr gelesen werden, und wenn allein deshalb, weil Outlook mit plain
text nicht richtig umgehen kann, bewirkt, dass meine Texte die Muehe des
Lesens nicht wert sind, leuchtet mir aber wirklich nicht ein.
>Newsgroupbeiträge von Leuten, die die Kennzeichnung des Attachmentbeginns
>gleich zu Beginn als "begin quoting" einfügen. - Das ist etwa so, also
>würde ich ein End-of-file-Zeichen setzen. Alles, was nach dem Zeichen
Bitte noch um genaue Ausfuehrungen ueber das End-of-file-Zeichen in
einer eMail oder einem Newsgroup-Posting und dessen Auswirkungen. Ich
erwarte, dass uns das zu ein paar interessanten Erkenntnissen ueber
system calls, Libraries (speziell die libc mit ihren strings), ^D (unix),
^Z (CP/M) und andere fuehrt sowie zu deren Verhaeltnis zu dem, was in
diversen Standarddokumenten zu lesen ist.
Eine Nachbemerkung moechte ich noch anbringen, weil ich gar so gemein
zu Mickeysoft bin. Vor allem moechte ich nicht, dass alle jetzt meinen,
sie muessten ihre Windows wegschmeissen weil einer gesagt hat, das ist
eh nur Mist.
Die Pauschalierung "alles von Microsoft ist nur Abfall" ist von der
Wahrheit auf jeden Fall nicht so weit entfernt, wie sie sollte. Dennoch
bleibt es eine Pauschalierung.
Ich gebe auch zu bedenken, dass ich mich noch nicht ueber diverse Unix-
Software geaeussert habe. Als Uebung im Understatement sage ich nur: Die
ist auch nicht immer ganz Fehlerfrei.
"Der freie PC" auf Linux- oder BSD-Basis ist sicher interessant und
ueberlegenswert. Ich habe selbst vor Jahren an der Umstellung eines
Betriebs auf Linux teilgenommen. Zumindest braucht es eine kompetente
Betreuung, damit solch ein Unterfangen gelingt. Heute sind allerdings
alle froh, dass sie ueber Loveletter, Navidad, SirCam, Nimda, Aliz
usw. hoehnisch lachen koennen.
Ob Unix (welcher Farbe auch immer) die bessere Plattform ist, haengt
neben dem persoenlichen Geschmack auch von der Nutzung ab. Ich habe
relativ wenig Probleme, mir einen Source-Code zu nehmen und kleinere
Fehler zu suchen, oder nichtdokumentierten Fragen "an der Quelle"
nachzugehen. Da es in Unix-Umgebungen typischerweise viel oder alles
mit Source-Code gibt, bei Windows aber nicht, kommt letzteres fuer
mich persoenlich nicht in Frage. Fuer Anwender ist dieses Kriterium
wohl weniger relevant, fuer die mag trotz aller Unzulaenglichkeiten
unter Umstaenden Windows die bessere Wahl sein - oder auch ein Mac
("sauteuer, aber es wirkt").
Wenn ich also Microsoft-Produkte in Grund und Boden kritisiere, dann
ist das wohl mit der Perspektive zu vergleichen, die ein Bio-Bauer
haben muesste, wenn er sieht, wie ich mit gestraeubten Haaren in der
Gemuese-Abteilung des Supermarkts traurig auf die gelbgruenden
Paradeiser, die schimmligen Karotten und die voellig geschmacklosen
Mandarinen schaue. Vielleicht sollte ich doch naechsten Samstag
frueher aufstehen und zum Karmelitermarkt schauen?
Schoenes Wochenende,
Alexander Talos
Boris 'pi' Piwinger
> Da gibt es von mir einen Einspruch, und wenn ich dafuer Stempelmarken
> kleben muss.
Das ist jetzt schon das zweite brillante Posting in diesem Thread. Ich
habe mir erlaubt, auf http://piology.org/ILOVEYOU-Signature-FAQ.html
darauf zu linken.
pi
Michael Bauer
> würde ich ein End-of-file-Zeichen setzen. Alles, was nach dem Zeichen
Ist nicht gerade dieses End-of-File zeichen so ein nettes relikt aus
CP/M zeiten, das nur noch auf veralteten Betriebssystemen (WinDOS)
beachtet wird? Sagt mir wenn ich da Falsch liege.
gruss mihi
--
Linux is like a tippy, no windows, no gates and an apache inside
GPG/PGP key availiable @ http://unet.univie.ac.at/~a9900470/mihi.asc
Alexand...@univie.ac.at
In article <3c0653cc$0$38702$3b21...@news.univie.ac.at>, Michael Bauer wrote:
>Ist nicht gerade dieses End-of-File zeichen so ein nettes relikt aus
Wir wissen bisher nicht, welches von den vielen als End of Irgendwas
interpretierten Zeichen gemeint war. Es soll ja sogar Systeme geben,
die bei +++ ein Problem haben (das war mal frueher ein Sport, Pings
mit dieser Sequenz zu verschicken und zuzusehen, wie die Terminal
Server freiwerden).
>CP/M zeiten, das nur noch auf veralteten Betriebssystemen (WinDOS)
>beachtet wird? Sagt mir wenn ich da Falsch liege.
^Z? Jaja, das weckt Erinnerungen an PIP, WordStar und dBase 2. Im
Gegensatz zu seinem Clone ist CP/M aber Open Source:
Allerdings hatte auch CP/M natuerlich keine Probleme mit einem ^Z
beim Schreiben von Files. Es war lediglich eine Konvention, Ascii-
Text mit ^Z enden zu lassen, weil CP/M Files nur blockweise
verwalten konnte und daher die irgendwie der Text vom Verschnitt
bis zur naechsten 128 Byte-Grenze getrennt werden musste.
Ich moechte hinzufuegen, dass bei DOS schon sehr bald (Version 2 war
das, wenn ich mich richtig erinnere) die System Calls vom CP/M-Stil
mit FCB und allem, was gut und teuer ist, durch eine zweite Schiene
ergaenzt wurden. Von mehr oder weniger Anfang an eine inkonsistente
API einzufuehren, war sicher kein designerischer Geniestreich,
obwohl dabei eine um einen Hauch bessere Filesystem Api (an Unix
halbherzig angelehnt) eingefuehrt wurde.
Schoenes Wochenende,
Alexander
Martin Braun
news:3c086b87$0$39476$3b21...@news.univie.ac.at...
> Wir wissen bisher nicht, welches von den vielen als End of Irgendwas
> interpretierten Zeichen gemeint war.
Kein bestimmtes. Sollte nur heißen: Wenn die Datei zu Ende ist, dann
gehört eventuell Folgendes nicht mehr zur Datei.
Grüße,
Martin