Status von Spam beim Schließen
Hallo zusammen,
wie handhabt ihr Spam Mails, die in OTRS eingehen? Wenn ich die dazugehörigen Tickets schließe, kann ich aktuell nur den Satus erfolgreich/nicht erfolgreich angeben, aber das würde u.U. ein paar Statistiken verwässern; wenn ich z.B. alle Spams erfolgreich schließe ... :)
Oder kann ich noch einen eigenen Status konfigurieren?
Was wäre eure Lösung hierfür?
Danke und Grüße . Götz
Hi Götz,
Wir verschieben die Mails in "_Junk", und schliessen das Mail. Mit einem Job löschen wir in regelmässigen Abständen alle geschlossenen "_Junk". Nach dem Löschen der Mails sind diese nicht mehr für OTRS relevant.
Gruss
Rudolf Bargholz
-----Ursprüngliche Nachricht----- Von: otrs-de [mailto:otrs-de-bounces@lists.otrs.org] Im Auftrag von Götz Reinicke - IT Koordinator Gesendet: Freitag, 25. November 2016 15:58 An: User questions and discussions about OTRS.org in German otrs-de@otrs.org Betreff: [otrs-de] Status von Spam beim Schließen
Hallo zusammen,
wie handhabt ihr Spam Mails, die in OTRS eingehen? Wenn ich die dazugehörigen Tickets schließe, kann ich aktuell nur den Satus erfolgreich/nicht erfolgreich angeben, aber das würde u.U. ein paar Statistiken verwässern; wenn ich z.B. alle Spams erfolgreich schließe ... :)
Oder kann ich noch einen eigenen Status konfigurieren?
Was wäre eure Lösung hierfür?
Danke und Grüße . Götz
On 25.11.2016 15:59, Rudolf Bargholz wrote:
Wir verschieben die Mails in "_Junk", und schliessen das Mail. Mit einem Job löschen wir in regelmässigen Abständen alle geschlossenen "_Junk".
Ich halte es ähnlich, mit dem Unterschied, dass die Spam-Tickets nicht geschlossen werden. Die Löschfunktion kann auch offene Tickets aus dem System entfernen.
-Ralph
Am 25.11.16 um 16:05 schrieb Ralph Seichter:
On 25.11.2016 15:59, Rudolf Bargholz wrote:
Wir verschieben die Mails in "_Junk", und schliessen das Mail. Mit einem Job löschen wir in regelmässigen Abständen alle geschlossenen "_Junk".
Ich halte es ähnlich, mit dem Unterschied, dass die Spam-Tickets nicht geschlossen werden. Die Löschfunktion kann auch offene Tickets aus dem System entfernen.
Klingt nach dem, was wir brauchen könnten. Wo und wie könnte ich so einen Job einrichten? ICh bin so selten in OTRS Backend und Config unterwegs, das ein Hinweis mir sehr helfen würde.
Danke und Grüße . Götz
Am 25.11.2016 um 16:12 schrieb Götz Reinicke - IT Koordinator:
Am 25.11.16 um 16:05 schrieb Ralph Seichter:
On 25.11.2016 15:59, Rudolf Bargholz wrote:
Wir verschieben die Mails in "_Junk", und schliessen das Mail. Mit einem Job löschen wir in regelmässigen Abständen alle geschlossenen "_Junk".
Ich halte es ähnlich, mit dem Unterschied, dass die Spam-Tickets nicht geschlossen werden. Die Löschfunktion kann auch offene Tickets aus dem System entfernen.
Klingt nach dem, was wir brauchen könnten. Wo und wie könnte ich so einen Job einrichten? ICh bin so selten in OTRS Backend und Config unterwegs, das ein Hinweis mir sehr helfen würde.
Admin -> GenericAgent -> Neuer Job ->
Name setzen Ticketfilter: Queue: Junk Kommando ausführen: Ticket löschen: Ja
Viele Grüße, Renée
Am 25.11.16 um 16:14 schrieb Renee B:
Am 25.11.2016 um 16:12 schrieb Götz Reinicke - IT Koordinator:
Am 25.11.16 um 16:05 schrieb Ralph Seichter:
On 25.11.2016 15:59, Rudolf Bargholz wrote:
Wir verschieben die Mails in "_Junk", und schliessen das Mail. Mit einem Job löschen wir in regelmässigen Abständen alle geschlossenen "_Junk".
Ich halte es ähnlich, mit dem Unterschied, dass die Spam-Tickets nicht geschlossen werden. Die Löschfunktion kann auch offene Tickets aus dem System entfernen.
Klingt nach dem, was wir brauchen könnten. Wo und wie könnte ich so einen Job einrichten? ICh bin so selten in OTRS Backend und Config unterwegs, das ein Hinweis mir sehr helfen würde.
Admin -> GenericAgent -> Neuer Job ->
Name setzen Ticketfilter: Queue: Junk Kommando ausführen: Ticket löschen: Ja
Klasse, Danke ! :)
/G
Hallo.
Am 25.11.2016 um 15:59 schrieb Rudolf Bargholz <bargholz@onlinetravel.chmailto:bargholz@onlinetravel.ch>:
Wir verschieben die Mails in "_Junk", und schliessen das Mail. Mit einem Job löschen wir in regelmässigen Abständen alle geschlossenen "_Junk". Nach dem Löschen der Mails sind diese nicht mehr für OTRS relevant.
Das haben wir eine Zeitlang genauso gemacht. Ich bin aber davon abgegangen, weil dadurch die Konsistenz des Systems nicht mehr gegeben ist. „Unbequeme“ Tickets können so einfach entsorgt werden, ohne weitere Spuren zu hinterlassen, abgesehen vom OTRS-Log, das aber in der Regel nur die ersten Zeichen des Betreffs enthält. Statt dessen habe ich einen GenericAgent, der Event-basiert bei Verschieben in Junk ein Ticket direkt schließt. In Junk verbleibt es dann auf „ewig“, d.h. bis es durch einen manuellen Aufräumen-Job (alles älter X Jahre) gelöscht wird.
Gruß / Regards — Jan Dreyer
On 25.11.2016 16:23, Jan.Dreyer@bertelsmann.de wrote:
Ich bin aber davon abgegangen, weil dadurch die Konsistenz des Systems nicht mehr gegeben ist. „Unbequeme“ Tickets können so einfach entsorgt werden, ohne weitere Spuren zu hinterlassen [...]
Hereinkommende E-Mails für OTRS landen hier in zwei IMAP-Konten. Das erste Konto wird von OTRS benutzt und somit permanent geleert. Auf das zweite IMAP-Konto haben die OTRS-Benutzer keinen Zugriff, und dort wird nur bei Bedarf händisch aufgeräumt. Es liegen also immer Kopien im "Rohzustand" vor. Hauptgrund dafür ist nicht, dass Misstrauen gegenüber den OTRS-Benutzern bestünde, sondern die Möglichkeit, die Spam-Erkennung zu verbessern, indem unmodifizierte Nachrichten in Ham/Spam Korpora überführt werden. OTRS selbst bietet m.W. weiterhin keine Möglichkeit, aus IMAP importierte Nachrichten in Ordner zu verschieben statt sie zu löschen, also muss ein zweites IMAP-Konto herhalten.
-Ralph
Am 25.11.2016 um 16:40 schrieb Ralph Seichter:
OTRS selbst bietet m.W. weiterhin keine Möglichkeit, aus IMAP importierte Nachrichten in Ordner zu verschieben statt sie zu löschen, also muss ein zweites IMAP-Konto herhalten.
http://opar.perl-services.de/dist/IMAPMove könnte helfen ;-)
- Renée
On 25.11.2016 23:06, Renee B wrote:
http://opar.perl-services.de/dist/IMAPMove könnte helfen ;-)
Das sieht interessant (und brandneu) aus. ;-) Darf ich vorschlagen, dass der Rückgabewert von $IMAPObject->copy() geprüft und ggf. eine Fehler- meldung geloggt wird?
Ideal fände ich, wenn bei konfiguriertem Kopie-Ordner zuerst die Kopie erstellt und die Originalnachricht nur nach erfolgreichem Kopieren in OTRS übernommen und anschließend gelöscht wird. Geht die Kopie schief, verbleibt das Original somit in der Inbox und wird beim nächsten Lauf erneut verarbeitet, erzeugt aber keine Doubletten innerhalb von OTRS.
'tschuldigung, falls das unbescheiden klingt. :-)
-Ralph
Am 26.11.2016 um 12:55 schrieb Ralph Seichter:
On 25.11.2016 23:06, Renee B wrote:
http://opar.perl-services.de/dist/IMAPMove könnte helfen ;-)
Das sieht interessant (und brandneu) aus. ;-) Darf ich vorschlagen, dass der Rückgabewert von $IMAPObject->copy() geprüft und ggf. eine Fehler- meldung geloggt wird?
Ideal fände ich, wenn bei konfiguriertem Kopie-Ordner zuerst die Kopie erstellt und die Originalnachricht nur nach erfolgreichem Kopieren in OTRS übernommen und anschließend gelöscht wird. Geht die Kopie schief, verbleibt das Original somit in der Inbox und wird beim nächsten Lauf erneut verarbeitet, erzeugt aber keine Doubletten innerhalb von OTRS.
'tschuldigung, falls das unbescheiden klingt. :-)
Danke für das Feedback. Ich werde das im Laufe der Woche umsetzen.
- Renée
-Ralph
OTRS mailing list: otrs-de - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs-de To unsubscribe: http://lists.otrs.org/mailman/listinfo/otrs-de
Am 26.11.2016 um 12:55 schrieb Ralph Seichter:
Ideal fände ich, wenn bei konfiguriertem Kopie-Ordner zuerst die Kopie erstellt und die Originalnachricht nur nach erfolgreichem Kopieren in OTRS übernommen und anschließend gelöscht wird. Geht die Kopie schief, verbleibt das Original somit in der Inbox und wird beim nächsten Lauf erneut verarbeitet, erzeugt aber keine Doubletten innerhalb von OTRS.
'tschuldigung, falls das unbescheiden klingt. :-)
https://github.com/reneeb/otrs-IMAPMove/commit/880569a0b2565e09a994bdede151d...
- Renée
participants (5)
-
Götz Reinicke - IT Koordinator -
Jan.Dreyer＠bertelsmann.de -
Ralph Seichter -
Renee B -
Rudolf Bargholz