Falscher Name des Attachments

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Falscher Name des Attachments

    Ich habe eine E-Mail erhalten, dessen Attachment mit TheBat und Outlook unterschiedliche Namen hat. In der abgespeicherten MSG steht :

    Quellcode

    1. Content-Type: application/octet-stream;
    2. name="abc U neu Gel knick.TW3"
    3. Content-Transfer-Encoding: base64
    4. Content-Disposition: attachment;
    5. filename="abc U neu Gel knick.TW3"
    Outlook nutzt den Wert aus 'filename' und The Bat aus 'name'.
    Ich gehe davon aus, dass das ein Fehler von TheBat ist. Oder sehe ich das falsch?

    Der Benutzer hatte übrigens
    User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
    genutzt.
  • Seltsam, dass Thunderbird 52.3 den Anhangsnamen beim Versand so erzeugt. Ich kann es nicht nachstellen.
    Waren vom Sender her im Originatdateinamen irgendwelche Umlaute, Tabzeichen oder Sonderzeiczhen?

    Es ist beim Multipart-Mail-Standard (also bei einem Mix aus Text-/HTML-Mail und anhängen) so, dass filename und name gleich sein sollten.

    The Bat! nimmt den ersten existenten Parameter, um den Namen des Anhangs zu ermitteln. Soweit ich weiß gibt es keien Vorschrift, dass filename oder name zu bevorzugen ist.
    TheBat! Pro 8.x BETA (32bit) • Win 10 Pro x64 • GnuPG 2.2.x • XMP + Regula


    Ich bin Gwendolyn. Wer mich der Drache nennt, bekommt von der Drachin Pratze und Feuer zu spüren.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von GwenDragon ()

  • Ich weiß nicht, wie das Verhältnis zwischen NAME und FILENAME sein sollte, aber im obigen Beispiel müssen die Zeilen richtigerweise so lauten:

    Quellcode

    1. Content-Type: application/octet-stream; name="abc U neu Gel knick.TW3"

    und

    Quellcode

    1. Content-Disposition: attachment; filename="abc U neu Gel knick.TW3"

    Es sind also zwei unterschiedliche Header: "Content-Type" und "Content-Disposition".

    Content-Type ist bekannt und muss in jeder eMail enthalten sein, egal ob mit oder ohne Anhang, HTML oder Text. Dadurch wird der MIME-Typ des Bodys definiert.

    Content-Disposition hingegen ist laut Wiki ein nicht standardisierter und sogar als gefährlich eingestufter Header, mit dem der Server für bestimmte MIME-Typen Downloadfenster erzeugen und einen Dateinamen vorschlagen kann.

    application/octet-stream soll wiederum laut Wiki zum Speichern der Daten führen und ausdrücklich nicht zum Starten eines Anwendungsprogramms. Ich nehme an, dass wenn dieser MIME-Typ verwendet wird, auch automatisch der Header "Content-Disposition" eingetragen wird bzw. sogar werden muss.

    Vielleicht kann Thunderbird damit nicht sehr gut umgehen und hat deswegen den Dateinamen falsch eingetragen. Und beim Öffnen arbeitet Outlook wohl mit dem Header "Content-Disposition", während TB! es mit "Content-Type" tut. TB! ist ja bekanntlich sehr streng im Hinblick auf Anhänge (vgl. z.B. "Benutzereinstellungen | Anlagensicherheit") und wird wahrscheinlich nicht einfach so irgendwelche Downloadfenster zulassen.
  • sanyok schrieb:

    Content-Disposition hingegen ist laut Wiki ein nicht standardisierter und sogar als gefährlich eingestufter Header, mit dem der Server für bestimmte MIME-Typen Downloadfenster erzeugen und einen Dateinamen vorschlagen kann.

    "Wiki" meinte bei meinem Vorredner de.Wikimedia.org
    Das bezieht sich auf die Verwendung von "content-disposition" im HTTP-Header, was in RFC 6266 diskutiert wird.

    Verwendung von Content-Disposition kann ich mir bei interaktiven HTTP-Anwendungen auch nicht wirklich vorstellen; das gehört in Mail, und das ist dann beschrieben in RFC 2183 Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field, vom August 1997.

    Darin heißt es zum Parameter "filename":

    RFC 2183 schrieb:

    2.3 The Filename Parameter The sender may want to suggest a filename to be used if the entity is detached and stored in a separate file. If the receiving MUA writes the entity to a file, the suggested filename should be used as a basis for the actual filename, where possible. It is important that the receiving MUA not blindly use the suggested filename. The suggested filename SHOULD be checked (and possibly changed) to see that it conforms to local filesystem conventions, does not overwrite an existing file, and does not present a security problem (see Security Considerations below). The receiving MUA SHOULD NOT respect any directory path information that may seem to be present in the filename parameter. The filename should be treated as a terminal component only. Portable specification of directory paths might possibly be done in the future via a separate Content-Disposition parameter, but no provision is made for it in this draft.

    [es folgen 2 Absätze bezüglich Zeichensatz des Dateinamens, und:]

    RFC 2183 schrieb:

    The presence of the filename parameter does not force an implementation to write the entity to a separate file. It is perfectly acceptable for implementations to leave the entity as part of the normal mail stream unless the user requests otherwise. As a consequence, the parameter may be used on any MIME entity, even `inline' ones. These will not normally be written to files, but the parameter could be used to provide a filename if the receiving user should choose to write the part to a file.Zu möglichen Gefahren durch diesen Header schließlich die 5. Security Considerations There are security issues involved any time users exchange data. While these are not to be minimized, neither does this memo change the status quo in that regard, except in one instance. Since this memo provides a way for the sender to suggest a filename, a receiving MUA must take care that the sender's suggested filename does not represent a hazard. Using UNIX as an example, some hazards would be: + Creating startup files (e.g., ".login"). + Creating or overwriting system files (e.g., "/etc/passwd"). + Overwriting any existing file. + Placing executable files into any command search path (e.g., "~/bin/more"). + Sending the file to a pipe (e.g., "| sh"). In general, the receiving MUA should not name or place the file such that it will get interpreted or executed without the user explicitly initiating the action. It is very important to note that this is not an exhaustive list; it is intended as a small set of examples only. Implementors must be alert to the potential hazards on their target systems.
  • DT5 schrieb:

    Ich habe eine E-Mail erhalten, dessen Attachment mit TheBat und Outlook unterschiedliche Namen hat. In der abgespeicherten MSG steht :

    Quellcode

    1. Content-Type: application/octet-stream;
    2. name="abc U neu Gel knick.TW3"
    3. Content-Transfer-Encoding: base64
    4. Content-Disposition: attachment;
    5. filename="abc U neu Gel knick.TW3"
    Outlook nutzt den Wert aus 'filename' und The Bat aus 'name'.
    Ich gehe davon aus, dass das ein Fehler von TheBat ist. Oder sehe ich das falsch?


    Ich sehe das auch so. Wobei ich als einzigen Unterschied zwischen dem name-Parameter zum Content-Type und dem filename-Parameter zum Content-Disposition darin sehe, daß letzterer ein paar mehr Leerzeichen zwischen dem "U" und dem "neu" hat.

    Ich kann übrigens in der ursprünglichen Definition der MIME-Header in RFC 2045 "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies" keinen Parameter "name" zu dem Header "Content-Type" finden und in den Updates zu diesem RFC (RFC 2231 und RFC 6532) auch nicht.

    Während ich Benennungen von Objekten zur Identifizierung eigentlich gut finde, weiß ich nicht, wer diesen Namen eines Body Parts einer MIME-Message referenzieren sollte. Wenn z.B. ein Bild in einem anderem Body Part gezeigt werden soll, dann hat das Bild eine CID, d.h. eine Content-ID, die in dem referenzierenden Body Part verwendet wird.
  • GwenDragon schrieb:


    Es ist beim Multipart-Mail-Standard (also bei einem Mix aus Text-/HTML-Mail und anhängen) so, dass filename und name gleich sein sollten.


    Wo wäre das festgelegt? Ich habe auf meiner Suche zum Header "Content-Type" keinen Parameter "name" gefunden, wie ich weiter oben geschrieben hatte. Und wenn, dann würde der nur diesem spezifischen Body Part einen Namen geben, aber keinen Dateinamen spezifizieren, unter dem dieser Bodypart auf den Massenspeicher des empfangenden Rechners gespeichert werden sollte.

    GwenDragon schrieb:


    The Bat! nimmt den ersten existenten Parameter, um den Namen des Anhangs zu ermitteln. Soweit ich weiß gibt es keien Vorschrift, dass filename oder name zu bevorzugen ist.


    Abgesehen, daß es diesen Parameter "name" nicht gibt (zumindest hab ich den nicht gefunden), wird beim RFC 2183 "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field" ja lang und breit dargelegt, daß und wie der Parameter "filename" zu verwenden ist.

    Wer macht den Eintrag im bt.ritlabs?
  • L.Willms schrieb:

    "Wiki" meinte bei meinem Vorredner de.Wikimedia.org
    Nicht Wikimedia, sondern Wikipedia. Ich hab's ja verlinkt.


    L.Willms schrieb:

    Wenn The Bat! stattdessen den "filename" aus dem Content-Type Header verwendet, ist das ein Fehler.
    Gesetzt in den Header wurde das aber nicht von TB!, sondern vom Absender, hier wohl von Thunderbird. Zudem hat Thunderbird den Dateinamen falsch eingetragen.


    L.Willms schrieb:

    Ich kann übrigens in der ursprünglichen Definition der MIME-Header in RFC 2045 "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies" keinen Parameter "name" zu dem Header "Content-Type" finden und in den Updates zu diesem RFC (RFC 2231 und RFC 6532) auch nicht.
    Dann handeln wohl viele MUAs nicht RFC-konform, denn wiederum bei Wiki(pedia) gibt's einen Auszug aus einer PGP/MIME-kodierten Nachricht, in der man ebenfalls Content-Type: application/octet-stream; name="encrypted.asc" im Header sieht. Im Internet findet man weitere Bespiele. Wahrscheinlich ist "name" bei Content-Type: application/octet-stream zumindest üblich, wenn nicht standardisiert.
  • Meinen Fehler seh ich erst im Zitat:
    Wenn The Bat! stattdessen den "filename" aus dem Content-Type Header verwendet, ist das ein Fehler.


    Gemeint ist natürlich der Parameter "name" aus dem Header Content-Type. Einen "filename" gibt es dort ja auch nicht.

    Was diesen Parameter angeht, hab ich vorsichtigerweise geschrieben, daß ich den nicht gefunden habe. Damit ist nicht bewiesen, daß der nicht doch in irgendeinem RFC auftaucht, sondern nur, daß ich den nicht gesehen habe. Man kann Abwesenheit von etwas eigentlich so gut wie nicht beweisen.

    Also wenn jemand einen RFC auftun kann, wo dem Header "Content-Type" ein Parameter "Name" zugeordnet wird, wäre meine Behauptung falsifiziert.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von L.Willms ()

  • Was diese Mixtur der Header bei MIME-Multipart-Mail anbelangt, bestehend aus aus Content-Type und Content-Disposition, liegt das vielleicht an irgendeinem Kompatibilitätskram mit älteren MS- oder Linux- oder Mac-Programmen oder anderen Webmail-/Mail-Clients.
    Aber so ganz sicher weiß ich das nicht mehr.
    TheBat! Pro 8.x BETA (32bit) • Win 10 Pro x64 • GnuPG 2.2.x • XMP + Regula


    Ich bin Gwendolyn. Wer mich der Drache nennt, bekommt von der Drachin Pratze und Feuer zu spüren.
  • The Bat! kann bei mir auch mit Mails umgehen, die Anhänge so eingebunden haben.

    Quellcode

    1. Content-Type: image/png
    2. Content-Disposition: attachment; filename=perl.png
    Logisch ist ja MIME-Standard.

    //EDIT:
    Der Header Content-Disposition und Content-Type mit Anhangsnamen existiert bei durch iPhone als auch bei diversen Androiden erzeugten Mails mit Anhängen.
    Ich hatte da ein paar Mails.
    TheBat! Pro 8.x BETA (32bit) • Win 10 Pro x64 • GnuPG 2.2.x • XMP + Regula


    Ich bin Gwendolyn. Wer mich der Drache nennt, bekommt von der Drachin Pratze und Feuer zu spüren.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von GwenDragon ()