Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comm.software.mailreader > #282 > unrolled thread

8bit-Dateinamen Umwandlung

Back to article view | Back to de.comm.software.mailreader

Contents

  8bit-Dateinamen Umwandlung christian_dcsm-ENTF@soemtron.de (Christian @Soemtron) - 2017-08-03 14:00 +0200
    Re: 8bit-Dateinamen Umwandlung Michael Bäuerle <michael.baeuerle@stz-e.de> - 2017-08-03 14:50 +0200
      Re: 8bit-Dateinamen Umwandlung Michael Bäuerle <michael.baeuerle@stz-e.de> - 2017-08-03 16:41 +0200
        Re: 8bit-Dateinamen Umwandlung christian_dcsm-ENTF@soemtron.de (Christian @Soemtron) - 2017-08-04 11:46 +0200
          Re: 8bit-Dateinamen Umwandlung Michael Bäuerle <michael.baeuerle@gmx.net> - 2017-08-06 21:05 +0000

#282 — 8bit-Dateinamen Umwandlung

Hi,

mein Lieblings-Mail-Programm hat seit Jahren eine Wahlmöglichkeit zur  
"8bit-Dateinamen Umwandlung". Die seither unveränderte Einstellung ist:

[x] MIME (obwohl nicht RFC2047 konform, es ist am meisten verbreitet)
[ ] RFC2231 (RFC konform, aber nicht alle Mailer unterstützen dieses Format)
[ ] Raw (Dateiname wird unter Umständen nicht richtig im Internet übertragen)

Stimmt das noch so oder ist das überholt? Nach den Jahren könnte ich mir  
vorstellen, daß "RFC2231" sinnvoller wäre, habe davon aber wenig Ahnung.
Wie macht es z.B. Thunderbird oder andere gängige Software - kann man das  
dort überhaupt einstellen?

cu,
Christian

PGP Key available.

[toc] | [next] | [standalone]

#283

Christian @Soemtron wrote:
> 
> mein Lieblings-Mail-Programm hat seit Jahren eine Wahlmöglichkeit zur  
> "8bit-Dateinamen Umwandlung". Die seither unveränderte Einstellung ist:
> 
> [x] MIME (obwohl nicht RFC2047 konform, es ist am meisten verbreitet)
> [ ] RFC2231 (RFC konform, aber nicht alle Mailer unterstützen dieses Format)
> [ ] Raw (Dateiname wird unter Umständen nicht richtig im Internet übertragen)
> 
> Stimmt das noch so oder ist das überholt? Nach den Jahren könnte ich mir  
> vorstellen, daß "RFC2231" sinnvoller wäre, habe davon aber wenig Ahnung.
> Wie macht es z.B. Thunderbird oder andere gängige Software - kann man das  
> dort überhaupt einstellen?

Ich kann deine Frage nicht beantworten, aber ich finde obige Auswahl
irreführend: RFC 2231 gehört zur MIME Definition genau wie RFC 2047
(und auch RFC 2045, 2046, 2048 und 2049).

Wenn der Punkt 1 nicht MIME-konform ist, warum heißt er dann "MIME"?
Eigentlich wäre dann vermutlich Punkt 2 das MIME-konforme Verhalten.

[toc] | [prev] | [next] | [standalone]

#284

Ingrid wrote:
> Christian @Soemtron wrote:
> > 
> > mein Lieblings-Mail-Programm hat seit Jahren eine Wahlmöglichkeit zur  
> > "8bit-Dateinamen Umwandlung". Die seither unveränderte Einstellung ist:
> > 
> > [x] MIME (obwohl nicht RFC2047 konform, es ist am meisten verbreitet)
> > [ ] RFC2231 (RFC konform, aber nicht alle Mailer unterstützen dieses Format)
> > [ ] Raw (Dateiname wird unter Umständen nicht richtig im Internet übertragen)
> > 
> > Stimmt das noch so oder ist das überholt? Nach den Jahren könnte ich mir  
> > vorstellen, daß "RFC2231" sinnvoller wäre, habe davon aber wenig Ahnung.
> > Wie macht es z.B. Thunderbird oder andere gängige Software - kann man das  
> > dort überhaupt einstellen?
> 
> Ich kann deine Frage nicht beantworten, [...]

