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.

    Einmal editiert, zuletzt von DT5 (8. Dezember 2016 um 15:46)

  • Du meinst, was mir TheBat als Header anzeigt?
    Das hatte ich geschrieben:
    Subject: [SPAM] plusieurs étages

    Ich hatte den ursprünglichen Beitrag auch noch einmal editiert (ein paar Zeilen dazugeschrieben). Leider erst nachdem Du schon geantwortet hattest

  • Das was bei F9 im Subject und X-Original-Subject und Original-Subject (falls letztere auch vorhanden) steht!


    The Bat! Pro 11.x BETA (32bit) | Win 11 Pro x64 | GnuPG 2.4.x | XMP + Regula

    Wer mich Er oder der Drache nennt, bekommt von der Drachin Pratze und Feuer zu spüren.

  • Wie? Das ist so?

    Code
    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:

    Code
    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.


    The Bat! Pro 11.x BETA (32bit) | Win 11 Pro x64 | GnuPG 2.4.x | XMP + Regula

    Wer mich Er oder der Drache nennt, bekommt von der Drachin Pratze und Feuer zu spüren.

  • Korrektes Encoding wäre:


    The Bat! Pro 11.x BETA (32bit) | Win 11 Pro x64 | GnuPG 2.4.x | XMP + Regula

    Wer mich Er oder der Drache nennt, bekommt von der Drachin Pratze und Feuer zu spüren.

  • Ich habe noch einmal in 'normale' Mails geschaut.
    Da steht dann etwas wie
    Subject: =?iso-8859-1?Q?Kr=FCmmling?=
    drin.

    SpamAssassin ist auf den Servern von DomainFactory installiert (von denen).

    Code
    X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
            spamfilter17.ispgateway.de
  • 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:

    Code
    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.


    The Bat! Pro 11.x BETA (32bit) | Win 11 Pro x64 | GnuPG 2.4.x | XMP + Regula

    Wer mich Er oder der Drache nennt, bekommt von der Drachin Pratze und Feuer zu spüren.

  • Ich bekomme es nicht hin die in Thunderbird auszuschalten. Bei mir sind Nicht-ASCII im Betreff immer kodiert.


    The Bat! Pro 11.x BETA (32bit) | Win 11 Pro x64 | GnuPG 2.4.x | XMP + Regula

    Wer mich Er oder der Drache nennt, bekommt von der Drachin Pratze und Feuer zu spüren.

  • 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.

  • 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.