Tag Archives: spamBlocker

Lizensierungsproblem bei FireCluster unter XTM v11.0 und 11.0.1

Comment

In den Versionen Fireware XTM 11.0 und 11.0.1 gibt es im Active/Passive Clusterbetrieb aktuell ein Lizensierungsproblem beim Einsatz der UTM Services. Grundsätzlich reicht es im Active/Passive Modus aus, dass die UTM Services nur auf der PRIMARY Box lizensiert sind. Für die SECONDARY Box reicht die “nackte” Live Security aus. Findet unter 11.0 und 11.0.1 jedoch ein Failover auf die Secondary Box statt, funktionieren die UTM Services WebBlocker, spamBlocker und Gateway Antivirus/IPS dann nicht, da ein Bug die UTM Lizenzen nicht korrekt auf die Secondary Box synchronisiert und die Services dann einfach nicht angewendet werden… Dieser Bug wird mit Version 11.0.2 behoben. Betroffene Kunden können sich in der Zwischenzeit von Customer Care eine temporäre Lizenz für die Secondary Box ausstellen lassen.

E-Mails ohne Datum und Uhrzeit (POP3-proxy)

Comment

Gelegentlich kommt es vor, dass der POP3-proxy zur Abholung von E-Mails bei einem externen Provider eingesetzt wird. In Verbindung mit den UTM Services Gateway Antivirus und spamBlocker macht das natürlich Sinn. spamBlocker kann bei POP3 jedoch nur mit der Option “Tagging” verwendet werden, also das Schreiben eines Zusatzes in die Betreffzeile, z.B. [SPAM?]. “Deny” macht technisch keinen Sinn, da die E-Mails ja bereits auf dem zuständigen Mailserver beim Provider stehen und dort auch abgeholt werden müssen. “Quarantine” wäre technisch zwar denkbar, steht bei POP3 aber leider auch nicht zur Verfügung.

Wenn der POP3-proxy mit seinen Default-Einstellungen verwendet wird, führt dies mitunter dazu, dass die abgeholten E-Mails ohne Sende-Datum/Uhrzeit im Mailclient (z.B. Outlook) angezeigt werden (“Keine Angabe”). Dies liegt dann vermutlich daran, dass der diesbezügliche Header vom POP3-proxy entfernt wurde, weil er nicht auf der Allow-Liste steht. Fügen Sie in diesem Fall einmal den Wert Date:* in die Liste der erlaubten Header ein.

Sollten Sie ein ähnliches Problem haben – irgendetwas geht bei Verwendung des POP3-proxy nicht mehr, das aber vorher mit einem POP3 Paketfilter geklappt hat – dann ist es sicher eine gute Idee, das Häkchen bei “Log” neben der “Strip” Action zu setzen und im Traffic Monitor mitzuverfolgen, welche eventuell doch benötigten Header noch auf der Strecke bleiben. Diese können dann in die Allow-Liste eingepflegt werden. Auch ein Blick in die “Header”-Sektion des SMTP-proxy (!) und ein entsprechender Vergleich lohnt sich gegebenenfalls…