Mails in der Mail.Box stauen sich

[Norton]

Hallo zusammen,

wir haben ein Problem, dass sich in der letzten Zeit unser Spam-Aufkommen deutlich erhöht hat (bis zu 25.000 erkannte Spam Mails pro Tag). Dies führt dazu, dass sich die Mails in unseren beiden Mailboxen aufstauen und nicht mehr zeitnah abgearbeitet werden können. So entstehen natürlich unangenehme Wartezeiten.

Der Status der Mails ist Check in Progress. Wir benutzen die IQSuite von Group zur Spamerkennung sowie für die Dateirestriktionen. Bisher hat dies auch sehr gut funktioniert, aber seit einigen Tagen (keine Änderungen in der Konfiguration - lediglich ein erhöhtes Mailaufkommen wegen den Spams) ist es doch sehr heftig geworden.

Was wir bisher gemacht haben ist ein Komprimieren der Mailboxen, ein Neustart des Domino-Servers sowie ein Neustart der physischen Maschine. Weiterhin ein Fixup sowie ein Updall. Alles ohne sichtbaren Erfolg.

Die eingesetzte Server-Version ist die 6.5.4.

Hat jemand eine Idee, was wir noch checken könnten, bzw. welche Maßnahmen erfolgsversprechend sein könnten. Mit unserem Supporter für die IQ-Suite stehen wir bisher recht erfolglos im Kontakt.

Vielen Dank im Voraus.

Gruß
Thomas

[m3]

Zweite Mailbox?
Blacklists verwenden und die Mails gar nicht annehmen (ist aber gefährlich).

[hallo.dirk]

"check in Progress"deutet schon auf die IQ Suite hin.

Habt ihr Auswahlregeln die Texte in Feldern suchen?
Arbeitet Ihr mit Wall-Wortlisten?

[Norton]

@m3: wir haben zwei Mailboxen, habe ich glaube ich zu versteckt erwähnt. Aber ob eine dritte oder vierte Mailbox unser Problem löst glaube ich eher nicht. Oder übersehe ich etwas?

Blacklists haben wir innerhalb der IQSuite sowohl für Domänen, als auch personalisierte, aber diese wandern halt in eine Quarantäne-Datenbank, damit wir unseren Benutzern keine an Sie addressierten Mails vorenthalten.

@hallo.dirk: Ja, wir arbeiten sowohl mit Wortlisten, seit einiger Zeit auch mit der Suche nach einem String (Firmenname) in dem Feld "TKFlag99" (Feld wird bei Mailfreigabe aus Quarantäne gesetzt) als auch mit einer Core-Analyse, die die Aufbaustruktur der Mails analysiert. Könnte dies etwa das Problem sein?
Ein Abschalten dieser Funktionen würden den dramatisch großen Teil der Spam-Mails wieder durchlassen, zumal die Erkennungsqoute soweit wir das beurteilen können recht zufriedenstellend ist. >95%

Die CPU-Auslastung ist übrigens nicht dramatisch und auch Speicher ist noch ausreichend vorhanden.

[m3]

Wie gehts dem Disk I/O? Ev. braucht ihr ein paar Spindeln mehr?

[Norton]

Die sind in Ordnung. Die haben wir vor einiger Zeit mal optimiert, weil wir massive Probleme hatten. Mit der Verbesserung des SAN ist dies kein Problem mehr. Auch die sonstigen Zugriffe und Tätigkeiten erledigt der Server ohne irgendwelche Auffälligkeiten, lediglich der Mailversand ist häufig mehr als ärgerlich langsam.

[hallo.dirk]

"TKFlag99" (Feld wird bei Mailfreigabe aus Quarantäne gesetzt) als auch mit einer Core-Analyse, die die Aufbaustruktur der Mails analysiert. Könnte dies etwa das Problem sein?

Ich glaube nicht, nein ich hab mal den Fehler gemacht im Body Feld etwas zu suchen, das mochte der Grabber nun gar nicht ...

Wie gross ist den dein Q Db? Hast Du eine oder mehrere?
M3 meinte übrigens BL aufgrund von IP's, Mails von diesen IP werden gar nicht erst angenommen.
Bei mir sind das im Monat so ca 1.2 -1.7 Mio Verbindungsversuche die auf diese Art scheitern.

[blizzard]

das hat mit cpu und i/o rein gar nix zu tun.

Die IQ Suite beackert jedes Mail mit der Anzahl der Jobs die hinterlegt sind.
Wieviel tm_grabs hast du am laufen? Wahrscheinlich standard 5, wenn ja erhöhe dies bitte auf 8 und mache einen reinit. Nicht mehr wie 8 nehmen, da sonst die Effektivität verloren geht.

Habt ihr zufällig auch das Clustering lizensiert? Wenn ja könnt ihr Server zusammenschalten und die können dann sich gegenseitig helfen.

Habt ihr generell Probleme mit langsamem abarbeiten von Mails auch ohne die Spamwellen?
Wenn ja, dann stimmt mit einer der Datenbanken, die hinter den Jobs liegen etwas nicht. Evtl. läuft auf einer immer ein compact?


edit: was du vor der BL vielleicht zuerst machen solltest, wäre Mails nur dann annehmen wenn der User im NAB eingetragen ist.

[Norton]

Guten Morgen,

erst einmal danke für die Antworten.

@hallo.dirk:

Wir haben eine Quarantäne-Datenbank für die Spams ohne und eine für die mit Anhängen.
Die DB mit Anhängen ist ca. 3 GB und die ohne 17 GB groß.
Könnte die Größe der Datenbank ein Faktor sein? Ist hier eine Empfehlung für die maximale Größe vorhanden?