Ich habe mir ein Testfile schicken lassen.

Apple Mail und Mozilla machen mit "täst.txt" als Anhang so was in der
Art hier (das Beispiel stammt von Thunderbird):
| 
| --------------DA8345C20CA3C44BE9BB4AC5
| Content-Type: text/plain; charset=UTF-8;
|  name="=?UTF-8?B?dMOkc3QudHh0?="

Das ist kaputt und war AFAIK seit der ersten MIME Norm von 1992 so
nie erlaubt.

Für andere Content-Types hatte früher z.B. RFC 1341 einen Parameter
"NAME" vorgesehen, in den aktuellen Normen gibt es den auch dort nicht
mehr.

| [...]
| Content-Disposition: attachment;
|  filename*=utf-8''%74%C3%A4%73%74%2E%74%78%74

So ist es seit 20 Jahren genormt (gemäß den MIME-Normen RFC 2183 und
RFC 2231):
<https://tools.ietf.org/html/rfc2183>
<https://tools.ietf.org/html/rfc2231>

[toc] | [prev] | [next] | [standalone]

#285

Michael Bäuerle <michael.baeuerle@stz-e.de> schrieb:

> Ich kann deine Frage nicht beantworten, aber ich finde obige
> Auswahl irreführend: RFC 2231 gehört zur MIME Definition genau wie
> RFC 2047 (und auch RFC 2045, 2046, 2048 und 2049).

danke, Wie wären denn passendere Formulierungen für die Optionen?

> | [...]
> | Content-Disposition: attachment;
> |  filename*=utf-8''%74%C3%A4%73%74%2E%74%78%74

> So ist es seit 20 Jahren genormt (gemäß den MIME-Normen RFC 2183
> und RFC 2231):

Hier das Ergebnis jeweils mit Datei "Ölfaß.txt":

========== "MIME" ========================================================

Content-Transfer-Encoding: 7bit

--------_boundary
Content-Type: application/octet-stream;
 name="=?ISO-8859-1?Q?=D6lfa=DF=2Etxt?="
Content-Disposition: attachment;
 filename="=?ISO-8859-1?Q?=D6lfa=DF=2Etxt?="

========== "RFC2231" =====================================================

Content-Transfer-Encoding: 7bit

--------_boundary
Content-Type: application/octet-stream;
 name*=iso-8859-1''%D6lfa%DF%2Etxt
Content-Disposition: attachment;
 filename*=iso-8859-1''%D6lfa%DF%2Etxt

========== "Raw" =========================================================

Content-Transfer-Encoding: 8bit

--------_boundary
Content-Type: application/octet-stream;
 name*=iso-8859-1''%D6lfa%DF%2Etxt
Content-Disposition: attachment;
 filename*=iso-8859-1''%D6lfa%DF%2Etxt

===========================================================================

Es bleibt die Frage, mit welcher Variante man mit weniger Problemen auf  
Empfängerseite rechnen muß: #1 oder #2. Nach 20 Jahren könnte man ja fast  
annehmen, daß sich der Standard flächendeckend durchgesetzt hat.

#3 unterscheidet sich von #2 nur durch "Content-Transfer-Encoding: 8bit"  
im Haupt-Header. Was könnte das mit den Dateinamen zu tun haben?

Davon abgesehen: von 8bit-Codierung meine ich gelesen zu haben, daß das  
zwar "moderner" und Standard, aber in seltenen Fällen dann doch mal  
problematisch ist. Da gehe ich lieber auf Nummer sicher, der Empfänger  
kann ja nichts für evtl. zwischenliegende veraltete Software.

cu,
Christian

PGP Key available.

[toc] | [prev] | [next] | [standalone]

#286

