info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Anhang - Datei mit Umlauten
45 views
Skip to first unread message
Gerhard Zahn
Sep 7, 2020, 2:35:04 AM9/7/20
to
Hallo in die Runde,
wer auch immer mir einen Dateianhang mit einem Umlaut im Dateinamen
schickt, der Anhang kommt wohlbehalten bei mir an und lässt sich
öffnen.
Beim Versand eines Anhangs mit Umlaut oder Sonderzeichen ist das
leider nicht so.
Als Test habe ich einen Dateianhang mit Umlaut an mich selbst
versandt.
Nach Eingang des Anhangs (in diesem Fall ein doc) enthält dieser nur
kryptischen Zeichensalat.
Bei einem gleichen Test mit einer jpg-Datei mit Umlaut im Dateinamen
erschien nach Eingang "[Invalid or unknown image typ]"
Also scheint es auf der Ausgangsseite des Agent ein Problem zu geben.
Ist an meinem Agent 5 etwas falsch eingestellt? Ist das reparabel?
Bin für jede Hilfe dankbar.
Beste Grüße
G. Zahn
wer auch immer mir einen Dateianhang mit einem Umlaut im Dateinamen
schickt, der Anhang kommt wohlbehalten bei mir an und lässt sich
öffnen.
Beim Versand eines Anhangs mit Umlaut oder Sonderzeichen ist das
leider nicht so.
Als Test habe ich einen Dateianhang mit Umlaut an mich selbst
versandt.
Nach Eingang des Anhangs (in diesem Fall ein doc) enthält dieser nur
kryptischen Zeichensalat.
Bei einem gleichen Test mit einer jpg-Datei mit Umlaut im Dateinamen
erschien nach Eingang "[Invalid or unknown image typ]"
Also scheint es auf der Ausgangsseite des Agent ein Problem zu geben.
Ist an meinem Agent 5 etwas falsch eingestellt? Ist das reparabel?
Bin für jede Hilfe dankbar.
Beste Grüße
G. Zahn
Manfred Polak
Sep 7, 2020, 7:34:35 AM9/7/20
to
Gerhard Zahn schrieb:
>Beim Versand eines Anhangs mit Umlaut oder Sonderzeichen ist das
>leider nicht so.
>Als Test habe ich einen Dateianhang mit Umlaut an mich selbst
>versandt.
>Nach Eingang des Anhangs (in diesem Fall ein doc) enthält dieser nur
>kryptischen Zeichensalat.
Das ist anscheinend der Inhalt als base64 codiert.
>Also scheint es auf der Ausgangsseite des Agent ein Problem zu geben.
>Ist an meinem Agent 5 etwas falsch eingestellt? Ist das reparabel?
Wenn Du beim Auswählen des Anhangs bei "Placement" nicht "Attachment",
sondern "Inline MIME section" wählst, sollte es funktionieren. Ob das
ein Bug von Agent ist, weiß ich auf Anhieb nicht. Da müsste ich erst in
den einschlägigen MIME-RFCs nachlesen.
Manfred
>Beim Versand eines Anhangs mit Umlaut oder Sonderzeichen ist das
>leider nicht so.
>Als Test habe ich einen Dateianhang mit Umlaut an mich selbst
>versandt.
>Nach Eingang des Anhangs (in diesem Fall ein doc) enthält dieser nur
>kryptischen Zeichensalat.
>Also scheint es auf der Ausgangsseite des Agent ein Problem zu geben.
>Ist an meinem Agent 5 etwas falsch eingestellt? Ist das reparabel?
sondern "Inline MIME section" wählst, sollte es funktionieren. Ob das
ein Bug von Agent ist, weiß ich auf Anhieb nicht. Da müsste ich erst in
den einschlägigen MIME-RFCs nachlesen.
Manfred
Manfred Polak
Sep 7, 2020, 9:46:23 AM9/7/20
to
Gerhard Zahn schrieb:
>Also scheint es auf der Ausgangsseite des Agent ein Problem zu geben.
Nö, doch nicht. Ich hab mir das ganze nochmal genauer angesehen und
gefunden, dass Agent nichts damit zu tun hat. Denn wenn so eine Mail
meinen Agent verlassen hat, aber noch in meinem lokalen Mailserver
Mailtraq liegt, ist sie noch in Ordnung. Erst wenn sie die Runde über
GMX zurück zu mir gemacht hat, ist sie kaputt (und Mailtraq hat nichts
damit zu tun). Deshalb hab ich mal versuchsweise Agent so konfiguriert,
dass er Mails direkt über den SMTP-Server meines Providers statt über
GMX verschickt, und damit kam eine Testmail mit Umlaut im Dateinamen
intakt wieder bei mir an. Damit ist offenbar GMX der Schuldige, und
zwar der SMTP-Server, nicht der POP3- oder IMAP-Server.
Der Unterschied besteht nur aus einer gelöschten Zeile. Wenn so eine
Mail in Mailtraq auf den Versand wartet, dann stehen die vollständigen
MIME-Angaben drin, nach dem Durchgang bei GMX fehlt dagegen die
Zeile mit dem Content-Transfer-Encoding. Das ist unabhängig davon,
ob es im Header oder (bei Multipart-Messages) im Body-Header passiert.
In beiden Fällen kann dann der Inhalt beim Empfänger nicht mehr korrekt
decodiert und angezeigt werden. Die Zeile wird aber anscheinend nur
gelöscht, wenn als Content-Disposition "attachment" angegeben ist.
Wenn da "inline" steht, wird nach meinen bisherigen Erkenntnissen die
Mail in Ruhe gelassen, und deshalb funktioniert der Workaround mit
"Inline MIME section" in Agent.
Je nachdem, ob das Absicht, eine Fehlkonfiguration bei GMX oder ein
Bug in der Serversoftware ist, könnten auch andere Provider betroffen
sein. Aber das müssten andere Leute testen. Ich werd jetzt auch mal
bei GMX nachfragen.
Manfred
>Also scheint es auf der Ausgangsseite des Agent ein Problem zu geben.
gefunden, dass Agent nichts damit zu tun hat. Denn wenn so eine Mail
meinen Agent verlassen hat, aber noch in meinem lokalen Mailserver
Mailtraq liegt, ist sie noch in Ordnung. Erst wenn sie die Runde über
GMX zurück zu mir gemacht hat, ist sie kaputt (und Mailtraq hat nichts
damit zu tun). Deshalb hab ich mal versuchsweise Agent so konfiguriert,
dass er Mails direkt über den SMTP-Server meines Providers statt über
GMX verschickt, und damit kam eine Testmail mit Umlaut im Dateinamen
intakt wieder bei mir an. Damit ist offenbar GMX der Schuldige, und
zwar der SMTP-Server, nicht der POP3- oder IMAP-Server.
Der Unterschied besteht nur aus einer gelöschten Zeile. Wenn so eine
Mail in Mailtraq auf den Versand wartet, dann stehen die vollständigen
MIME-Angaben drin, nach dem Durchgang bei GMX fehlt dagegen die
Zeile mit dem Content-Transfer-Encoding. Das ist unabhängig davon,
ob es im Header oder (bei Multipart-Messages) im Body-Header passiert.
In beiden Fällen kann dann der Inhalt beim Empfänger nicht mehr korrekt
decodiert und angezeigt werden. Die Zeile wird aber anscheinend nur
gelöscht, wenn als Content-Disposition "attachment" angegeben ist.
Wenn da "inline" steht, wird nach meinen bisherigen Erkenntnissen die
Mail in Ruhe gelassen, und deshalb funktioniert der Workaround mit
"Inline MIME section" in Agent.
Je nachdem, ob das Absicht, eine Fehlkonfiguration bei GMX oder ein
Bug in der Serversoftware ist, könnten auch andere Provider betroffen
sein. Aber das müssten andere Leute testen. Ich werd jetzt auch mal
bei GMX nachfragen.
Manfred
Gerhard Zahn
Sep 7, 2020, 12:57:35 PM9/7/20
to
Am Mon, 07 Sep 2020 13:34:26 +0200 schrieb Manfred Polak:
Hallo Manfred,
danke für deine Mail.
Leider komme ich als Laie noch nicht ganz ans Ziel.
>Also scheint es auf der Ausgangsseite des Agent ein Problem zu geben.
>Ist an meinem Agent 5 etwas falsch eingestellt? Ist das reparabel?
>
>Wenn Du beim Auswählen des Anhangs bei "Placement" nicht "Attachment",
>sondern "Inline MIME section" wählst, sollte es funktionieren.
Und unter Folder > Properties bzw. Default Properties > Posting
messages > Email Attachments steht bei mir jetzt:
Format: Mime
und darunter Attachment Placement: Inline MIME section
Jetzt werden Anhänge mit Umlaut im Dateinamen korrekt versandt, bis
auf eines:
Beim Empfänger wird zwar die Dateigröße der Anlage angezeigt,
aaaaber: weder der Dateiname noch der Dateityp wird mit mitübertragen.
Lässt sich auch das korrigieren?
Beste Grüße
Gerhard
Hallo Manfred,
danke für deine Mail.
Leider komme ich als Laie noch nicht ganz ans Ziel.
>Also scheint es auf der Ausgangsseite des Agent ein Problem zu geben.
>Ist an meinem Agent 5 etwas falsch eingestellt? Ist das reparabel?
>
>Wenn Du beim Auswählen des Anhangs bei "Placement" nicht "Attachment",
>sondern "Inline MIME section" wählst, sollte es funktionieren.
messages > Email Attachments steht bei mir jetzt:
Format: Mime
und darunter Attachment Placement: Inline MIME section
Jetzt werden Anhänge mit Umlaut im Dateinamen korrekt versandt, bis
auf eines:
Beim Empfänger wird zwar die Dateigröße der Anlage angezeigt,
aaaaber: weder der Dateiname noch der Dateityp wird mit mitübertragen.
Lässt sich auch das korrigieren?
Beste Grüße
Gerhard
Manfred Polak
Sep 7, 2020, 1:00:45 PM9/7/20
to
Ich schrieb:
>Ich werd jetzt auch mal bei GMX nachfragen.
Ts, die Sitten im Internet verlottern. Ich hab an postm...@gmx.de
gemailt, wie man das halt (eigentlich) so macht, wenn es um Probleme
mit Mail geht. Aber als Antwort kam nur ein automatischer Textbaustein:
| Sehr geehrte Damen und Herren,
|
| Ihre Anfrage kann unter dieser E-Mail-Adresse leider nicht bearbeitet
| werden. Hilfe und weitere Unterstützung zu Postmaster-Fragen erhalten
| Sie unter
|
| http://postmaster.gmx.de
|
| Für Ihr Verständnis vielen Dank.
Welches Verständnis? Aber ich hab dann natürlich den Link angeklickt
und bekam diesmal als Reaktion im Browser:
| Failed to Connect
|
| The connection was refused when attempting to contact postmaster.gmx.de.
Diese Pfeifen sind also auch zu doof, den richtigen Link in ihre
Textbausteine zu setzen. Aber da steht ja http, also hab ich es mal
mit https versucht. Da kam dann auch was, allerdings weder ein
Kontaktformular noch eine Mailadresse. An diesem Punkt wurde
es mir zu blöd, und ich habe den Kontaktversuch abgebrochen.
Manfred
>Ich werd jetzt auch mal bei GMX nachfragen.
gemailt, wie man das halt (eigentlich) so macht, wenn es um Probleme
mit Mail geht. Aber als Antwort kam nur ein automatischer Textbaustein:
| Sehr geehrte Damen und Herren,
|
| Ihre Anfrage kann unter dieser E-Mail-Adresse leider nicht bearbeitet
| werden. Hilfe und weitere Unterstützung zu Postmaster-Fragen erhalten
| Sie unter
|
| http://postmaster.gmx.de
|
| Für Ihr Verständnis vielen Dank.
Welches Verständnis? Aber ich hab dann natürlich den Link angeklickt
und bekam diesmal als Reaktion im Browser:
| Failed to Connect
|
| The connection was refused when attempting to contact postmaster.gmx.de.
Diese Pfeifen sind also auch zu doof, den richtigen Link in ihre
Textbausteine zu setzen. Aber da steht ja http, also hab ich es mal
mit https versucht. Da kam dann auch was, allerdings weder ein
Kontaktformular noch eine Mailadresse. An diesem Punkt wurde
es mir zu blöd, und ich habe den Kontaktversuch abgebrochen.
Manfred
Henning Sponbiel
Sep 7, 2020, 2:13:53 PM9/7/20
to
On Mon, 07 Sep 2020 19:00:37 +0200, Manfred Polak wrote:
>Ich schrieb:
>
>>Ich werd jetzt auch mal bei GMX nachfragen.
>
>Ts, die Sitten im Internet verlottern. Ich hab an postm...@gmx.de
>gemailt, wie man das halt (eigentlich) so macht, wenn es um Probleme
>mit Mail geht. Aber als Antwort kam nur ein automatischer Textbaustein:
>
>| Sehr geehrte Damen und Herren,
>|
>| Ihre Anfrage kann unter dieser E-Mail-Adresse leider nicht bearbeitet
>| werden. Hilfe und weitere Unterstützung zu Postmaster-Fragen erhalten
>| Sie unter
>|
>| http://postmaster.gmx.de
>|
>| Für Ihr Verständnis vielen Dank.
>
>Welches Verständnis? Aber ich hab dann natürlich den Link angeklickt
>und bekam diesmal als Reaktion im Browser:
>
>| Failed to Connect
>|
>| The connection was refused when attempting to contact postmaster.gmx.de.
Hier (mit Firefox 80.0.1) kein Problem (gegen 20:00 Uhr, wenn das was
>Ich schrieb:
>
>>Ich werd jetzt auch mal bei GMX nachfragen.
>
>Ts, die Sitten im Internet verlottern. Ich hab an postm...@gmx.de
>gemailt, wie man das halt (eigentlich) so macht, wenn es um Probleme
>mit Mail geht. Aber als Antwort kam nur ein automatischer Textbaustein:
>
>| Sehr geehrte Damen und Herren,
>|
>| Ihre Anfrage kann unter dieser E-Mail-Adresse leider nicht bearbeitet
>| werden. Hilfe und weitere Unterstützung zu Postmaster-Fragen erhalten
>| Sie unter
>|
>| http://postmaster.gmx.de
>|
>| Für Ihr Verständnis vielen Dank.
>
>Welches Verständnis? Aber ich hab dann natürlich den Link angeklickt
>und bekam diesmal als Reaktion im Browser:
>
>| Failed to Connect
>|
>| The connection was refused when attempting to contact postmaster.gmx.de.
hilft).
Henning
Manfred Polak
Sep 7, 2020, 3:41:34 PM9/7/20
to
Henning Sponbiel schrieb:
>>| http://postmaster.gmx.de
gewechselt ist?
Manfred
>>| http://postmaster.gmx.de
>>|
>>| Failed to Connect
>>|
>>| The connection was refused when attempting to contact postmaster.gmx.de.
>
>Hier (mit Firefox 80.0.1) kein Problem (gegen 20:00 Uhr, wenn das was
>hilft).
Und Du bist sicher, dass Firefox dabei nicht stillschweigend zu https
>>| Failed to Connect
>>|
>>| The connection was refused when attempting to contact postmaster.gmx.de.
>
>Hier (mit Firefox 80.0.1) kein Problem (gegen 20:00 Uhr, wenn das was
>hilft).
gewechselt ist?
Manfred
Henning Sponbiel
Sep 8, 2020, 2:00:05 AM9/8/20
to
Henning
Gerhard Zahn
Sep 8, 2020, 4:51:32 AM9/8/20
to
Am Mon, 07 Sep 2020 15:46:15 +0200 schrieb Manfred Polak:
>Damit ist offenbar GMX der Schuldige, und
>zwar der SMTP-Server, nicht der POP3- oder IMAP-Server.
>...........
>Damit ist offenbar GMX der Schuldige, und
>zwar der SMTP-Server, nicht der POP3- oder IMAP-Server.
>Die Zeile wird aber anscheinend nur
>gelöscht, wenn als Content-Disposition "attachment" angegeben ist.
>Wenn da "inline" steht, wird nach meinen bisherigen Erkenntnissen die
>Mail in Ruhe gelassen, und deshalb funktioniert der Workaround mit
>"Inline MIME section" in Agent.
Hallo in die Runde,
>gelöscht, wenn als Content-Disposition "attachment" angegeben ist.
>Wenn da "inline" steht, wird nach meinen bisherigen Erkenntnissen die
>Mail in Ruhe gelassen, und deshalb funktioniert der Workaround mit
>"Inline MIME section" in Agent.
kann den ein Agent-Nutzer berichten, dass bei ihm der Versand von
Anhängen mit Umlaut im Dateinamen über GMX funktioniert?
Und wenn ja, ist dann Attatchment Placement auf "Attachment" oder auf
"Inline MIME section" eingestellt?
Und wir im letzteren Fall der Dateiname und -typ mitgeteilt?
Beste Grüße
G. Zahn
Manfred Polak
Sep 8, 2020, 5:24:03 PM9/8/20
to
Gerhard Zahn schrieb:
>Und unter Folder > Properties bzw. Default Properties > Posting
>messages > Email Attachments steht bei mir jetzt:
>Format: Mime
>und darunter Attachment Placement: Inline MIME section
Ja, so stellt man ein, was Default sein soll. Man kann aber auch noch
direkt beim Einfügen eines Attachments im entsprechenden Dialogfenster
bei "Placement" den Typ ändern.
>Jetzt werden Anhänge mit Umlaut im Dateinamen korrekt versandt, bis
>auf eines:
>
>Beim Empfänger wird zwar die Dateigröße der Anlage angezeigt,
>aaaaber: weder der Dateiname noch der Dateityp wird mit mitübertragen.
>Lässt sich auch das korrigieren?
Nein, bei "Inline" wird diese Information gar nicht erst in die Mail
eingefügt und kommt deshalb auch nicht beim Empfänger an.
Wahrscheinlich ist das auch der einzige Grund, warum GMX hier
nicht rumpfuscht ...
Wenn dieser Punkt für Dich wichtig ist (und dafür kann es natürlich
gute Gründe geben), dann sehe ich ein bis zwei Möglichkeiten:
Erstens dürfte Dein Internetprovider auch einen SMTP-Server betreiben,
den Du anstelle des GMX-Servers benutzen könntest. Allerdings könnte
es sein, dass dieser Server nur Mails mit einer Absenderadresse eben
dieses Providers annimmt, also keine GMX-Adressen beim Absender
zulässt. Das würdest Du wahrscheinlich nicht wollen, aber ich würde
es trotzdem erst mal probieren.
Möglichkeit 2 funktioniert immer: Du könntest die Dateien vor dem
Versenden umbenennen, so dass eben keine Umlaute mehr drin sind.
Manfred
>Und unter Folder > Properties bzw. Default Properties > Posting
>messages > Email Attachments steht bei mir jetzt:
>Format: Mime
>und darunter Attachment Placement: Inline MIME section
direkt beim Einfügen eines Attachments im entsprechenden Dialogfenster
bei "Placement" den Typ ändern.
>Jetzt werden Anhänge mit Umlaut im Dateinamen korrekt versandt, bis
>auf eines:
>
>Beim Empfänger wird zwar die Dateigröße der Anlage angezeigt,
>aaaaber: weder der Dateiname noch der Dateityp wird mit mitübertragen.
>Lässt sich auch das korrigieren?
eingefügt und kommt deshalb auch nicht beim Empfänger an.
Wahrscheinlich ist das auch der einzige Grund, warum GMX hier
nicht rumpfuscht ...
Wenn dieser Punkt für Dich wichtig ist (und dafür kann es natürlich
gute Gründe geben), dann sehe ich ein bis zwei Möglichkeiten:
Erstens dürfte Dein Internetprovider auch einen SMTP-Server betreiben,
den Du anstelle des GMX-Servers benutzen könntest. Allerdings könnte
es sein, dass dieser Server nur Mails mit einer Absenderadresse eben
dieses Providers annimmt, also keine GMX-Adressen beim Absender
zulässt. Das würdest Du wahrscheinlich nicht wollen, aber ich würde
es trotzdem erst mal probieren.
Möglichkeit 2 funktioniert immer: Du könntest die Dateien vor dem
Versenden umbenennen, so dass eben keine Umlaute mehr drin sind.
Manfred
Gerhard Zahn
Sep 9, 2020, 2:53:59 AM9/9/20
to
Am Tue, 08 Sep 2020 23:23:56 +0200 schrieb Manfred Polak:
Hallo M anfred,
Hallo M anfred,
>Möglichkeit 2 funktioniert immer: Du könntest die Dateien vor dem
>Versenden umbenennen, so dass eben keine Umlaute mehr drin sind.
Genau darauf werde ich wohl wieder zurückgehen.
>Versenden umbenennen, so dass eben keine Umlaute mehr drin sind.
Und wenn man diesen Weg häufiger benutzt, dann vergisst man auch nicht
mehr, die Umlaute aus dem Dateinamen zu tilgen.
Danke für dein Mitdenken und deine Hilfe!
Beste Grüße
Gerhard
Wolfgang Kynast
Sep 9, 2020, 3:53:58 AM9/9/20
to
On Wed, 09 Sep 2020 08:53:57 +0200, "Gerhard Zahn" posted:
>Am Tue, 08 Sep 2020 23:23:56 +0200 schrieb Manfred Polak:
>
>Hallo M anfred,
>
>>Möglichkeit 2 funktioniert immer: Du könntest die Dateien vor dem
>>Versenden umbenennen, so dass eben keine Umlaute mehr drin sind.
>
>Genau darauf werde ich wohl wieder zurückgehen.
>Und wenn man diesen Weg häufiger benutzt, dann vergisst man auch nicht
>mehr, die Umlaute aus dem Dateinamen zu tilgen.
Alte Nerd-Regel: alles, was sich nicht in 7-Bit-Ascii darstellen lässt
ist des Teufels!
>Danke für dein Mitdenken und deine Hilfe!
Danichfür :-)
;-)
--
Wolfgang
>Am Tue, 08 Sep 2020 23:23:56 +0200 schrieb Manfred Polak:
>
>Hallo M anfred,
>
>>Möglichkeit 2 funktioniert immer: Du könntest die Dateien vor dem
>>Versenden umbenennen, so dass eben keine Umlaute mehr drin sind.
>
>Genau darauf werde ich wohl wieder zurückgehen.
>Und wenn man diesen Weg häufiger benutzt, dann vergisst man auch nicht
>mehr, die Umlaute aus dem Dateinamen zu tilgen.
ist des Teufels!
>Danke für dein Mitdenken und deine Hilfe!
;-)
--
Wolfgang
Michael Bäuerle
Sep 9, 2020, 4:29:05 AM9/9/20
to
Manfred Polak wrote:
> Gerhard Zahn schrieb:
> >
> > Und unter Folder > Properties bzw. Default Properties > Posting
> > messages > Email Attachments steht bei mir jetzt:
> > Format: Mime
> > und darunter Attachment Placement: Inline MIME section
>
> Ja, so stellt man ein, was Default sein soll. Man kann aber auch noch
> direkt beim Einfügen eines Attachments im entsprechenden Dialogfenster
> bei "Placement" den Typ ändern.
>
> > Jetzt werden Anhänge mit Umlaut im Dateinamen korrekt versandt, bis
> > auf eines:
> >
> > Beim Empfänger wird zwar die Dateigröße der Anlage angezeigt,
> > aaaaber: weder der Dateiname noch der Dateityp wird mit mitübertragen.
> > Lässt sich auch das korrigieren?
>
> Nein, bei "Inline" wird diese Information gar nicht erst in die Mail
> eingefügt und kommt deshalb auch nicht beim Empfänger an.
Prinzipiell wäre das aber möglich, da von RFC 2183 ausdrücklich erlaubt:
> Gerhard Zahn schrieb:
> >
> > Und unter Folder > Properties bzw. Default Properties > Posting
> > messages > Email Attachments steht bei mir jetzt:
> > Format: Mime
> > und darunter Attachment Placement: Inline MIME section
>
> Ja, so stellt man ein, was Default sein soll. Man kann aber auch noch
> direkt beim Einfügen eines Attachments im entsprechenden Dialogfenster
> bei "Placement" den Typ ändern.
>
> > Jetzt werden Anhänge mit Umlaut im Dateinamen korrekt versandt, bis
> > auf eines:
> >
> > Beim Empfänger wird zwar die Dateigröße der Anlage angezeigt,
> > aaaaber: weder der Dateiname noch der Dateityp wird mit mitübertragen.
> > Lässt sich auch das korrigieren?
>
> Nein, bei "Inline" wird diese Information gar nicht erst in die Mail
> eingefügt und kommt deshalb auch nicht beim Empfänger an.
<https://tools.ietf.org/html/rfc2183#section-2.3>
|
| 2.3 The Filename Parameter
|
| [...], 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.
Umlaute in Dateinamen sind ebenfalls genormt (RFC 2231).
Das sollte etwa so aussehen wie in diesem Testartikel:
<news:AABfKp1kC0oAA...@WStation5.stz-e.de>
|
| [...]
| Content-Type: multipart/mixed; boundary=BBB
| [...]
|
| --BBB
|
| Anhang mit Umlaut im Dateinamen
| --BBB
| Content-Type: text/plain; charset=ISO-8859-1
| Content-Disposition: attachment; Filename*=ISO-8859-1''%DCberfall.txt
^^^^^^^^^^
|
| [Body des Anhangs]
| --BBB--
An der markierten Stelle dürfte auch "inline" stehen, s.o.
Für eine Größenangabe wäre zusätzlich der Parameter "Size" zu verwenden:
<https://tools.ietf.org/html/rfc2183#section-2.7>
|
| 2.7 The Size parameter
|
| The size parameter indicates an approximate size of the file in
| octets. It can be used, for example, to pre-allocate space before
| attempting to store the file, or to determine whether enough space
| exists.
Auch hier sehe ich keine Einschränkung, dass man den "Size"-Parameter
in Verbindung mit "inline" nicht verwenden dürfte.
Manfred Polak
Sep 9, 2020, 4:17:52 PM9/9/20
to
Michael Bäuerle schrieb:
>> Nein, bei "Inline" wird diese Information gar nicht erst in die Mail
>> eingefügt und kommt deshalb auch nicht beim Empfänger an.
>
>Prinzipiell wäre das aber möglich, da von RFC 2183 ausdrücklich erlaubt:
><https://tools.ietf.org/html/rfc2183#section-2.3>
Ja, erlaubt ist es tatsächlich. Aber da es Agent nicht macht, sehe ich
auch keine brauchbare Möglichkeit, das nachträglich noch durch ein
Script oder sonstwas hineinzukriegen. Wenn die Mail Agent verlässt,
ist die dafür nötige Information (bei "inline") bereits weg. Bei anderen
Mail-Clients mag das natürlich anders sein, die könnten auch bei
"inline" den Dateinamen und die Größe mit dazupacken.
>Umlaute in Dateinamen sind ebenfalls genormt (RFC 2231).
>Das sollte etwa so aussehen wie in diesem Testartikel:
><news:AABfKp1kC0oAA...@WStation5.stz-e.de>
>|
>| [...]
>| Content-Type: multipart/mixed; boundary=BBB
>| [...]
>|
>| --BBB
>|
>| Anhang mit Umlaut im Dateinamen
>| --BBB
>| Content-Type: text/plain; charset=ISO-8859-1
>| Content-Disposition: attachment; Filename*=ISO-8859-1''%DCberfall.txt
> ^^^^^^^^^^
Hier leistet sich Agent in der Tat einen Bug. Natürlich dürfen im Header
nie uncodierte 8-bit-Zeichen stehen, und Agent macht es trotzdem, egal,
ob man in den Optionen "MIME Headers" angekreuzt hat oder nicht.
Aber interessanterweise werden die beiden Headerzeilen, in die Agent
die Umlaute reinschreibt (Content-Type und Content-Disposition), von
GMX gar nicht angefasst. Stattdessen löscht der Server die Zeile mit
Content-Transfer-Encoding, in der als Wert ja nur das harmlose "base64"
steht. Das ist schon irgendwie schräg, und ich kann mir keinen echten
Reim darauf machen.
Manfred
>> Nein, bei "Inline" wird diese Information gar nicht erst in die Mail
>> eingefügt und kommt deshalb auch nicht beim Empfänger an.
>
>Prinzipiell wäre das aber möglich, da von RFC 2183 ausdrücklich erlaubt:
><https://tools.ietf.org/html/rfc2183#section-2.3>
auch keine brauchbare Möglichkeit, das nachträglich noch durch ein
Script oder sonstwas hineinzukriegen. Wenn die Mail Agent verlässt,
ist die dafür nötige Information (bei "inline") bereits weg. Bei anderen
Mail-Clients mag das natürlich anders sein, die könnten auch bei
"inline" den Dateinamen und die Größe mit dazupacken.
>Umlaute in Dateinamen sind ebenfalls genormt (RFC 2231).
>Das sollte etwa so aussehen wie in diesem Testartikel:
><news:AABfKp1kC0oAA...@WStation5.stz-e.de>
>|
>| [...]
>| Content-Type: multipart/mixed; boundary=BBB
>| [...]
>|
>| --BBB
>|
>| Anhang mit Umlaut im Dateinamen
>| --BBB
>| Content-Type: text/plain; charset=ISO-8859-1
>| Content-Disposition: attachment; Filename*=ISO-8859-1''%DCberfall.txt
> ^^^^^^^^^^
nie uncodierte 8-bit-Zeichen stehen, und Agent macht es trotzdem, egal,
ob man in den Optionen "MIME Headers" angekreuzt hat oder nicht.
Aber interessanterweise werden die beiden Headerzeilen, in die Agent
die Umlaute reinschreibt (Content-Type und Content-Disposition), von
GMX gar nicht angefasst. Stattdessen löscht der Server die Zeile mit
Content-Transfer-Encoding, in der als Wert ja nur das harmlose "base64"
steht. Das ist schon irgendwie schräg, und ich kann mir keinen echten
Reim darauf machen.
Manfred
Michael Bäuerle
Sep 10, 2020, 5:08:04 AM9/10/20
to
Manfred Polak wrote:
> Michael Bäuerle schrieb:
melden, ansonsten als Feature-Request.
Intern muss der Agent die Daten für den Name und die Größe ja erzeugen
können (für "attachment"), d.h. es sollte kein Problem sein das so zu
implementieren, dass diese Daten auch bei "inline" mitgesendet werden.
Das Problem mit der Codierung (s.u.) betrifft dann beide Varianten
(d.h. einmal repariert sollte es auch für "inline" funktionieren).
> > Umlaute in Dateinamen sind ebenfalls genormt (RFC 2231).
> > Das sollte etwa so aussehen wie in diesem Testartikel:
> > <news:AABfKp1kC0oAA...@WStation5.stz-e.de>
> > |
> > | [...]
> > | Content-Type: multipart/mixed; boundary=BBB
> > | [...]
> > |
> > | --BBB
> > |
> > | Anhang mit Umlaut im Dateinamen
> > | --BBB
> > | Content-Type: text/plain; charset=ISO-8859-1
> > | Content-Disposition: attachment; Filename*=ISO-8859-1''%DCberfall.txt
> > ^^^^^^^^^^
>
> Hier leistet sich Agent in der Tat einen Bug. Natürlich dürfen im Header
> nie uncodierte 8-bit-Zeichen stehen, und Agent macht es trotzdem, egal,
> ob man in den Optionen "MIME Headers" angekreuzt hat oder nicht.
Diese Option aktiviert vermutlich nur die Codierung gemäß RFC 2047, die
ist gemäß RFC 2049 [1] Pflicht für MIME-Konformität, siehe Kapitel 2
Punkte (9) und (10).
Dateinamen mit Sonderzeichen in "Content-Disposition" müssen aber gemäß
RFC 2231 codiert werden. Das ist eventuell gar nicht implementiert und
wäre gemäß RFC 2049 [1] trotzdem MIME-konform, wenn ich das richtig sehe
(man darf dann eben keine Dateinamen bzw. nur solche ohne Sonderzeichen
verwenden).
> Aber interessanterweise werden die beiden Headerzeilen, in die Agent
> die Umlaute reinschreibt (Content-Type und Content-Disposition), von
> GMX gar nicht angefasst. Stattdessen löscht der Server die Zeile mit
> Content-Transfer-Encoding, in der als Wert ja nur das harmlose "base64"
> steht. Das ist schon irgendwie schräg, und ich kann mir keinen echten
> Reim darauf machen.
Das ist in der Tat schwer nachvollziehbar.
____________
[1] <https://tools.ietf.org/html/rfc2049#section-2>
> Michael Bäuerle schrieb:
> > Manfred Polak wrote:
> > >
> > > Nein, bei "Inline" wird diese Information gar nicht erst in die Mail
> > > eingefügt und kommt deshalb auch nicht beim Empfänger an.
> >
> > Prinzipiell wäre das aber möglich, da von RFC 2183 ausdrücklich erlaubt:
> > <https://tools.ietf.org/html/rfc2183#section-2.3>
>
> Ja, erlaubt ist es tatsächlich. Aber da es Agent nicht macht, sehe ich
> auch keine brauchbare Möglichkeit, das nachträglich noch durch ein
> Script oder sonstwas hineinzukriegen. Wenn die Mail Agent verlässt,
> ist die dafür nötige Information (bei "inline") bereits weg. Bei anderen
> Mail-Clients mag das natürlich anders sein, die könnten auch bei
> "inline" den Dateinamen und die Größe mit dazupacken.
Die Frage ist, ob das Absicht ist. Falls nein, könnte man es als Bug
> > >
> > > Nein, bei "Inline" wird diese Information gar nicht erst in die Mail
> > > eingefügt und kommt deshalb auch nicht beim Empfänger an.
> >
> > Prinzipiell wäre das aber möglich, da von RFC 2183 ausdrücklich erlaubt:
> > <https://tools.ietf.org/html/rfc2183#section-2.3>
>
> Ja, erlaubt ist es tatsächlich. Aber da es Agent nicht macht, sehe ich
> auch keine brauchbare Möglichkeit, das nachträglich noch durch ein
> Script oder sonstwas hineinzukriegen. Wenn die Mail Agent verlässt,
> ist die dafür nötige Information (bei "inline") bereits weg. Bei anderen
> Mail-Clients mag das natürlich anders sein, die könnten auch bei
> "inline" den Dateinamen und die Größe mit dazupacken.
melden, ansonsten als Feature-Request.
Intern muss der Agent die Daten für den Name und die Größe ja erzeugen
können (für "attachment"), d.h. es sollte kein Problem sein das so zu
implementieren, dass diese Daten auch bei "inline" mitgesendet werden.
Das Problem mit der Codierung (s.u.) betrifft dann beide Varianten
(d.h. einmal repariert sollte es auch für "inline" funktionieren).
> > Umlaute in Dateinamen sind ebenfalls genormt (RFC 2231).
> > Das sollte etwa so aussehen wie in diesem Testartikel:
> > <news:AABfKp1kC0oAA...@WStation5.stz-e.de>
> > |
> > | [...]
> > | Content-Type: multipart/mixed; boundary=BBB
> > | [...]
> > |
> > | --BBB
> > |
> > | Anhang mit Umlaut im Dateinamen
> > | --BBB
> > | Content-Type: text/plain; charset=ISO-8859-1
> > | Content-Disposition: attachment; Filename*=ISO-8859-1''%DCberfall.txt
> > ^^^^^^^^^^
>
> Hier leistet sich Agent in der Tat einen Bug. Natürlich dürfen im Header
> nie uncodierte 8-bit-Zeichen stehen, und Agent macht es trotzdem, egal,
> ob man in den Optionen "MIME Headers" angekreuzt hat oder nicht.
ist gemäß RFC 2049 [1] Pflicht für MIME-Konformität, siehe Kapitel 2
Punkte (9) und (10).
Dateinamen mit Sonderzeichen in "Content-Disposition" müssen aber gemäß
RFC 2231 codiert werden. Das ist eventuell gar nicht implementiert und
wäre gemäß RFC 2049 [1] trotzdem MIME-konform, wenn ich das richtig sehe
(man darf dann eben keine Dateinamen bzw. nur solche ohne Sonderzeichen
verwenden).
> Aber interessanterweise werden die beiden Headerzeilen, in die Agent
> die Umlaute reinschreibt (Content-Type und Content-Disposition), von
> GMX gar nicht angefasst. Stattdessen löscht der Server die Zeile mit
> Content-Transfer-Encoding, in der als Wert ja nur das harmlose "base64"
> steht. Das ist schon irgendwie schräg, und ich kann mir keinen echten
> Reim darauf machen.
____________
[1] <https://tools.ietf.org/html/rfc2049#section-2>
Manfred Polak
Sep 10, 2020, 3:18:39 PM9/10/20
to
Michael Bäuerle schrieb:
>Die Frage ist, ob das Absicht ist. Falls nein, könnte man es als Bug
>melden, ansonsten als Feature-Request.
Das Problem ist halt, dass es für Agent seit sechs Jahren kein Update
mehr gab. Und es sind keine Hinweise ersichtlich, dass sich an dem
Dornröschenschlaf nochmal etwas ändert. Aber vielleicht werden
wir ja irgendwann mal überrascht ...
Manfred
>Die Frage ist, ob das Absicht ist. Falls nein, könnte man es als Bug
>melden, ansonsten als Feature-Request.
mehr gab. Und es sind keine Hinweise ersichtlich, dass sich an dem
Dornröschenschlaf nochmal etwas ändert. Aber vielleicht werden
wir ja irgendwann mal überrascht ...
Manfred
0 new messages