gerade war es wieder soweit - der Versuch des geheimen Verbindungsaufbaus an infonotary.com.
Überprüfe bitte die POP3-Einstellungen in TB!, vielleicht hast du eine Adresse bzw. den Port falsch eingegeben.
Ansonsten kann ich nur das wiederholen, was ich schon im meinem letzten Posting geschrieben habe.
Die einzigen Verbindungen, die Phalanx öffnet, sind jene, die von TB! über den Phalanx-Server beim Abfragen der Nachrichten geöffent werden. Dabei wird LDAP nicht unterstützt. Es können nur POP3-Verbindungen aufgebaut werden (normalerweise Port 110 bzw. 995).
All diese Verbindungen müssen vom Benutzer in den Konteneinstellungen von TB! konfiguriert werden. Von sich aus öffnet Phalanx keine Verbindung zu einem anderen Rechner.
Kann man auch ein Makro erstellen, dass keinen vordefinirten Text ausrichtet, sondern den, den ich später verfassen werde, also so etwas wie z.B. "%XMP_StrWrap(C)" würde den Text zentriert darstellen?Das meinte ich auch in dem anderen Thread.
Mir ist keine Möglichkeit bekannt - weder mit einem Plugin, noch manuell im Nachrichteneditor.
Da musst du wohl bei RitLabs nachfragen.
Version 1.1.91:
[+] Dem Makro "%XMP_StrWrap" kann nun optional ein dritter Parameter übergeben werden, der die Ausrichtung des Textes (links/rechts/zentriert/Blocksatz) steuert.
Download auf der Produktseite.
derzeit wird in den Protokollen UTC-Zeit angegeben. Hier sollte m.E. die Zeit gem. Zeitzone des Rechners angezeigt werden.
In der neuen Version 1.1 kann jetzt wahlweise die UTC-Zeit oder die lokale Systemzeit bei der Protokollierung verwendet werden.
derzeit wird in den Protokollen UTC-Zeit angegeben. Hier sollte m.E. die Zeit gem. Zeitzone des Rechners angezeigt werden.
Die Protokolle sind vorwiegend zur Fehlersuche gedacht. Darum finde ich UTC-Zeiten besser.
Ich werde es mir aber vormerken, eventuell werde ich das einstellbar machen.
Kann es sein, dass Regula und das TheBat AVG 8-Plugin sich stören?
Siehe https://www.batboard.net/index.php?PHPS…g88904#msg88904
Regula verschiebt keine Nachrichten, es übergibt TB! nur den Score und TB! verschiebt diese bei Bedarf.
Nachdem AV-Plugins direkt auf Nachrichten-Dateien von TB! (Temp-Dateien) zugreifen, würde ich eher vermuten, dass das AV-Plugin was macht, was TB! nicht gefällt...
Und für wann ist sie geplant?
Ein Termin steht dafür nicht fest.
Allerdings habe ich es auch nicht wirklich eilig...
Mittlerweile versenden Spammer auch manchmal mit den eigenen (meine) Absenderadressen.Meine Adressen sind in der Whitelist.txt. Spamassassin markiert den Header mit
X-Spam-Flag: YES
Die Regel ist im EasyMode als Spam gesetzt.Trotzdem wird es in Regula zu Ham wg. des Whitelisteintrags.
Wie kann ich das verhindern, dass die Whitelist Priorität hat (ich weiß seltsame Logik)?
Wenn du den Easy-Mode in den Einstellungen deaktivierst kannst du in der Datei "Rules.dat" die Reihenfolge der einzelnen Filter selbst festlegen. Wenn du die Regel für den Spamassassin vor der Whitelist-Regel einfügst, ist dein Problem gelöst.
Andererseits solltest du die Received-Zeilen dieser Mails überprüfen. Wenn als Absender z.B. xxx@meinedomain.tld eingetragen ist, steht in einer Received-Zeile meist auch "Received: by meinedomain.tld" - also der Domainnamen statt des Hostnamens. Auch damit kann man solche Mails gut herausfiltern.
Die Umlaute in meinen empfangenen Nachrichten werden durch Phalanx verstümmelt
Das ist nicht möglich, da der Inhalt der Nachricht nicht verändert wird.
Wird jetzt hierdurch Regula nicht mehr weiterentwickelt und in der kommenden Version 4.1 xx nicht mehr funktionieren oder gibt es wie im Dezember schon mal geschrieben für die neue Version von TB wieder ein Plugin.
Was RitLabs in der Version 4.1 ändern wird weiß ich nun wirklich nicht...
Wir werden es sehen, wenn es soweit ist.
Aber existiert keine API, um auf die bereits entschlüsselten Adressbücher zurückzugreifen?
Dazu musst du dich an RitLabs wenden, ich habe keinen Einfluss auf den Funktionsumfang der Plugin-API.
Phalanx steht jetzt als Final zum Download unter http://www.gaijin.at/dlphalanx.php bereit.
In der nächsten Version werden diese Formatierungen als Parameter im Makro "%XMP_StrWrap" möglich sein.
Verschlüsselte Adressbücher (EDB) können auf Grund der Verschlüsselung nicht ausgelesen werden. S.h. dazu auch https://www.batboard.net/index.php?topi…g65964#msg65964
Wo finde ich das Protokoll?
Im Ordner "Logs\Filter.log".
Unter Vista lastet das lernen neuer Mails mein System extrem aus.Da ich immer so 500 Mails auf einen Schwung abhole dauert das Filtern dann fast ne Stunde.
Kann man das irgendwie beschleunigen?
Unter Vista kann ich das Plugin nicht testen...
Wenn es am Hinzufügen von Nachrichten zur Bayes-Datenbank liegt, solltest du die Datenbank aufräumen (in den Optionen) oder - falls das nicht hilft und die Datenbank sehr groß ist - die Datenbank löschen und mit 200 oder 300 Spam/Ham neu anlernen.
Vielleicht liegt es aber auch an vielen DNSBL-/URLBL-Abfragen...
Wenn du mir einige Nachrichtenblöcke aus dem Protokoll schicken kannst, kann ich dir vermutlich mehr sagen.
Kann man das Plugin für einen einzelnen Account deaktivieren?
Diese Möglichkeit stellt TB! für Plugins nicht zur Verfügung.
Eine neue Version ist verfügbar:
Version 0.9.0.2:
[+] Protokoll-Ansicht: In der Protokoll-Ansicht wurde ein Menü zum Öffnen anderer Protokolldateien hinzugefügt.
[*] Optionen: Kleinere Änderungen an der Programmoberfläche und der Sortierung der internen Regeln.
[-] Bayes: Die automatische Entfernung von alten korrigierbaren Nachrichten funktionierte nicht richtig.
(Zu finden im Beta-Bereich meiner Seite.)
Liese sich das vielleicht mit einem TB! Plugin lösen oder ist das ein Ding der Unmöglichkeit?
Das sollte möglich sein.
Angenommen ich finde die mindestens notwendigen Dateien, so wäre der Aufwand, zumindest während der Beta-Phase unverhältnismäßig hoch. Bei jeder Änderung müsste das Programm immer wieder mit diesem Mini-.NET getestet werden. Wenn eine Datei fehlt, muss das Paket von jedem Benutzer wieder neu heruntergeladen werden - falls MS das Veröffentlichen eines zerstückelten .NET überhaupt gestattet. Wie auch immer, der Aufwand rentiert sich vorerst keinesfalls.