Christian @Soemtron wrote:
> Michael Bäuerle <michael.baeuerle@stz-e.de> schrieb:
> > 
> > Ich kann deine Frage nicht beantworten, aber ich finde obige
> > Auswahl irreführend: RFC 2231 gehört zur MIME Definition genau wie
> > RFC 2047 (und auch RFC 2045, 2046, 2048 und 2049).
> 
> danke, Wie wären denn passendere Formulierungen für die Optionen?
> 
> > | [...]
> > | Content-Disposition: attachment;
> > |  filename*=utf-8''%74%C3%A4%73%74%2E%74%78%74
> 
> > So ist es seit 20 Jahren genormt (gemäß den MIME-Normen RFC 2183
> > und RFC 2231):
> 
> Hier das Ergebnis jeweils mit Datei "Ölfaß.txt":
> 
> ========== "MIME" ========================================================
> 
> Content-Transfer-Encoding: 7bit
> 
> --------_boundary
> Content-Type: application/octet-stream;
>  name="=?ISO-8859-1?Q?=D6lfa=DF=2Etxt?="
> Content-Disposition: attachment;
>  filename="=?ISO-8859-1?Q?=D6lfa=DF=2Etxt?="
> 
> ========== "RFC2231" =====================================================
> 
> Content-Transfer-Encoding: 7bit
> 
> --------_boundary
> Content-Type: application/octet-stream;
>  name*=iso-8859-1''%D6lfa%DF%2Etxt
> Content-Disposition: attachment;
>  filename*=iso-8859-1''%D6lfa%DF%2Etxt
> 
> ========== "Raw" =========================================================
> 
> Content-Transfer-Encoding: 8bit
> 
> --------_boundary
> Content-Type: application/octet-stream;
>  name*=iso-8859-1''%D6lfa%DF%2Etxt
> Content-Disposition: attachment;
>  filename*=iso-8859-1''%D6lfa%DF%2Etxt
> 
> ===========================================================================
> 
> Es bleibt die Frage, mit welcher Variante man mit weniger Problemen auf  
> Empfängerseite rechnen muß: #1 oder #2. Nach 20 Jahren könnte man ja fast  
> annehmen, daß sich der Standard flächendeckend durchgesetzt hat.

Ja, ich würde deswegen Einstellung #2 als Standardeinstellung
verwenden - zumindest solange sich kein Empfänger beschwert.
Variante 1 ist kaputt, sowas sollte man nicht versenden.

Das potentielle Problem auf Empfängerseite würde sich auch in Grenzen
halten: Der betreffende Anhang würde korrekt transportiert werden, nur
eben der Dateiname nicht. Ein Empfänger mit kaputter Software könnte
trotzdem von Hand einen Namen vergeben und die Datei danach verwenden.

> #3 unterscheidet sich von #2 nur durch "Content-Transfer-Encoding: 8bit"  
> im Haupt-Header. Was könnte das mit den Dateinamen zu tun haben?

Ich denke nichts. "Content-Transfer-Encoding" bezieht sich ja nur auf
den Body, der Dateiname wird aber im Header übertragen.

> Davon abgesehen: von 8bit-Codierung meine ich gelesen zu haben, daß das  
> zwar "moderner" und Standard, aber in seltenen Fällen dann doch mal  
> problematisch ist. Da gehe ich lieber auf Nummer sicher, der Empfänger  
> kann ja nichts für evtl. zwischenliegende veraltete Software.

Das originale SMTP-Protokoll konnte nur 7bit Daten transportieren.
Das sollte daher überall durchgehen, ohne dass eine Konvertierung
erforderlich wäre.
Sogesehen ist 7bit die konservative Variante. Da sie völlig MIME-konform
ist, besteht eigentlich kein Grund daran etwas zu ändern.

USENET ist ein anderer Fall: NNTP konnte schon immer 8bit Daten
transportieren, deswegen macht 7bit als Standardeinstellung bei
einem Newsreader wenig Sinn.

Bei kombinierten Progammen würde ich den Mail-Teil auf 7bit und den
News-Teil auf 8bit konfigurieren.

[toc] | [prev] | [standalone]

Back to top | Article view | de.comm.software.mailreader

csiph-web