Ich habe Probleme, meine persönlichen spamassassinRegeln festzulegen. Mein Problem: Ich bekomme viel russischen Spam mit kyrillischen Buchstaben, viele davon UTF-8. Daher ist die Suche nach einem Zeichensatz nicht ausreichend. Deshalb mag ich stattdessen ein paar typischen russischen Buchstaben suchen (zB): (д|ж|з|и|й).
Ich habe sowohl das Muster /(д|ж|з|и|й)/ials auch /(\xd0\xb4|\xd0\xb6|\xd0\xb7|\xd0\xb8|\xd0\xb9)/i(diese Regex-Muster sollten das Gleiche tun, richtig?) In einer SubjectSuche ausprobiert :
Ergebnis: Der UTF-8Spam kommt immer noch durch. Ich habe die E-Mails analysiert, die durchkommen. Alle haben eine ähnliche Struktur. Der (wichtige Teil der) Quelle sucht nach einem Beispiel für Spam-Mails wie folgt
Also, das subjectverwendet RFC2047: =?UTF-8?B?msg_subject?= =?UTF-8?B?msg_subject2?= [...]. Diese Zeile sagt uns, die subjectverwendet die utf-8charset und base64Codierung (vergleiche http://www.ietf.org/rfc/rfc2047.txt ).
Dies hilft mir aber nicht, wie es gerade beschreibt, wie Base64-kodierte Strings gefiltert werden, die lang genug sind. Da ich nach einzelnen Zeichen suche, kann ich diesen Ansatz nicht verwenden.
Fehlt mir etwas? Danke für Ihre Hilfe!
edit: Ich habe auch die rawbodySuche versucht, weil dies die base64-Kodierung wie in den Dokumenten dekodieren soll :
rawbody CYRILLIC_LETTER_PRESENT /(д|ж|з|и|й)/i
Hat auch nicht für mich gearbeitet, obwohl es auch den ganzen Körper durchsuchen sollte und es voller kyrillischer Buchstaben ist.
edit2: Ich habe versucht, das Problem weiter zu untersuchen. Wenn ich versuche, textcat mit zu testen spamassassin -D textcat -t spamtest, sagt es mir " can't determine language uniquely enough".
So wie es aussieht funktioniert es. Alles war gut. Meine Regel, hier genannt LOCAL_CYRILLIC, funktioniert wie beabsichtigt. ABER das Problem ist, diese E-Mail wurde nicht als Spam erkannt, da dieselbe Regel in der Konfigurationsdatei vorhanden war. Ich habe versucht, dieselbe E-Mail erneut an mich weiterzuleiten, und die E-Mail-Quelle sieht dann folgendermaßen aus:
Es scheint also ein Unterschied zu geben, ob der Test lokal in einer Datei ausgeführt wird und welche E-Mails tatsächlich eingehen. Warum? Ich starte spamassassin immer wieder mit systemctl restart spamassassin. Ich habe es überprüft systemctl status spamassassinund alles sieht gut aus, spamdwird auch neu gestartet, wie es sein sollte. Dort finde ich auch folgende Informationen zur weitergeleiteten E-Mail:
spamd: clean message (2.7/3.0) for spamd:5555 in 6.0 seconds, 8371 bytes. spamd: result: . 2 - LOCAL_CYRILLIC,RCVD_IN_DNSWL_MED scantime=6.0,size=8371,user=spamd,uid=5555,required_score=3.0,[...]
Haben Sie versucht, `ok_locales` zu konfigurieren? https://spamassassin.apache.org/full/3.2.x/doc/Mail_SpamAssassin_Conf.html#language_options
AnFi vor 7 Jahren
0
@ AndrzejA.Filip das `ok_locales` sucht nur nach typischen regionalen Zeichensätzen. Das hilft mir nicht weiter, da die E-Mails in `utf-8` sind = /
nox vor 7 Jahren
0
Sorry, ok_languages ist besser geeignet. Die Testnote "UNWANTED_LANGUAGE_BODY" beträgt 2,8. https://spamassassin.apache.org/full/3.1.x/doc/Mail_SpamAssassin_Plugin_TextCat.html
AnFi vor 7 Jahren
0
@ AndrzejA.Filip Vielleicht hast du recht, aber das funktioniert trotzdem nicht für meinen Fall, ich habe es auch ausprobiert, hätte das vielleicht schreiben sollen. Die E-Mails werden mit dieser Option immer noch gesendet. Ich vermute, es liegt an ihren `utf-8`-Zeichensätzen in Verbindung mit der` base64`-Codierung.
nox vor 7 Jahren
0
Haben Sie versucht, die Arbeit des Texcat-Plugins zu überprüfen? `spamassassin -D textcat -t spam_message_file`
AnFi vor 7 Jahren
0
@ AndrzejA.Filip siehe neue Bearbeitung. Vielen Dank für Ihre bisherige Hilfe!
nox vor 7 Jahren
0
Wird die Regel mit UTF-8 erstellt? Diese Glyphen können mit verschiedenen Codeseiten abgerufen werden.
Yorik vor 7 Jahren
0
Ich bin mir nicht sicher, was Sie hier fragen möchten. Die Konfigurationsdatei selbst befindet sich im `utf-8`-Zeichensatz. Ich denke, dass die Unicode-Codes für diese Buchstaben eindeutig sind.
nox vor 7 Jahren
0
1 Antwort auf die Frage
0
Daniel Vérité
Offensichtlich entschlüsselt Spamassassin dies nicht (richtig). Ich habe keine Möglichkeit gefunden, diese Funktion zum Laufen zu bringen
Es funktioniert für mich mit Ubuntu 14.04, spamassassin 3.4, Perl 5.18.2, locale: fr_FR.UTF-8.
$ spamc -R <mailtest 10,0 / 5,0 Spam-Erkennungssoftware, die auf dem System ausgeführt wird, ** geändert ** ... Inhaltsvorschau: ** redigiert ** [...] Angaben zur Inhaltsanalyse: (10,0 Punkte, 5,0 erforderlich) pts Regelname Beschreibung ---- ---------------------- ------------------------ -------------------------- 10 RUSSIAN_CHARS russische Zeichen in der Kopfzeile 0.0 DKIM_ADSP_CUSTOM_MED Keine gültige Signatur des Autors, Adsp_override ist CUSTOM_MED 0.0 FREEMAIL_FROM Absender-E-Mail ist in der Regel ein Endverbraucher-E-Mail-Anbieter (** redigiert ** [um] gmail.com) -0.0 NO_RELAYS Information: Die Nachricht wurde nicht über SMTP weitergeleitet
Es trifft auch mit rawbody RUSSIAN_CHARS /(д|ж|з|и|й)/i
Ich hatte Glück, ich hatte nicht so viel Glück. Wie auch immer, siehe neue Bearbeitung für zusätzliche Informationen.
nox vor 7 Jahren
0
@nox: Wenn ich es richtig verstanden habe, funktioniert die Filterung auch für Sie. Jetzt haben Sie eine andere Frage, weshalb bestimmte andere Regeln übereinstimmen oder nicht, je nachdem, wie Spamassassin aufgerufen wird.
Daniel Vérité vor 7 Jahren
0
Vielleicht war das meine Frage von Anfang an. Zur Klarstellung: Ich möchte diese Regel natürlich für eingehende E-Mails anwenden, und diese Regel funktioniert nicht, während andere dort perfekt funktionieren. Mein Setup-Filter funktioniert jedoch vor Ort.
nox vor 7 Jahren
0