Guten Morgen, Vorne weg gleich mal: Ein tolles Produkt! Weiter so! Leider ist das eMail Archiev nicht durchsuchbar, oder es ist einfach noch zu früh. Deswegen frage ich einfach mal. Wir alle sind uns ja des Spam Problems bewußt. Mein Helpdesk wird regelrecht zugemüllt damit. Um eMails in die DB zu bekommen, benutze ich PostMaster.pl Bevor dies jedoch geschieht wandert sie (wie jede andere auch) durch SpamAssassin und bekommt dort ein zusätzliches Header Field "X-Spam-Flag: YES" Es sollte doch möglich sein, einfach alle eMails mit diesem Header zu ignorieren? Gibts sowas vielleicht schon? Ich habe gesehen, hier lesen auch Developer mit. Gibt es vielleicht ein Diff, was ich 'applyen' kann? Das wäre wunderbar und würde das Produkt abrunden. Tausend Dank, Gruß -- Michael Kunze http://www.smrealms.de/ Humor nam je u krvi, mnogi nam se smeju
On Wednesday, January 21, 2004 9:57 AM
Michael Kunze
Vorne weg gleich mal: Ein tolles Produkt! Weiter so!
Danke sehr!
Leider ist das eMail Archiev nicht durchsuchbar, oder es ist einfach noch zu früh. Deswegen frage ich einfach mal.
Wir sind voll "vergoogled": http://google.de/search?q=spam+mails+site%3Alists.otrs.org
"X-Spam-Flag: YES" Es sollte doch möglich sein, einfach alle eMails mit diesem Header zu ignorieren? Gibts sowas vielleicht schon?
Der übliche Weg ist, die Mails per Procmail (http://www.procmail.org/) in eine Spam-Queue zu verschieben. Dies sollte bei der Einrichtung helfen: http://doc.otrs.org/cvs/de/html/receiving-email-filter-module.html http://doc.otrs.org/cvs/de/html/receiving-email-procmail.html Ich persönlich lasse die Tickets in der 'Spam' Queue nach 2 Tagen eskalieren, dann per GA (/opt/otrs/bin/GenericAgent.pm) schliessen und nach Junk::delete verschieben, wo sie den Weg derer gehen, die /dev/null heiligen ;) So habe ich eine 2-tägige Kontrollmöglichkeit, falls ein FN drin gelandet sein sollte. Falls Du Deinem SpamAssassin 100%ig vertraust, kannst Du auch ganz hart in Deiner .procmailrc dies setzen: :0 : /dev/null Dafür würde ich aber SpamAssassin anweisen, wenigstens Backups der Spam-Mails vorzuhalten. Your Choice.
Ich habe gesehen, hier lesen auch Developer mit. Gibt es vielleicht ein Diff, was ich 'applyen' kann? Das wäre wunderbar und würde das Produkt abrunden.
Die Developer-Liste ist hier: http://lists.otrs.org/cgi-bin/listinfo/dev In der Version 1.2 oder im aktuellen CVS Head gibt es die Möglichkeit, ohne Procmail innerhalb von OTRS zu filtern. Aus CHANGES (http://cvs.otrs.org/cvsweb.cgi/~checkout~/otrs/CHANGES?rev=1.96): - (2003/11/01) added PostMaster(POP3).pl filter options like procmail. Example for Kernel/Config.pm: # Job Name: 1-Match # (block/ignore all spam email with From: noreply@) $Self->{'PostMaster::PreFilterModule'}->{'1-Match'} = { Module => 'Kernel::System::PostMaster::Filter::Match', Match => { From => 'noreply@', }, Set => { 'X-OTRS-Ignore' => 'yes', }, }; hth, Robert Kehl -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Tel. +49 (0)6172 4832388
Robert Kehl wrote:
In der Version 1.2 oder im aktuellen CVS Head gibt es die Möglichkeit, ohne Procmail innerhalb von OTRS zu filtern. Aus CHANGES
Danke für die schnelle ANtwort. Nicht nur gutes Tool, sondern auch noch 1a Support! *g* Gibt es denn schon Erfahrungen mit dem Update von (ich benutzt 1.1.2) auf die CVS Version? Sind die soweit kompatibel? Ich gehe mal davon aus, dass dies hier "DBUpdate-to-1.2.mysql.sql" mein Einstiegspunkt ist. Für Hinweise auf evt. Stolpersteine wäre ich dankbar. Gruß, -- Michael Kunze http://www.smrealms.de/ There are always bozos with guns...more than willing to ruin our day.
On Wednesday, January 21, 2004 3:39 PM
Michael Kunze
Gibt es denn schon Erfahrungen mit dem Update von (ich benutzt 1.1.2) auf die CVS Version?
Nein, scheint im Feld alles gutzugehen. Vorausgesetzt, es leben überhaupt User auf dem "bleeding edge" ;-)
Sind die soweit kompatibel?
Die Motive ("Themes") früherer Versionen sind *nicht* mit der 1.2er kompatibel - gar nicht erst nicht versuchen. Nicht alle Dateien sind davon "betroffen", insbesondere diese sehr häufig geänderten nicht: Standard/CustomerHeader.dtl Standard/CustomerFooter.dtl Standard/CustomerLogin.dtl Mit diesen bestimmst Du die größten Teile des Aussehens des Customer-Frontends.
Ich gehe mal davon aus, dass dies hier "DBUpdate-to-1.2.mysql.sql" mein Einstiegspunkt ist. Für Hinweise auf evt. Stolpersteine wäre ich dankbar.
Achte ganz besonders auf die Punkte 2a bis 2c): 1) Stoppe alles: rcotrs stop-force 2a) Mache ein Backup, mindestens von: Datenbank(!), Kernel/Config.pm, Kernel/Config/GenericAgent.pm, var/* 2b) Du hast ein Backup? 2c) Wirklich?? 3) Installiere/update die Version aus dem CVS. 4) Aktualisiere die Datenbank. MySQL: cat $OTRS_HOME/scripts/DBUpdate-to-1.2.mysql.sql | mysql -p -f -u root otrs PostgreSQL: cat $OTRS_HOME/scripts/DBUpdate-to-1.2.postgresql.sql | psql otrs Keine Sorge wegen evtl. Fehlermeldungen, alles ist gut. 5) $OTRS_HOME/bin/SetPermissions.sh ausführen! 6) Neustart der Software: rcotrs restart-force oder alles einzeln von Hand. Und dann noch diesess: + Kontrolliere/setze die Gruppenberechtigungen nach dem Update auf http://localhost/otrs/index.pl?Action=AdminUserGroup + Wirf die alte Installation erst mal *nicht* weg. + GANZ SCHLECHTE IDEE: Datenbank-Version ungleich OTRS-Version ("getestet") Falls was schief geht: Was haben wir in Punkt 2a) bis 2c) gesagt? hth, Robert Kehl -- ((otrs.de)) :: OTRS GmbH :: Norsk-Data-Str. 1 :: 61352 Bad Homburg http://www.otrs.de/ :: Tel. +49 (0)6172 4832388
participants (2)
-
Michael Kunze -
Robert Kehl