
hallo, leider gibt es bei uns ein paar mails pro tag, die den spam filter unseres providers austricksen. diese landen in unserer eingangs-queue und der dadurch ausgelöste autoreply triggert normalerweise eine "Undelivered Mail Returned to Sender" vom smtp server welche dann wiederum in der eingangs-queue landet. wir hatten die folgende idee: wenn wir jede mail mit dem subject "Undelivered Mail Returned to Sender" nach email addressen parsen und gefundene mit den den absendern der in der eingangs-queue vergleichen können wir sowohl den undelivered mail reply als auch die auslösende mail direkt und automatisch verwerfen. hat das zu fällig schon jemand mal gemacht? vielleicht müssen wir das rad ja nicht zweimal erfinden... mit grüßen, marc schlaile

Hallo Marc, klingt gut. Bin ich auch dran interessiert. Leider haben wir so etwas noch nicht implementiert. Mann könnte ja mal versuchem mit den X-OTRS Headern zu arbeiten. Procmail Filter vor, der sucht nach "Undeliver..." und setzt dann den X-OTRS-Queue header. Der Interessante Punkt hier ist, ob ein Ticket was es schon gibt, dann auch mit in die Queue wandert. Leider kann ich das derzeit nicht ausprobieren, aber vielleicht hast du ja Zeit *G* :) Bye, Robert Heinzmann Marc Schlaile wrote:
hallo,
leider gibt es bei uns ein paar mails pro tag, die den spam filter unseres providers austricksen. diese landen in unserer eingangs-queue und der dadurch ausgelöste autoreply triggert normalerweise eine "Undelivered Mail Returned to Sender" vom smtp server welche dann wiederum in der eingangs-queue landet.
wir hatten die folgende idee: wenn wir jede mail mit dem subject "Undelivered Mail Returned to Sender" nach email addressen parsen und gefundene mit den den absendern der in der eingangs-queue vergleichen können wir sowohl den undelivered mail reply als auch die auslösende mail direkt und automatisch verwerfen.
hat das zu fällig schon jemand mal gemacht? vielleicht müssen wir das rad ja nicht zweimal erfinden...
mit grüßen,
marc schlaile

Hallo, ich habe mal den Source Code des PostMaster.pm durchstöbert und ich denke derzeit ist es nicht möglich, dass ein FollowUp mit einer neuen X-OTRS-Qeueu Kennung Auswirkungen auf das Originalticket hat. Ich denke jedoch das die Implementierbar ist. Ich werde mich mal am Wochenende dransetzen, da der Workflow den du beschrieben bei 99% aller Spams zutrifft und 'ne echt schicke Lösung währe. Bye, Robert Robert Heinzmann wrote:
Hallo Marc,
klingt gut. Bin ich auch dran interessiert. Leider haben wir so etwas noch nicht implementiert.
Mann könnte ja mal versuchem mit den X-OTRS Headern zu arbeiten. Procmail Filter vor, der sucht nach "Undeliver..." und setzt dann den X-OTRS-Queue header. Der Interessante Punkt hier ist, ob ein Ticket was es schon gibt, dann auch mit in die Queue wandert. Leider kann ich das derzeit nicht ausprobieren, aber vielleicht hast du ja Zeit *G* :)
Bye,
Robert Heinzmann
Marc Schlaile wrote:
hallo,
leider gibt es bei uns ein paar mails pro tag, die den spam filter unseres providers austricksen. diese landen in unserer eingangs-queue und der dadurch ausgelöste autoreply triggert normalerweise eine "Undelivered Mail Returned to Sender" vom smtp server welche dann wiederum in der eingangs-queue landet.
wir hatten die folgende idee: wenn wir jede mail mit dem subject "Undelivered Mail Returned to Sender" nach email addressen parsen und gefundene mit den den absendern der in der eingangs-queue vergleichen können wir sowohl den undelivered mail reply als auch die auslösende mail direkt und automatisch verwerfen.
hat das zu fällig schon jemand mal gemacht? vielleicht müssen wir das rad ja nicht zweimal erfinden...
mit grüßen,
marc schlaile
_______________________________________________ OTRS Mailingliste: otrs-de - Webpage: http://otrs.org/ Archiv: http://lists.otrs.org/pipermail/otrs-de/ Listenabo verwalten: http://lists.otrs.org/cgi-bin/listinfo/otrs-de/ Support oder Consulting fuer Ihr OTRS System? => http://www.otrs.de/

