Re: [MacAdmin] standard-codierungen für den mail-transfer

Hi Alex,

Du hast mein "Lieblingsthema" angeschnitten ;-)

am 17.10.2001 10:44 Uhr schrieb Alexander Landgraf:

> welche standard-codierungen verwendet ihr bei den datentransfer via mail?

Für reinen Text ISO-8859-1 (Latin1 bzw. "westeuropäisch"). Als Text-Encoding
quoted-printable (das kann man bei manchen eMailern aber eh nicht wählen)

> einmal für den transfer mac->mac und einmal vom mac zum pc??

Ich würde MIME einstellen, dann werden Attachments automatisch mittels
Base64-Kodierung verpackt, so daß sie alle Eventualitäten überstehen.

Für PCs ist das IMO die sauberste Variante. Beim Transfer von Mac zu Mac muß
man halt evtl. darauf achten, daß die Ressource-Fork flöten geht. Ich stuffe
daher zumeist die Dateien vorher (ich nehme hier halt eher Rücksicht auf
potentielle Empfänger der Attachments, die unter Windows arbeiten müssen,
als auf Mac-User, die meistens wissen, was sie zu tun haben ;-).

Alternativ könnte man natürlich auch AppleDouble nehmen. Dabei werden dann
Daten- und Ressource-Zweig separat angehängt. Ein eMail-Client auf dem Mac,
der mit AppleDouble umgehen kann, wird daraus automatisch wieder eine
saubere vollwertige Mac-Datei machen. Windows-User werden anschl. fragen,
warum man ihnen zwei Dateien geschickt hat ;-)

AppleDouble finde ich aber nur in der Spielart okay, wie sie zum Glück die
meisten Mailer auf dem Mac betreiben: die beiden Dateizweige werden
ihrerseits wieder sauber MIME-kodiert, so daß sie auch auf nicht
AppleDouble-fähigen eMail-Clients (halt alle unter Windows bspw. ;-) dafür
sorgen, daß die korrekten Metainformationen bez. MIME-Type ankommen. Ich
habe schon schaurige Beispiele für falsche AppleDouble-Implementationen
gesehen. Mit den Attachments konnten Macs anschließend noch was anfangen.
Aber bei PCs kam nur uninterpretierbarer Datenmüll an...

Anbei mal ein willkürliches Beispiel, wie es aussieht, wenn man in die
Source einer MIME-konformen Mail guckt, die für Attachments AppleDouble
verwendet:

                            ------ 8< ------
   [ Mail-Header ]
   Content-type: multipart/mixed;
      boundary="MS_Mac_OE_3086099428_1269870_MIME_Part"
   
   > Diese Nachricht ist im MIME-Format. Da Ihr Mailreader dieses
     Format nicht unterstützt, könnte diese Nachricht ganz oder
     teilweise unlesbar sein.
   
   --MS_Mac_OE_3086099428_1269870_MIME_Part
   Content-type: text/plain; charset="ISO-8859-1"
   Content-transfer-encoding: quoted-printable
   
   [ Text der Mail]
   
   --MS_Mac_OE_3086099428_1269870_MIME_Part
   Content-type: multipart/appledouble;
      boundary="MS_Mac_OE_3086099424_1267994_MIME_Part"
   
   
   --MS_Mac_OE_3086099424_1267994_MIME_Part
   Content-type: application/applefile; name="internal-roadmap"
   Content-transfer-encoding: base64
   Content-disposition: attachment
   
   [Inhalt der Ressource-Fork]
   
   --MS_Mac_OE_3086099424_1267994_MIME_Part
   Content-type: text/plain; name="internal-roadmap";
    x-mac-creator="522A6368";
    x-mac-type="54455854"
   Content-disposition: attachment
   Content-transfer-encoding: base64
   
   [Inhalt der Data-Fork]
   
   --MS_Mac_OE_3086099424_1267994_MIME_Part--
   
   
   --MS_Mac_OE_3086099428_1269870_MIME_Part--

                            ------ >8 ------

