Spam-Mails kommen als interner Absender durch, warum auf einmal?

Da ist gar nichts falsch. Das ist eine Eigenheit des SMTP Protokolls:

Spam Prüfungen gehen immer auf die internen Routing Felder eines Maildokuments, während dir im Client die Inhalte der Textfelder angezeigt werden.

Dies hängt unter anderem auch damit zusammen, daß du ja einen Absender in der Form "Nachname, Vorname " (emailadresse) anzeigen lassen kannst.
In den internen Feldern steht aber dann trotzdem bei Absenden nur die eMailadresse drin.
Und es gibt leider keine Definition, daß diese internen und die anzeigbaren Felder übereinstimmen müssen oder auch nur irgendetwas miteinander zu tun haben müssen

Die IQ Suite nimmt immer das Feld "From" als Absenderinformation. In diesem Feld steht bei den genannten Mails die eigene SMTP-Adresse drin. Somit denkt die Suite es ist ein lokaler Absender.

Ich vergleiche bei mir die Felder From und SMTP-Originator. Sofern hier unterschiedliche Werte stehen kennzeichne ich die Mail als SPAM.

Ist vielleicht ein Lösungsansatz.

fohlen

Und wie behandelst du dann eMails die eine Adresse in der Form "Nachname, Vorname" (emailadresse) als Absender angeben ?

Denn im From steht da ja auch nur die eMail-Adresse drin und damit wären die beiden Felder unterschiedlich.

Und dann würdest du ja eine ganze menge ordnungsgemäßer Mails als Spam kennzeichnen

Markus.M.

Nicht auf diesem Weg. Da würde dann wohl am ehesten die Kombination mit den anderen Spamidentifizierungsmöglichkeiten helfen, also Blacklisten,...

taurec

Dieser Job der IQ Suite läuft nicht mit höchster Priorität.

Ich vergleiche auch nicht die gesamten Feldwerte. Hier mal meine Auswahlregel:

_tmp1:=@Left(@Right(@LowerCase(SMTPOriginator);"@");".");
_tmp2:=@Left(@Right(@LowerCase(From);"@");".");
_tmp3:=@Middle(@LowerCase(SMTPOriginator);"@";-2);
_tmp4:=@Middle(@LowerCase(From);"@";-2);

@If(_tmp1!=_tmp2 | _tmp3!=_tmp4;@True;@False)

Das funktioniert bei mir in Verbindung mit WhiteLists ordentlich.

Beispiel:

From: "admin@Viagra.com <vorname.nachname@meine-domäne.de>"
SMTPOriginator: "binian@wall123.fsnet.co.uk"

Natürlich läuft das auch nicht ganz fehlerfrei, z.B. bei einigen Newslettern oder Mails, die mit BlackBerry eingereicht werden.

Erstelle eine Auswahlregel vom Typ "Formula" und füge die genannte Formel ein.

Ich habe zur Sicherheit noch eine zweite Regel vom Typ "Formula" angelegt, die das Feld SMTPOriginator überprüft:

@If(SMTPOriginator="";@True;@False)

Erstelle dann einen WallMailJob. Der Job läft auf "Ausgewählte Mails", die Abhängigkeit vom Anhang kann auf "Alle" gesetzt werden.
In den positiven Regeln nimmst Du die Auswahlregel auf, in die negierten Regeln nimmst Du die Auswahlregel auf, die das Feld SMTPOriginator überprüft, sowie entsprechende WhiteList-Regeln.
Bei den WhiteLists solltest Du darauf achten, dass Deine User in der Liste nicht enthalten sind.

Die Gültigkeit für Absender setzt Du auf "Alle in Liste" und trägst in der Liste "*@*" ein.

Dann musst Du nur noch die Operations, etc. nach Deinen Wünschen ausfüllen.

Fertig.

Hi,

zur Zeit rollt eine Spamwelle, die einen Schwachpunkt bei vielen Produkten ausnutzt.

Boshafterweise werden diesmal nicht nur die Absenderadressen gefälscht, sonden auch die Empfänger. Ein Mail sieht dann zum Beispiel so aus:

... schnipp ...
Mail from:irgendwer@meine_domain.de
Rcpt to: <"arme_sau@web.de"@meine_domain.de>
... schnapp ...

Diese Mail geht dann bei vielen Filtern durch, die nur die Empfängerdomain prüfen. Wenn diese Mail dann beim Domino aufschlägt, stellt er sie an den "lokalen" Empfänger arme_sau@web.de zu, fatalerweise mit dem Absender irgendwer@meine_domain.de. Der Empfänger muß natürlich keine externe Domain wie web.de sein - er kann auch auf @meine_domain.de stammen.
Übrigens: das Prüfen der Internetadresse durch den Domino hat an der Stelle nichts bewirkt - zumindest in der 5.x ...

Zitat Feuerzangenbohle: "Jungs, wat habt Ihr für ne fiese Charakter"

In einer meiner "toten" Installationen mit Domino 5.x und IMSS von TrendMicro konnte ich mir kurzfristig nur durch einen schnell vorgeschalteten Postfix (mit LDAP-Anfrage an den Domino) behelfen.

Kombiniert mit ein paar DNS-Reverse-Lookups und der LDAP-Anfrage blockt der Postfix so locker erst einmal mindesten 80% aller Mailanfragen schon am Eingang - bevor die IMSS den Rest erledigt.

Nicht jeder hat ein internes Mailrelay zur Verfügung, aber selbst mit internem Mailrelay ist nicht jeder in der Lage, die Blockierung einzurichten.

Mit der IQ-Suite gibt es aber etliche Möglichkeiten hier etwas zu tun.

Der erste Schritt sollte immer folgender Check auf "durchgekommene" Mails sein: das Feld $TkFlag50 prüfen

Daran erkennt man, welche Jobs sich überhaupt mit der Mail befasst haben. Bei Jobs, die die Mail nicht bearbeitet haben obwohl sie sollten ist (mindestens) eine Bedingung falsch gesetzt.

Weiterhin hat man mit der IQ-Suite die geniale Chance, Fake-Mails zu filtern, so kann man beispielsweise alle Mails filtern, die mit einer internen Absenderadresse aber ohne Notes-typische weitere Felder erkannt werden (Client-Version im $Mailer beispielsweise prüfen oder das Vorhandensein des Felds $SMTPNotFromNotes).

Achtung: bei der Fake-Prüfung aber aufpassen, dass nicht echte interne SMTP-Mails versehentlich geblockt werden. Gern wird der Notesserver auch von anderen internen Maschinen für den SMTP-Versand mit benutzt. Hier müssen die so eingehenden Mails natürlich wieder auf besondere Eigenschaften geprüft werden um sie von Fakes zu unterscheiden.

Ich kann hier leider keine fertig funktionierende Back-Anleitung posten, ich mußte die Regeln und Jobs bisher bei jedem Kunden separat auf die dortigen Gegebenheiten anpassen.

Eine Sache kann ich aber generell sagen: die vorgefertigten Regeln LocalSender / RemoteSender / WhitelistSender sind absolut ungeeignet um bei den Antivirus- oder Spam-Jobs als Nicht-Prüf-Kriterium eingesetzt zu werden. Diese prüfen nämlich nur die Absenderadresse und die kann, wenn nichts dagegen getan wird, von jedem beliebig gesetzt werden.