hallo robert, herzlichen dank! bin gespannt grüße, marc
Von: Robert Heinzmann
Antworten an: "User questions and discussions about OTRS in German." Datum: Fri, 04 Feb 2005 08:41:29 +0100 An: "User questions and discussions about OTRS in German." Betreff: Re: [otrs-de] spam aussortieren Hallo,
ich habe mal den Source Code des PostMaster.pm durchstöbert und ich denke derzeit ist es nicht möglich, dass ein FollowUp mit einer neuen X-OTRS-Qeueu Kennung Auswirkungen auf das Originalticket hat.
Ich denke jedoch das die Implementierbar ist. Ich werde mich mal am Wochenende dransetzen, da der Workflow den du beschrieben bei 99% aller Spams zutrifft und 'ne echt schicke Lösung währe.
Bye, Robert
Robert Heinzmann wrote:
Hallo Marc,
klingt gut. Bin ich auch dran interessiert. Leider haben wir so etwas noch nicht implementiert.
Mann könnte ja mal versuchem mit den X-OTRS Headern zu arbeiten. Procmail Filter vor, der sucht nach "Undeliver..." und setzt dann den X-OTRS-Queue header. Der Interessante Punkt hier ist, ob ein Ticket was es schon gibt, dann auch mit in die Queue wandert. Leider kann ich das derzeit nicht ausprobieren, aber vielleicht hast du ja Zeit *G* :)
Bye,
Robert Heinzmann
Marc Schlaile wrote:
hallo,
leider gibt es bei uns ein paar mails pro tag, die den spam filter unseres providers austricksen. diese landen in unserer eingangs-queue und der dadurch ausgelöste autoreply triggert normalerweise eine "Undelivered Mail Returned to Sender" vom smtp server welche dann wiederum in der eingangs-queue landet.
wir hatten die folgende idee: wenn wir jede mail mit dem subject "Undelivered Mail Returned to Sender" nach email addressen parsen und gefundene mit den den absendern der in der eingangs-queue vergleichen können wir sowohl den undelivered mail reply als auch die auslösende mail direkt und automatisch verwerfen.
hat das zu fällig schon jemand mal gemacht? vielleicht müssen wir das rad ja nicht zweimal erfinden...
mit grüßen,
marc schlaile
_______________________________________________ OTRS Mailingliste: otrs-de - Webpage: http://otrs.org/ Archiv: http://lists.otrs.org/pipermail/otrs-de/ Listenabo verwalten: http://lists.otrs.org/cgi-bin/listinfo/otrs-de/ Support oder Consulting fuer Ihr OTRS System? => http://www.otrs.de/
_______________________________________________ OTRS Mailingliste: otrs-de - Webpage: http://otrs.org/ Archiv: http://lists.otrs.org/pipermail/otrs-de/ Listenabo verwalten: http://lists.otrs.org/cgi-bin/listinfo/otrs-de/ Support oder Consulting fuer Ihr OTRS System? => http://www.otrs.de/

Hallo, hab da einen kleinen Patch vorbereitet (attached). Dieser erlaubt es, wenn die Konfigurationsoption $Self->{'FollowUpCanChangeQueue'} = 1; gesetzt ist, dass X-OTRS-Queue header in FollowUps die Queue des Tickets ändern. Patch ist für OTRS 1.3.2-01 und verändert: Kernel/System/PostMaster.pm Kernel/Config/Defaults.pm Anwendugsbeispiel: Typischer Spam Bei typischem Spam werden SPAM Mails von einer nicht erreichbaren Absendeadresse über offene Relays verschickt. Besitzt eine Queue eine Autoantwort, so kommt eine Fehlermeldung zurück (Nicht erreichbar etc.). Wenn mann nun diesen Patch anwendet, $Self->{'FollowUpCanChangeQueue'} = 1 setzt kann man einen Procmail Filter vorschalten kann so SPAM teilweise automatisch eingeordnet werden. Der Procmail Filter klassifiziert EMails nach typischen "nicht Erreichbar" Merkmalen und setzt die X-OTRS-Queue auf z.B. "Junk". Damit werden quasi automatisch SPAM emails erkannt und in eine Queue einsortiert, wenn dies auch ein eher pragmatischer Ansatz ist :) Diese "Junk" Queue kann mann dann durch einen Gernericagent Job löschen lassen (oder was mann eben sonst machen will, vielleicht Verklagen ? :). Problematisch sind Antworten von Mailservern, die die Ticketnummer aus dem Subject nehmen. Hier muss eventuell noch in PostMaster->CheckFollowUp ein multipart message scan eingebaut werden. Typischerweise ist in solchen Fällen die Original EMail (die nicht versand werden konnte) als MultiPart Attachment der Fehlermeldung angehangen. Bye, Robert Heinzmann p.s. Sollte das eher an dev@otrs ? Robert Heinzmann wrote:
Hallo Marc,
klingt gut. Bin ich auch dran interessiert. Leider haben wir so etwas noch nicht implementiert.
Mann könnte ja mal versuchem mit den X-OTRS Headern zu arbeiten. Procmail Filter vor, der sucht nach "Undeliver..." und setzt dann den X-OTRS-Queue header. Der Interessante Punkt hier ist, ob ein Ticket was es schon gibt, dann auch mit in die Queue wandert. Leider kann ich das derzeit nicht ausprobieren, aber vielleicht hast du ja Zeit *G* :)
Bye,
Robert Heinzmann
Marc Schlaile wrote:
--- opt/otrs.orig/Kernel/System/PostMaster.pm 2004-10-18 12:14:00.000000000 +0200 +++ opt/otrs/Kernel/System/PostMaster.pm 2005-02-05 12:06:11.000000000 +0100 @@ -224,6 +224,42 @@ State => $Self->{ConfigObject}->Get('PostmasterFollowUpState') || 'open', AutoResponseType => 'auto follow up', ); + # Can a X-OTRS-Queue header in the follow up change the queue for the ticket ? + if ($Self->{ConfigObject}->Get('FollowUpCanChangeQueue')) { + # check if trusted returns a new queue id + my $TQueueID = $Self->{DestQueueObject}->GetTrustedQueueID( + Params => $GetParam, + ); + # X-OTRS-Queue exists + my $TicketQueueID = $Self->{TicketObject}->TicketQueueID(TicketID => $TicketID,); + if ($TQueueID) { + # Only move if not already in X-OTRS-Queue target queue + if ($TicketQueueID ne $TQueueID) { + # Move the ticket to the new Queue + $Self->{TicketObject}->MoveTicket( + QueueID => $TQueueID, + TicketID => $TicketID, + UserID => $Self->{PostmasterUserID}, + ); + $Self->{LogObject}->Log( + Priority => 'notice', + Message => "Moved Ticket $Tn (ID:$TicketID) to queue $GetParam->{'X-OTRS-Queue'} (ID: $TQueueID) (X-OTRS-Queue header)", + ); + } else { + # ticket already in X-OTRS-Queue + $Self->{LogObject}->Log( + Priority => 'notice', + Message => "Ticket $Tn (ID:$TicketID) already in queue $GetParam->{'X-OTRS-Queue'} (ID: $TQueueID) (X-OTRS-Queue header), not moved", + ); + } + } else { + # Queue of X-OTRS-Queue header not found + $Self->{LogObject}->Log( + Priority => 'error', + Message => "Queue \"$GetParam->{'X-OTRS-Queue'}\" from X-OTRS-Queue mail header not found", + ); + } + } } } # create new ticket --- opt/otrs.orig/Kernel/Config/Defaults.pm 2004-10-18 12:14:00.000000000 +0200 +++ opt/otrs/Kernel/Config/Defaults.pm 2005-02-05 12:10:57.000000000 +0100 @@ -1071,6 +1071,9 @@ # (The state if a ticket got a follow up.) [default: open] $Self->{PostmasterFollowUpState} = 'open'; + # FollowUpCanChangeQueue: Can a X-OTRS-Queue header in the follow up change the Queue ? [1/0] default: 0 + $Self->{'FollowUpCanChangeQueue'} = 0; + # X-Header # (All scanned x-headers.) $Self->{'PostmasterX-Header'} = [