@blizzard:

Wir hatten 5 tm_grabs am laufen. Testweise hatten wir mal 10 eingestellt, dies aber ohne nennenswerten Erfolg. Wenn natürlich 8 der Maximalwert sein soll, ist es vielleicht klar, warum es nichts genützt hat. Wir haben vor wenigen Minuten auf den Wert 8 geändert.

Die eingehenden Mails durchlaufen 2 Jobs der IQ.Suite obwohl da noch mehr durchlaufen werden sollten (insbesondere die Spamerkennung). Danach wechseln diese in den Zustand "Continue" und verharren da im Extremfall bis zu einigen Stunden.

Das mit dem lizensierten Clustering müssen wir noch einmal klären, vermutlich ist es im Lizenzpaket aber drin. Ob dies aber so einfach umzusetzen ist, da wir dann unser Konzept anpassen müssen (und wir gerade Urlaubszeit haben) ist noch eine andere Frage.

Das Abarbeiten von Mails ohne Spamwellen hat uns eigentlich noch nie Probleme bereitet, auch wenn mal eine Massenmail (2000 Empfänger) unterwegs war, so wurden diese in relativ schneller Zeit abgearbeitet.

Mit dem Annehmen der Mails nur wenn ein User auch im NAB ist werde ich mal abklären, ob ich ein Okay bekomme. Das hatten wir mal und wurde wieder deaktiviert. Ehrlich gesagt weiß ich aber auch nicht mehr aus welchem Grund das damals deaktiviert wurde. Ich such auf jeden Fall noch einmal raus, wo die Einstellung zu finden ist und kläre das einmal ab.

Ich meld mich wieder, bin aber auch für weitere Anregungen immer dankbar.

Gruß
Thomas

[Norton]

Wir haben das nun eingestellt, dass Mails an Empfänger, die nicht in unserem NAB stehen abgelehnt werden, aber nun schreibt er unsere Server IP in die Nachricht.

Es sieht also so aus: Error transferring to XXX.XXX.XXX.XXX; SMTP Protocol Returned a Permanent Error 550

Wie kann man denn die IP-Nummer ausblenden, dass muss ja nicht unbedingt sein?

Danke und Gruß
Thomas

[m3]

a) Muss das so sein
b) Was stört Dich daran? Wenn Du Deine IP nicht öffentlich machen willst, nimm den Server offline
c) Wenn Du das nicht willst, brauchst Du Blacklists auf IP-Ebene, welche bereits die Annahme von Spam unterbinden (Achtung, ev. auch von legitimen E-Mails).

[monne]

kleiner Tipp am Rande:
wenn möglich schalte für den Eingang den NoSpam Proxy von Net at Work voran.
Der ist wirklich gut und easy in der Konfiguration.
Das hat bei uns seeehr geholfen.

[blizzard]

Noch nen kleinen Tipp zu den Spam DBs, was übrigens nen richtiger Blödsinn bei der Group meiner Meinung nach ist, da je nach Useranzahl weiss Gott wieviel Spams reinlanden.

Wir hatten DBs mit über 50GB. Aber auch schon 17GB ist auch nicht gerade so toll. Da dort immer wieder neue reinkommen und die Ansichten neu aufbereitet werden. Die User haben zusätzlich natürlich nicht Rechte auf alle Spams und deshalb dauert das ewig. Performance geht gegen 0. Sowohl die der Grabber als auch die der DB selbst.

Deswegen hab ich damals die DB in den replication settings den space saver aktiviert. Alle Mails älter als 30 Tage löschen. Das bringt enorm und die User haben trotz Urlaub auch noch 30 Tage Zeit false positives rauszufischen, welche je nach Spamjob bei der Group leider häufig der Fall sind.

Clustering kostet normal extra und ist auch nicht ganz billig. Konfiguriert ist es jedenfalls in ein paar Minuten.

Ja m3 hat da voll recht, das gehört so. Die IP von deinem Serverchen ist ja sowieso schon über die mx records bekannt, von daher ist das also praktisch wurst.

[Norton]

Erst einmal noch vielen Dank für die weiteren Antworten.

Zum Stand jetzt sind die Mailboxen nach einigen Tagen endlich einmal vorübergehend leer.
Vielleicht war die Erhöhung der TM-Grabs auf 8 und das Ablehnen nicht vorhandener Adressen schon die fehlende Lösung.

@m3: Nun gut, leben wir halt mit der IP. Ist schon richtig, dass Sie eh bekannt ist. Dennoch fand ich es nicht so toll, dass Sie sooo offensichtlich genannt wird.

@monne: Ich werd mich mal schlau machen, was genau dahintersteht. Danke auf jeden Fall für den Tipp.

@blizzard: Die Einstellung bezgl. Löschung nach 30 Tagen ist bei uns auch schon genauso gesetzt. Umso schlimmer sind die 17 GB. Wir haben uns überlegt, dass wir eine Kopie der Datenbank machen und die Mails älter als 14 Tage erstmal aus der produktiven DB entfernen und in den seltenen Fällen die Mails halt selbst weiterleiten.

Thema Clustering ist interessant. In die Richtung werden wir uns auf jeden Fall noch Informationen einholen und uns damit beschäftigen.

[Norton]

...das Thema kann ich dann erst einmal als erledigt betrachten. Ich hoffe, dass es das war.

Vielen Dank noch einmal an alle!