Sonderzeichen im Betreff werden falsch dargestellt

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

  • Sonderzeichen im Betreff werden falsch dargestellt

    Ich habe das Problem, dass Sonderzeichen im Betreff falsch dargestellt werden.
    Die Probleme scheinen damit zu tun zu haben, dass Domainfactory die Mails im Header als SPAM markiert.
    Der Original-Betreff lautet: plusieurs étages
    Der Betreff mit Spam-Markierung: [SPAM] plusieurs �tages

    Im Header der Mail steht aber:
    Subject: [SPAM] plusieurs étages

    Die Mails werden von Exchange per Pop3-Connector von Domainfactory abgeholt und dann im lokalen Exchange-Server zur Verfügung gestellt.
    Outlook zeigt den Betreff auch falsch an.

    Wenn ich die Mail mit TheBat in ein lokales POP3-Konto kopiere, dann wird im POP3-Konto plötzlich wieder der richtige Betreff angezeigt.
    Ein Kopieren in ein anderes IMAP-Konto (GMX) ändert nichts.

    Was kann die Ursache sein?
    The Bat! 7.3.12 (64-Bit)

    Edit:
    es scheint immer "FD FF" angezeigt zu werden - egal welches Sonderzeichen oder welcher Umlaut ursprünglich genutzt wurde.

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

  • Wie? Das ist so?

    Quellcode

    1. Subject: [SPAM] plusieurs étages
    Das e accentgrave muss aber anders kodiert sein!
    Da ist ja gar kein Encoding drin. Unicode in Headern sind so nicht erlaubt.

    Wenn schon dann so:

    Quellcode

    1. Subject: =?utf-8?Q?[SPAM]_plusieurs_=C3=A9tages?=
    Kann auch sein, dass Outlook-Schrott das fabriziert ohne Encoding zu senden.


    SpamAssassin ist installiert auf dem Server? Ja, dann vermurkst der den Betreff. Wo soll dann der Filter das korrekt hinkriegen ohne Encoding!

    Du kannst ja gern mal deinen Serveranbieter fragen was das ist.
    TheBat! Pro 7.x BETA (32bit) • Win 10 Pro x64 • GnuPG 2.0.x • XMP,Regula


    Ich bin Gwendolyn. Wer mich der Drache nennt, bekommt von der Drachin Pratze und Feuer zu spüren.
  • Korrektes Encoding wäre:

    Quellcode

    1. Date: Thu, 8 Dec 2016 16:09:17 +0100
    2. From: GwenDragon <info@gwendragon.de>
    3. Message-ID: <504570598.20161208160917@gwendragon.de>
    4. Subject: =?utf-8?Q?[SPAM]_plusieurs_=C3=A9tages?=
    5. MIME-Version: 1.0
    6. Content-Type: text/plain; charset=utf-8
    7. Content-Transfer-Encoding: quoted-printable
    8. Date: Thu, 8 Dec 2016 16:13:01 +0100
    9. From: GwenDragon <info@gwendragon.de>
    10. Message-ID: <236225505.20161208161301@gwendragon.de>
    11. Subject: =?iso-8859-15?Q?[SPAM]_plusieurs_=E9tages?=
    12. MIME-Version: 1.0
    13. Content-Type: text/plain; charset=iso-8859-15
    14. Content-Transfer-Encoding: quoted-printable
    15. Date: Thu, 8 Dec 2016 16:13:01 +0100
    16. From: GwenDragon <info@gwendragon.de>
    17. Message-ID: <236225505.20161208161301@gwendragon.de>
    18. Subject: =?iso-8859-1?Q?[SPAM]_plusieurs_=E9tages?=
    19. MIME-Version: 1.0
    20. Content-Type: text/plain; charset=iso-8859-1
    21. Content-Transfer-Encoding: quoted-printable
    Alles anzeigen
    TheBat! Pro 7.x BETA (32bit) • Win 10 Pro x64 • GnuPG 2.0.x • XMP,Regula


    Ich bin Gwendolyn. Wer mich der Drache nennt, bekommt von der Drachin Pratze und Feuer zu spüren.
  • Ich habe jetzt mal DomainFactory kontaktiert. Mal schauen, was die machen können.
    Normalerweise ist SPAM ja SPAM und da braucht man sich keine Gedanken zu machen.
    Heute habe ich aber mal nach langer, langer Zeit eine false positive SPAM erhalten. (ist sicherlich die erste seit über 5 Jahren). Und da gab es zufälligerweise Sonderzeichen.

    Danke für Deine Hilfe!
  • Es hängt wohl damit zusammen, dass in der betreffenden eMail Nicht-ASCII-Zeichen in den Nachrichtenkopfzeilen gar nicht kodiert wurden. In TB! z.B. kann man das über "Kontoeigenschaften | Erweitert" einstellen. Wenn man dort unten unter "Kodierung von Nicht-ASCII-Zeichen beim Versand" bei "Kopfzeilen: keine" wählt, dann wird der o.g. Betreff nicht kodiert versandt:

    Quellcode

    1. Subject: [SPAM] plusieurs étages
    Das kann natürlich zu Anzeigeproblemen beim Empfänger führen. Wie gesagt, in TB! kann man das ändern. Ob's auch in dem Programm geht, mit dem der Betreff verändert wurde, muss man klären.
  • MS Web Outlook ist so ein Kandidat, der versendet auch einfach als Unicode ohne das Encoding bei den notwendigen Headern mit zu führen. Nachfolgende Mailserverdienste streiken da mal bei der Verarbeitung. Dass Microsofts Programme damit Standards brechen, ist denen egal.

    Man muss abklären, was der sendende Mailpartner da im eigenen Mailprogramm an Murks verzapft.
    TheBat! Pro 7.x BETA (32bit) • Win 10 Pro x64 • GnuPG 2.0.x • XMP,Regula


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

    Als Client wurde da Thunderbird verwendet
    Der Zusatz "[SPAM]" wurde nicht vom Absender und damit von Thunderbird eingefügt, sondern vom Empfänger-Server bzw. von dem auf diesem Server laufenden Anti-Junk-Filter, in diesem Fall also von SpamAssassin. Es kann also durchaus sein, dass der ursprüngliche Betreff in Thunderbird beim Versand zwar richtig kodiert war, jedoch später nachträglich nicht kodiert verändert wurde.

    Jedenfalls kannst du den Absender bitten, dir eine weitere Nachricht mit einem Nicht-ASCII-Zeichen im Betreff über Thunderbird zu schicken, dabei am besten ohne spamverdächtigen Inhalt. Wenn diese Nachricht unverändert ankommt, dann kannst du sehen, ob der Betreff kodiert ist. Wenn ja, dann liegt's nicht am Absender, sondern am Empfänger-Server.
  • Mir ist das klar.
    Wenn ich aber sichergehen kann, dass Thunderbird den Betreff immer kodiert, dann kann der Fehler zu 100% nicht bei Thunderbird liegen.
    Es ist, was ich in der Zwischenzeit auch erfahren habe, auch nicht SpamAssassin verantwortlich.
    Dieses Tool überprüft zwar die Mails - die Umbenennung des Betreffs erfolgt aber anscheinend durch einen weiteren Schritt bei Domainfactory.
    Und alles deutet darauf hin, dass da etwas schief läuft.

    Ein individuelles Filtern und Umbenennen ist bei Domainfactory jedoch erfolgreich, d.h. die Kodierung bleibt erhalten. Ich konnte da aber bislang nur Non-Spam testen.
    Somit ist möglicherweise nur die Default-Einstellung (nennt sich bei denen MailfilterEASY ) betroffen.
  • DT5 schrieb:

    Wenn ich aber sichergehen kann, dass Thunderbird den Betreff immer kodiert, dann kann der Fehler zu 100% nicht bei Thunderbird liegen.
    Selbst wenn es eine entsprechende Einstellung in Thunderbird nicht gibt, kann man sie eventuell über eine Erweiterung hinzufügen. Es kann auch sein, dass die Nachricht nach Thunderbird durch einen lokalen SMTP-Server durchgeht, auf dem die Kopfzeilen verändert werden. Wirklich sicher kann man daher nur sein, wenn der gleiche Absender unter gleichen Bedingungen eine weitere Nachricht sendet und diese unverändert ankommt.
  • Sieht jetzt alles danach aus, dass MailfilterEASY das Problem ist.
    Wenn ich die Filter manuell setze, dann erhalte ich SPAM mit sauber kodiertem Betreff.
    Wenn ich die Filter wieder lösche, MailfilterEASY aktiviere und dann die Mails auf den gleichen Account umleite, dann ist der Betreff unkodiert.

    Zur Erklärung:
    Wenn man bei Domainfatory SPAM&Viren herausfiltern lassen will, dann wird MailfilterEasy standardmäßig aktiviert.
    Mit eigenen Filter kann man detailiertere Regeln festlegen.