Und jetzt dasselbe nochmals kommentiert.

                            ------ 8< ------

   | [ Mail-Header ]
   | Content-type: multipart/mixed;
   
   Im Header wird die MIME-Boundary (also der Trenner) der obersten
   Hierarchieebene festgelegt:
   
   |    boundary="MS_Mac_OE_3086099428_1269870_MIME_Part"
   | 
   
   Jetzt die MIME-Preamble (OE-typisch falsch, da mit Umlauten!)
   
   | > Diese Nachricht ist im MIME-Format. Da Ihr Mailreader dieses
   |   Format nicht unterstützt, könnte diese Nachricht ganz oder
   |   teilweise unlesbar sein.
   | 
   
   Nun abgetrennt durch die MIME-Boundary der erste Part der Mail, in
   diesem Fall der Text, der im Body der Mail steht. Da ein Charset
   angegeben ist, wird dieser Text auch korrekt unter Windows oder
   UNIX lesbar sein.
   
   | --MS_Mac_OE_3086099428_1269870_MIME_Part
   | Content-type: text/plain; charset="ISO-8859-1"
   | Content-transfer-encoding: quoted-printable
   | 
   | [ Text der Mail]
   | 
   
   Ebenfalls durch die Haupt-Boundary abgetrennt das Attachment als
   AppleDouble:
   
   | --MS_Mac_OE_3086099428_1269870_MIME_Part
   | Content-type: multipart/appledouble;
   
   welches wiederum eine eigenen MIME-Boundary für die beiden Dateizweige
   definiert:
   
   |    boundary="MS_Mac_OE_3086099424_1267994_MIME_Part"
   | 
   | 
   
   Hier nun die Ressource-Fork ("application/applefile" ;-)
   
   | --MS_Mac_OE_3086099424_1267994_MIME_Part
   | Content-type: application/applefile; name="internal-roadmap"
   | Content-transfer-encoding: base64
   | Content-disposition: attachment
   | 
   | [Inhalt der Ressource-Fork]
   | 
   
   Und nun die Data-Fork. Netterweise mit Angabe eines korrekten
   MIME-Types "text/plain", da als "attachment" angehängt ohne
   Encoding (was dazu führen wird, daß alle Nicht-Mac Benutzer mit
   dem angehängten Textfile nicht viel anfangen werden können, da
   Umlaute und Sonderzeichen auf ihren Plattformen hinüber sind!),
   aber unter Beibehaltung von FileType und Creator:
   
   | --MS_Mac_OE_3086099424_1267994_MIME_Part
   | Content-type: text/plain; name="internal-roadmap";
   |  x-mac-creator="522A6368";
   |  x-mac-type="54455854"
   | Content-disposition: attachment
   | Content-transfer-encoding: base64
   | 
   | [Inhalt der Data-Fork]
   | 

   und schließlich werden beide MIME-Parts wieder abgeschlossen
   (abschließende Stricherl "--")

   | --MS_Mac_OE_3086099424_1267994_MIME_Part--
   | 
   | 
   | --MS_Mac_OE_3086099428_1269870_MIME_Part--
   
                           ------ >8 ------

FileType- und Creator werden übrigens von manchen Mac-eMailern immer korrekt
weitergegeben (also auch ohne AppleDouble), da sie den Attachments
mitgegeben werden, wie oben gezeigt: "522A6368" steht für "R*ch" und
"54455854" für "TEXT" --> es handelt sich um eine BBEdit-Datei (es werden
einfach die vierstelligen Type- und Creator-Codes hexadezimal notiert, so
daß sie in achtstelligen wirren Buchstaben-/Zahlenkombinationen enden)

> sind dateinamenerweiterungen absolut notwendig??

Wenn es Richtung PC geht, sollte man sie schon anhängen, denn sonst sind
doofe Rückfragen oder blöde Anmachen garantiert. Wenn bei Dir auf'm Mac das
Kontrollfeld Internet korrekte Settings gespeichert hat, dann wird zwar zu
nahezu jeder gebräuchlichen FileType-/Creator-Kombination (bspw. "PDF " /
"CARO", "TIFF" / "8BIM" , "TEXT" / "vgrd", "TEXT" / "MOSS") auch ein
entsprechender MIME-Type ("application/pdf", "image/tiff",
"application/postscript", "text/html") erzeugt. Diese Zuordnung geht aber
wieder flöten, wenn das Attachment den eMail-Client des Empfängers verläßt,
denn unter Windows heißt es dann wieder nur "wo ist die Extension?" (in
unserem Falle wäre eben ".pdf", ".tif", ".ps" oder ".htm" nötig)

> ps. verschickt wird via outlook-express 5

Der hat in der deutschen Version übrigens einen Lokalisierungsfehler, der
für Ärger sorgen kann (wie fast jede M$-Software).

Die sog. MIME-Preamble, die eMailer anzeigen, wenn sie nicht MIME-konform
sind, enthält Umlaute, d.h. keine reinen ASCII-Zeichen. Das ist aber nicht
spezifikationskonform und manche eMail-Gateways stören sich daran und
schneiden das Attachment einfach ab. Michael Roth hat darauf vor Monaten
schonmal hingewiesen und hier ist es detailliert nachzulesen:

    <http://www.macup.com/titris/2979.html>

Gruss,

Thomas