Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Cannot display Unicode content
192 views
Skip to first unread message
Sebastian Suchanek
Sep 11, 2022, 4:22:23 PM9/11/22
to
Hallo NG!
Vorweg kurz zu meinem Mail-Setup als Ganzes: Auf (m)einem "richtigen"
Server läuft Exim, der eingehende Mails u.a. durch Spamassassin schiebt.
Alle "legitimen" Mails landen in Maildirs, von wo aus sie ein
Courier-POP zum Abholen bereithält. Das Abholen erledigt ein Fetchmail
auf meinem Heimserver[1]. (Von dort aus geht es in einen weiteren Exim
und letztendlich via Courier-IMAP an die Clients.)
Das hat soweit alles jahrelang wunderbar funktioniert. Allerdings habe
ich jetzt wegen eines Providerwechsels das Setup auf einen neuen
"externen" Server umgezogen, was mit einem Wechsel von Debian Stretch
auf Debian Buster einherging.
Seither habe ich das Problem, das zunächst *jede* Mail nicht
ordnungsgemäß zugestellt wurde, sondern ich stattdessen eine
Fehlermeldungsmail mit dem Betreff "Cannot display Unicode content"
erhalten habe. Der Inhalt dieser Mails beginnt mit diesem Text:
| This E-mail message was determined to be Unicode-formatted
| but your E-mail reader does not support Unicode E-mail.
|
| Please use an E-mail reader that supports POP3 with UTF-8
| (see https://tools.ietf.org/html/rfc6856.html).
|
| This can also happen when the sender's E-mail program does not
| correctly format the sent message.
|
| The original message is included as a separate attachment
| so that it can be downloaded manually.
| [...]
Absender war/ist "postmaster@$EMPFÄNGERDOMAIN.tld" - das und auch die
Header deuten darauf hin, dass diese Mails auf dem externen Server
erzeugt wurden/werden.
Das Problem wurde besser, als ich auf dem externen Server die Locale von
Deutsch auf Englisch umgestellt habe und damit zumindest der von
Spamassassin eingefügte Info-Header keine (UTF8-codierten?) Umlaute mehr
enthielt. Danach kam die Fehlermeldung nur noch bei einigen Mails -
anscheinend solchen, die schon absenderseitig UTF8-codierte Header
enthalten. Wenn ich Spamassassin komplett aus der Mail-"Pipeline"
herausnehme, funktioniert alles wie gewohnt - allerdings ist das ja auch
nicht Sinn der Sache. ;-)
Ich habe in der Spamassassin-Config auch schon "normalize_charset 0"
gesetzt in der Hoffnung, dass Spamassassin dann nicht an irgendwelchen
Zeichencodierungen 'rumfummelt, das scheint allerdings nichts gebracht
zu haben.
Lange Rede, kurzer Sinn: was läuft da schief und wie kann ich es reparieren?
TIA,
Sebastian
_____
[1] Der Heimserver läuft ebenfalls auf Debian Stretch. Das bekomme ich
Aus Gründen[tm] auch nicht so einfach aktualisiert.
Vorweg kurz zu meinem Mail-Setup als Ganzes: Auf (m)einem "richtigen"
Server läuft Exim, der eingehende Mails u.a. durch Spamassassin schiebt.
Alle "legitimen" Mails landen in Maildirs, von wo aus sie ein
Courier-POP zum Abholen bereithält. Das Abholen erledigt ein Fetchmail
auf meinem Heimserver[1]. (Von dort aus geht es in einen weiteren Exim
und letztendlich via Courier-IMAP an die Clients.)
Das hat soweit alles jahrelang wunderbar funktioniert. Allerdings habe
ich jetzt wegen eines Providerwechsels das Setup auf einen neuen
"externen" Server umgezogen, was mit einem Wechsel von Debian Stretch
auf Debian Buster einherging.
Seither habe ich das Problem, das zunächst *jede* Mail nicht
ordnungsgemäß zugestellt wurde, sondern ich stattdessen eine
Fehlermeldungsmail mit dem Betreff "Cannot display Unicode content"
erhalten habe. Der Inhalt dieser Mails beginnt mit diesem Text:
| This E-mail message was determined to be Unicode-formatted
| but your E-mail reader does not support Unicode E-mail.
|
| Please use an E-mail reader that supports POP3 with UTF-8
| (see https://tools.ietf.org/html/rfc6856.html).
|
| This can also happen when the sender's E-mail program does not
| correctly format the sent message.
|
| The original message is included as a separate attachment
| so that it can be downloaded manually.
| [...]
Absender war/ist "postmaster@$EMPFÄNGERDOMAIN.tld" - das und auch die
Header deuten darauf hin, dass diese Mails auf dem externen Server
erzeugt wurden/werden.
Das Problem wurde besser, als ich auf dem externen Server die Locale von
Deutsch auf Englisch umgestellt habe und damit zumindest der von
Spamassassin eingefügte Info-Header keine (UTF8-codierten?) Umlaute mehr
enthielt. Danach kam die Fehlermeldung nur noch bei einigen Mails -
anscheinend solchen, die schon absenderseitig UTF8-codierte Header
enthalten. Wenn ich Spamassassin komplett aus der Mail-"Pipeline"
herausnehme, funktioniert alles wie gewohnt - allerdings ist das ja auch
nicht Sinn der Sache. ;-)
Ich habe in der Spamassassin-Config auch schon "normalize_charset 0"
gesetzt in der Hoffnung, dass Spamassassin dann nicht an irgendwelchen
Zeichencodierungen 'rumfummelt, das scheint allerdings nichts gebracht
zu haben.
Lange Rede, kurzer Sinn: was läuft da schief und wie kann ich es reparieren?
TIA,
Sebastian
_____
[1] Der Heimserver läuft ebenfalls auf Debian Stretch. Das bekomme ich
Aus Gründen[tm] auch nicht so einfach aktualisiert.
Laurenz Trossel
Sep 11, 2022, 7:59:18 PM9/11/22
to
On 2022-09-11, Sebastian Suchanek <sebastian...@gmx.de> wrote:
> Lange Rede, kurzer Sinn: was läuft da schief und wie kann ich es reparieren?
Da steht doch:
> Lange Rede, kurzer Sinn: was läuft da schief und wie kann ich es reparieren?
>| This E-mail message was determined to be Unicode-formatted
>| but your E-mail reader does not support Unicode E-mail.
>|
>| Please use an E-mail reader that supports POP3 with UTF-8
>| (see https://tools.ietf.org/html/rfc6856.html).
Fetchmail meldet per POP keine Unterstützung für UTF-8 nach RFC6856, also
>| but your E-mail reader does not support Unicode E-mail.
>|
>| Please use an E-mail reader that supports POP3 with UTF-8
>| (see https://tools.ietf.org/html/rfc6856.html).
hüllt der Server die Mail in einen 7bit-Umschlag.
https://sourceforge.net/p/fetchmail/mailman/fetchmail-users/thread/0e41ab7f-e74a-1b54-395c-89b248c56ab1%40gmx.de/
https://gitlab.com/fetchmail/fetchmail/-/issues/14
Vielleicht lässt sich das Verhalten im POP-Server konfigurieren.
Sebastian Suchanek
Sep 25, 2022, 5:41:53 PM9/25/22
to
bis ich ausprobieren und testen konnte.
Wirklich weiter gekommen bin ich indes nicht - Google ist hier leider
auch nicht wirklich hilfreich. In Anlehnung an [1] habe ich testweise
'mal "UTF8 = ACCEPT" in die /etc/courier/pop3d-ssl eingetragen,
allerdings hat das nichts gebracht.
Wenn ich mich allerdings auf der Courier-Homepage so umschaue, bekomme
ich außerdem den Verdacht, dass zumindest der POP3-Teil nicht mehr
wirklich weiterentwickelt wird. In [1] wird u.a. auch vorgeschlagen, von
Courier auf Dovecot zu wechseln. Was ist davon zu halten?
Tschüs,
Sebastian
_____
[1] https://debianforum.de/forum/viewtopic.php?t=174337
Sebastian Suchanek
Oct 27, 2022, 12:17:06 PM10/27/22
to
Am 25.09.2022 um 23:38 schrieb Sebastian Suchanek:
> [...]
> [1] https://debianforum.de/forum/viewtopic.php?t=174337
Fürs Protokoll: Das - also den Wechsel von Courier auf Dovecot - habe
ich jetzt gemacht. Die Installation von Dovecot war auch relativ
einfach: ich musste in der Konfiguration nur die Pfade für die Maildirs
sowie für die SSL-Zertifikate (von Let's Encrypt) anpassen. Bislang
scheint alles zu funktionieren.
Tschüs,
Sebastian
> [...]
> In [1] wird u.a. auch vorgeschlagen, von
> Courier auf Dovecot zu wechseln. Was ist davon zu halten?
> _____
> Courier auf Dovecot zu wechseln. Was ist davon zu halten?
> [1] https://debianforum.de/forum/viewtopic.php?t=174337
Fürs Protokoll: Das - also den Wechsel von Courier auf Dovecot - habe
ich jetzt gemacht. Die Installation von Dovecot war auch relativ
einfach: ich musste in der Konfiguration nur die Pfade für die Maildirs
sowie für die SSL-Zertifikate (von Let's Encrypt) anpassen. Bislang
scheint alles zu funktionieren.
Tschüs,
Sebastian
0 new messages