Hallo, hab noch glatt was vergessen: Ob das ganze mit POP3 funktioniert ist mir noch nicht klar, konnte ich nicht testen. Theoretisch müsste es gehen, da auch hier der Kernel/PostMaster.pm aufgerufen wird. Der Filter müsste dann aber auf POP3 Seite sein und nicht procmail. Wie ist das bei POP3 OTRS team ? Bye, Robert Robert Heinzmann wrote:
Hallo,
hab da einen kleinen Patch vorbereitet (attached). Dieser erlaubt es, wenn die Konfigurationsoption $Self->{'FollowUpCanChangeQueue'} = 1; gesetzt ist, dass X-OTRS-Queue header in FollowUps die Queue des Tickets ändern.
Patch ist für OTRS 1.3.2-01 und verändert: Kernel/System/PostMaster.pm Kernel/Config/Defaults.pm
Anwendugsbeispiel: Typischer Spam Bei typischem Spam werden SPAM Mails von einer nicht erreichbaren Absendeadresse über offene Relays verschickt. Besitzt eine Queue eine Autoantwort, so kommt eine Fehlermeldung zurück (Nicht erreichbar etc.). Wenn mann nun diesen Patch anwendet, $Self->{'FollowUpCanChangeQueue'} = 1 setzt kann man einen Procmail Filter vorschalten kann so SPAM teilweise automatisch eingeordnet werden. Der Procmail Filter klassifiziert EMails nach typischen "nicht Erreichbar" Merkmalen und setzt die X-OTRS-Queue auf z.B. "Junk". Damit werden quasi automatisch SPAM emails erkannt und in eine Queue einsortiert, wenn dies auch ein eher pragmatischer Ansatz ist :)
Diese "Junk" Queue kann mann dann durch einen Gernericagent Job löschen lassen (oder was mann eben sonst machen will, vielleicht Verklagen ? :).
Problematisch sind Antworten von Mailservern, die die Ticketnummer aus dem Subject nehmen. Hier muss eventuell noch in PostMaster->CheckFollowUp ein multipart message scan eingebaut werden. Typischerweise ist in solchen Fällen die Original EMail (die nicht versand werden konnte) als MultiPart Attachment der Fehlermeldung angehangen.
Bye,
Robert Heinzmann
p.s. Sollte das eher an dev@otrs ?
participants (2)
-
Marc Schlaile
-
Robert Heinzmann