Request Tracker Wiki - User contributions [en]

WriteCustomAction

2016-07-19T17:15:10Z

Medea61: /* Step by step or "Tickets, transactions and attachments" */

This text in Portuguese in [[WriteCustomActionBR]]

How to write custom action code

== Introduction ==

Included in RT3 is the ability to create your own custom ticket actions via the Web UI. The RT3 Custom Scrip capability lets you access the RT API and is a very powerful tool for customising RT.

== Basics ==

[[File:Example1ScripUI.png|thumb|left|325px|Modify a scrip UI]]Let's start with Web UI. Goto Configuration -> Globals -> Scrips -> New Scrip.

The Scrip UI will display the following selectors: Description, Condition, Action, Template and Stage. In the action selector you can pick actions based on files (modules). An outstanding action from this list is "User Defined". The rest of this document describes this action. So in the Action field, select "User Defined" from the menu.

Once you have selected "User Defined" from the Action Field, the following two Action code areas are enabled and used by RT:
* Custom action preparation code
* Custom action cleanup code

When a [[Transaction]] is created, RT does the following steps to enable all this magic and give you a chance to be a small God:

* Select [[Scrip|Scrips]]
* Check applicability of scrips by executing [[Condition]]s
* Execute preparation code scrip by scrip
* Scrips that fail will be thrown away
* Execute commit code of survived scrips proceeding scrip by scrip

When RT executes your perl Action code within this scrip, your code can become an actor upon the ticket. RT has already defined the variable $self. This variable represents an instance of class [=RT::Action::[[UserDefined]]], a subclass of <code>RT::Action::Generic</code>. You can get more info from perldoc and from the source code.

Instance <code>$self</code> provides your Action code with very useful methods:

$self->TransactionObj

Returns <code>RT::Transaction</code> instance, the transaction that has been created and caused all this.

$self->TicketObj

Returns <code>RT::Ticket</code> instance which represents the ticket. Our transaction was applied to it.

$self->TemplateObj

Returns the template (<code>RT::Template</code>) which was selected for this scrip.

=== Getting more info about these objects ===

You can get complete information about these objects from their POD (embedded documentation).

perldoc /opt/rt3/lib/RT/Ticket.pm
perldoc /opt/rt3/lib/RT/Ticket_Overlay.pm
perldoc /opt/rt3/lib/RT/Tickets.pm
perldoc /opt/rt3/lib/RT/Tickets_Overlay.pm
perldoc /opt/rt3/lib/RT/Transaction.pm
perldoc /opt/rt3/lib/RT/Transaction_Overlay.pm
perldoc /opt/rt3/lib/RT/Transactions.pm
perldoc /opt/rt3/lib/RT/Transactions_Overlay.pm
...

== Simple example ==

Ok, let's try to change something.

Requirement: There is a support queue for special customers where each request must have high priority on ticket creation.

[[File:Example1ScripBehavior.png|thumb|275px]]Preparation code:

<nowiki>
# we don't need any preparation yet.
return 1;

</nowiki>

Commit code:

$self->TicketObj->SetPriority( 100 );
return 1;

I hope that this example is understandable enough, but it has at least one weakness. I've hardcoded the priority value. Since RT lets the administrator define default final priority per queue, our code should reflect that.

my $qfp = $self->TicketObj->QueueObj->FinalPriority || 100;
$self->TicketObj->SetPriority( int( $qfp * 0.9 ) );
return 1;

This change to the logic first retrieves the [[FinalPriority]] of the current Queue or 100 if no [[FinalPriority]] is set for the Queue. Then it sets the Priority of this ticket to 90% of the retrieved Priority. The final 10% of the priority is reserved for very exclusive, super high priority requests.

== Errors handling ==

It's important to check errors to protect you from headache. Most methods in RT that change something return a tuple ($status, $msg). If $status is not true value then something failed and $msg is error text describing the reason. Let's extend our code:

my $qfp = $self->TicketObj->QueueObj->FinalPriority || 100;
my ($status, $msg) = $self->TicketObj->SetPriority( int( $qfp * 0.9 ) );
unless ( $status ) {
$RT::Logger->error("Couldn't change priority: $msg");
return 0;
}
return 1;

== What you can (not) do with scrips ==

You can manipulate almost any object in RT within a scrip.

* update properties of tickets, for example set properties of tickets with commands in email
* change linked tickets, for example [[OpenTicketOnAllMemberResolve]] and [[OpenDependantsOnResolve]]
* extract info from messages, implement own workflow, create approvals and many-many more actions

Let's talk about impossible things you don't even want to try to do with a scrip:

* you couldn't deny action scrip's triggered, for example you don't want to allow users to open ticket unless it has owner, you may think that you can create scrip "on ticket open block action if ticket has no owner", but it's impossible. I said impossible? no... sure you can create such scrip, but instead of preventing action you can revert it by setting status back to old value. yeah, this works but don't forget that it would be two transactions 'set open status' and 'set previouse status'. Each action could be applied to other scrips, so really it's not preventing action.
* you couldn't run scrip at some time, remember RT runs scrips after creating transactions, but of course we have solution for this situation - rt-crontool.

== How to be silent ==

Now you put SetXxxx calls all over the places in RT and suddenly note that strange transactions appear in tickets. They have creator [[RT System|RT_System]] and describe what you've done with your scrips. Sometimes it's better to be silent and not mislead users. These transactions also go through the steps described earlier and could trigger some conditions too. Just use the long form of SetXxx functions:

$TicketObj->_Set(Field => 'Priority', Value => 90, RecordTransaction => 0);

The zero in the [[RecordTransaction]] argument informs RT not to record the change as a new transaction.

== How to change ticket custom field values ==

Step 1, get the custom field (CF) object or ID. Don't use the hardcoded CF ID from the database. [why?] Step 2, get the CF object by ticket object by ticket object (I hope you remember how to get a ticket object) and CF name.

<pre>
...
my $CFName = 'MyCustomField';
my $CF = RT::CustomField->new( $RT::SystemUser );
$CF->LoadByNameAndQueue( Name => $CFName, Queue => $Ticket->Queue );
# RT has bug/feature until 3.0.10, you should load global CF yourself
unless( $CF->id ) {
# queue 0 is special case and is a synonym for global queue
$CF->LoadByNameAndQueue( Name => $CFName, Queue => '0' );
}

unless( $CF->id ) {
$RT::Logger->error( "No field $CFName in queue ". $Ticket->QueueObj->Name );
return undef;
}
...
</pre>

Now we could add value to ticket:
<pre>
my $Value = 'MyValue';
$Ticket->AddCustomFieldValue( Field => $CF, Value => $Value );
</pre>
or
<pre>
$Ticket->AddCustomFieldValue( Field => $CF, Value => $Value, RecordTransaction => 0 );
</pre>
you also could use custom field id instead of object.
<pre>
$Ticket->AddCustomFieldValue( Field => NN , Value => $Value );
</pre>

== Step by step or "Tickets, transactions and attachments" ==

Lets look what happens with RT from the beginning when a user clicks on create button in their browser. Web server gets request with queue id, ticket subject and body, owner and etc. RT fetches info from the request that is needed for Ticket record: its Queue id, Status, Subject, [[CurrentUser]](Creator), and then runs the next code:

<pre>
# init empty instance of RT::Ticket class
my $TicketObj = RT::Ticket->new( $session{'CurrentUser'} );

# create new record
# if you more familiar with SQL then it's INSERT
# this call is inherited from SearchBuilder API
my $id = $TicketObj->Create( %ARGS );

</pre>

Ticket is created and it's time to record transaction into table. RT has all info for this: ticket's id that was recently created and transaction type - 'Create'.

<pre>
# this call creates new transaction record
# this is very similar to situation with new ticket record
my $TransactionObj = $Ticket->_RecordTransaction( %ARGS );

</pre>

Transactions in RT has an many-to-one mapping with ticket. One ticket => one or more transactions. You can get collection of transactions by calling Transactions method on a ticket object:
<pre>
my $transactions = $TicketObj->Transactions;
</pre>
Each transaction belongs to only one ticket and you get ticket object with the following code:
<pre>
my $ticket = $TransactionObj->TicketObj;
</pre>
As you can see RT still didn't use content that you wrote in the body. Content is an RT::Attachment object. You know how RT creates new record and know about Ticket-Transaction relation, the same relationship applies to Attachments and Transactions.

== From "User Defined" to a module ==

User defined actions you write in the web UI are handy and quick way to write an action. However, at some point you want to re-use your action, make it configurable, edit it in more suitable editor rather than text area, make it more complex and consist of additional methods. So it's time to move from "User Defined" action to your first module file.

use strict;
use warnings;

package RT::Action::MyAction;
use base qw(RT::Action::Generic);

sub Prepare {
my $self = shift;

... here goes preparation code ...

return 1;
}

sub Commit {
my $self = shift;

... here goes commit code ...

return 1;
}

1;

That's it. Save it as [=lib/RT/Action/MyAction.pm](it is important that the file have the same name as the package ("MyAction" in the example)), fill in preparation and commit code then you can register your action in the DB. Use the following data file and [[AddDatabaseRecords]] instructions.

@ScripActions = (
{
Name => 'My super duper action',
Description => 'Super-puper action that does hell of a job' ,
ExecModule => 'MyAction',
Argument => 'some argument if needed'
},
);

Now your action in the DB and you can pick it for a scrip through the Web UI instead of picking "User Defined".

== See also ==

Other documentation on this wiki that may help

[[GlobalObjects]], [[ObjectModel]]

== Special thanks ==

* [[TimWilson]], who was the main editor and reviewer

WriteCustomAction

2016-07-19T17:13:41Z

Medea61: /* How to change ticket custom field values */

This text in Portuguese in [[WriteCustomActionBR]]

How to write custom action code

== Introduction ==

Included in RT3 is the ability to create your own custom ticket actions via the Web UI. The RT3 Custom Scrip capability lets you access the RT API and is a very powerful tool for customising RT.

== Basics ==

[[File:Example1ScripUI.png|thumb|left|325px|Modify a scrip UI]]Let's start with Web UI. Goto Configuration -> Globals -> Scrips -> New Scrip.

The Scrip UI will display the following selectors: Description, Condition, Action, Template and Stage. In the action selector you can pick actions based on files (modules). An outstanding action from this list is "User Defined". The rest of this document describes this action. So in the Action field, select "User Defined" from the menu.

Once you have selected "User Defined" from the Action Field, the following two Action code areas are enabled and used by RT:
* Custom action preparation code
* Custom action cleanup code

When a [[Transaction]] is created, RT does the following steps to enable all this magic and give you a chance to be a small God:

* Select [[Scrip|Scrips]]
* Check applicability of scrips by executing [[Condition]]s
* Execute preparation code scrip by scrip
* Scrips that fail will be thrown away
* Execute commit code of survived scrips proceeding scrip by scrip

When RT executes your perl Action code within this scrip, your code can become an actor upon the ticket. RT has already defined the variable $self. This variable represents an instance of class [=RT::Action::[[UserDefined]]], a subclass of <code>RT::Action::Generic</code>. You can get more info from perldoc and from the source code.

Instance <code>$self</code> provides your Action code with very useful methods:

$self->TransactionObj

Returns <code>RT::Transaction</code> instance, the transaction that has been created and caused all this.

$self->TicketObj

Returns <code>RT::Ticket</code> instance which represents the ticket. Our transaction was applied to it.

$self->TemplateObj

Returns the template (<code>RT::Template</code>) which was selected for this scrip.

=== Getting more info about these objects ===

You can get complete information about these objects from their POD (embedded documentation).

perldoc /opt/rt3/lib/RT/Ticket.pm
perldoc /opt/rt3/lib/RT/Ticket_Overlay.pm
perldoc /opt/rt3/lib/RT/Tickets.pm
perldoc /opt/rt3/lib/RT/Tickets_Overlay.pm
perldoc /opt/rt3/lib/RT/Transaction.pm
perldoc /opt/rt3/lib/RT/Transaction_Overlay.pm
perldoc /opt/rt3/lib/RT/Transactions.pm
perldoc /opt/rt3/lib/RT/Transactions_Overlay.pm
...

== Simple example ==

Ok, let's try to change something.

Requirement: There is a support queue for special customers where each request must have high priority on ticket creation.

[[File:Example1ScripBehavior.png|thumb|275px]]Preparation code:

<nowiki>
# we don't need any preparation yet.
return 1;

</nowiki>

Commit code:

$self->TicketObj->SetPriority( 100 );
return 1;

I hope that this example is understandable enough, but it has at least one weakness. I've hardcoded the priority value. Since RT lets the administrator define default final priority per queue, our code should reflect that.

my $qfp = $self->TicketObj->QueueObj->FinalPriority || 100;
$self->TicketObj->SetPriority( int( $qfp * 0.9 ) );
return 1;

This change to the logic first retrieves the [[FinalPriority]] of the current Queue or 100 if no [[FinalPriority]] is set for the Queue. Then it sets the Priority of this ticket to 90% of the retrieved Priority. The final 10% of the priority is reserved for very exclusive, super high priority requests.

== Errors handling ==

It's important to check errors to protect you from headache. Most methods in RT that change something return a tuple ($status, $msg). If $status is not true value then something failed and $msg is error text describing the reason. Let's extend our code:

my $qfp = $self->TicketObj->QueueObj->FinalPriority || 100;
my ($status, $msg) = $self->TicketObj->SetPriority( int( $qfp * 0.9 ) );
unless ( $status ) {
$RT::Logger->error("Couldn't change priority: $msg");
return 0;
}
return 1;

== What you can (not) do with scrips ==

You can manipulate almost any object in RT within a scrip.

* update properties of tickets, for example set properties of tickets with commands in email
* change linked tickets, for example [[OpenTicketOnAllMemberResolve]] and [[OpenDependantsOnResolve]]
* extract info from messages, implement own workflow, create approvals and many-many more actions

Let's talk about impossible things you don't even want to try to do with a scrip:

* you couldn't deny action scrip's triggered, for example you don't want to allow users to open ticket unless it has owner, you may think that you can create scrip "on ticket open block action if ticket has no owner", but it's impossible. I said impossible? no... sure you can create such scrip, but instead of preventing action you can revert it by setting status back to old value. yeah, this works but don't forget that it would be two transactions 'set open status' and 'set previouse status'. Each action could be applied to other scrips, so really it's not preventing action.
* you couldn't run scrip at some time, remember RT runs scrips after creating transactions, but of course we have solution for this situation - rt-crontool.

== How to be silent ==

Now you put SetXxxx calls all over the places in RT and suddenly note that strange transactions appear in tickets. They have creator [[RT System|RT_System]] and describe what you've done with your scrips. Sometimes it's better to be silent and not mislead users. These transactions also go through the steps described earlier and could trigger some conditions too. Just use the long form of SetXxx functions:

$TicketObj->_Set(Field => 'Priority', Value => 90, RecordTransaction => 0);

The zero in the [[RecordTransaction]] argument informs RT not to record the change as a new transaction.

== How to change ticket custom field values ==

Step 1, get the custom field (CF) object or ID. Don't use the hardcoded CF ID from the database. [why?] Step 2, get the CF object by ticket object by ticket object (I hope you remember how to get a ticket object) and CF name.

<pre>
...
my $CFName = 'MyCustomField';
my $CF = RT::CustomField->new( $RT::SystemUser );
$CF->LoadByNameAndQueue( Name => $CFName, Queue => $Ticket->Queue );
# RT has bug/feature until 3.0.10, you should load global CF yourself
unless( $CF->id ) {
# queue 0 is special case and is a synonym for global queue
$CF->LoadByNameAndQueue( Name => $CFName, Queue => '0' );
}

unless( $CF->id ) {
$RT::Logger->error( "No field $CFName in queue ". $Ticket->QueueObj->Name );
return undef;
}
...
</pre>

Now we could add value to ticket:
<pre>
my $Value = 'MyValue';
$Ticket->AddCustomFieldValue( Field => $CF, Value => $Value );
</pre>
or
<pre>
$Ticket->AddCustomFieldValue( Field => $CF, Value => $Value, RecordTransaction => 0 );
</pre>
you also could use custom field id instead of object.
<pre>
$Ticket->AddCustomFieldValue( Field => NN , Value => $Value );
</pre>

== Step by step or "Tickets, transactions and attachments" ==

Lets look what happens with RT from the beginning when a user clicks on create button in their browser. Web server gets request with queue id, ticket subject and body, owner and etc. RT fetches info from the request that is needed for Ticket record: its Queue id, Status, Subject, [[CurrentUser]](Creator), and then runs the next code:

<nowiki>
# init empty instance of RT::Ticket class
my $TicketObj = RT::Ticket->new( $session{'CurrentUser'} );

# create new record
# if you more familiar with SQL then it's INSERT
# this call is inherited from SearchBuilder API
my $id = $TicketObj->Create( %ARGS );

</nowiki>

Ticket is created and it's time to record transaction into table. RT has all info for this: ticket's id that was recently created and transaction type - 'Create'.

<nowiki>
# this call creates new transaction record
# this is very similar to situation with new ticket record
my $TransactionObj = $Ticket->_RecordTransaction( %ARGS );

</nowiki>

Transactions in RT has an many-to-one mapping with ticket. One ticket => one or more transactions. You can get collection of transactions by calling Transactions method on a ticket object:

my $transactions = $TicketObj->Transactions;

Each transaction belongs to only one ticket and you get ticket object with the following code:

my $ticket = $TransactionObj->TicketObj;

As you can see RT still didn't use content that you wrote in the body. Content is an RT::Attachment object. You know how RT creates new record and know about Ticket-Transaction relation, the same relationship applies to Attachments and Transactions.

== From "User Defined" to a module ==

User defined actions you write in the web UI are handy and quick way to write an action. However, at some point you want to re-use your action, make it configurable, edit it in more suitable editor rather than text area, make it more complex and consist of additional methods. So it's time to move from "User Defined" action to your first module file.

use strict;
use warnings;

package RT::Action::MyAction;
use base qw(RT::Action::Generic);

sub Prepare {
my $self = shift;

... here goes preparation code ...

return 1;
}

sub Commit {
my $self = shift;

... here goes commit code ...

return 1;
}

1;

That's it. Save it as [=lib/RT/Action/MyAction.pm](it is important that the file have the same name as the package ("MyAction" in the example)), fill in preparation and commit code then you can register your action in the DB. Use the following data file and [[AddDatabaseRecords]] instructions.

@ScripActions = (
{
Name => 'My super duper action',
Description => 'Super-puper action that does hell of a job' ,
ExecModule => 'MyAction',
Argument => 'some argument if needed'
},
);

Now your action in the DB and you can pick it for a scrip through the Web UI instead of picking "User Defined".

== See also ==

Other documentation on this wiki that may help

[[GlobalObjects]], [[ObjectModel]]

== Special thanks ==

* [[TimWilson]], who was the main editor and reviewer

TransactionBatchStage

2016-07-19T17:09:48Z

Medea61: /* How it works? */

== Introduction ==

[[ScripExecOrder]] article gives you overview and example about what "stages" is and what happens if scrip in batch stage instead of create stage.

In two words: If [[Scrip]] in batch stage then it's applied only when all transactions of the user's request have been created.

== When do you want to use batch stage ==

* When people resolve tickets they can write a comment, in some setups it's cool to send a notification that the ticket is resolved to requestor and add the comment to the email. RT allows user to leave comment blank or RT as well could create a resolve transaction earlier than a transaction for the comment. In this situation batch stage can help you, you can find example of a template below.
* Another situation when you need batch stage is custom field updates. Consider some page with custom fields change boxes and fields for other manipulations and for example you want set field X on status change. RT sets status (create transaction) in create stage your scrip updates a CF, but then RT reverts this change as it starts [[CFs]] update action which checks if object has values in arguments of the request, the new value is not there then RT deletes it.
* Keep in mind that if your TransactionBatch scrip sends email, the email address of the people notified will '''not''' be visible while users are composing a reply.

== How to enable it? ==

Add to RT_SiteConfig.pm (only needed in RT versions less than 3.8.2 which defaultes this to on)

Set($UseTransactionBatch , 1);

Then restart server to apply changes and now you can set stage for scrips you want to run in batch stage.

== How it works? ==

This is complex [[Template]] that adds "last" comment to email. Template works in both stages, but works better in batch stage cause adds only comment that was added within resolve action only.

<pre>
-------------------- Clever 'resolved' template ----------------------
Subject: Resolved: {$Ticket->Subject}

According to our records, your request has been resolved. If you have any
further questions or concerns, please respond to this message.

{
my $old_user = $Ticket->CurrentUser;
$Ticket->CurrentUser( $RT::SystemUser );
my $batch = $Ticket->TransactionBatch;
my $comment;
if( !$batch || !ref($batch) ) {
$RT::Logger->info("TransactionBatch stage is disabled,
fallback to last comment.
Turn on TransactionBatch stages for acurate results.");
my $transactions = $Ticket->Transactions;
$transactions->Limit( FIELD => 'Type', VALUE => 'Comment' );
$transactions->OrderByCols( { FIELD => 'Created',
ORDER => 'DESC' },
{ FIELD => 'id',
ORDER => 'DESC' } );
$transactions->RowsPerPage(1);
$comment = $transactions->First;
} else {
$comment = (grep { ($_->Type eq 'Comment')? 1: 0;} @$batch)[0];
}
$OUT = " ";
if ( $comment ) {
# Since we're effectively turning this comment into
# correspondence, it is possible to use RT::Record to alter
# history a bit here. This is normally really frowned upon,
# but without this, users may be confused that the reply they
# got by email isn't visible in the Web UI, because they don't
# have the ShowTicketComment right
RT::Record::_Set($comment, ( Field => 'Type', Value => 'Correspond' ));
$OUT = "Resolution:\n";
$OUT .= ("-"x76) ."\n";
$OUT .= $comment->Content;
}
$Ticket->CurrentUser( $old_user );
}
</pre>

You can set the stage on your scrip from the Applies To page in 4.2, or from the Scrip page in 4.0. In 4.2 you can even choose to run scrips in TransactionBatch mode on a per-queue basis.

See also the [http://bestpractical.com/docs/rt/latest/initialdata.html#Scrips Initialdata docs]

SendEmailAction

2016-07-19T17:08:33Z

Medea61:

The following is built into 3.8.X

This action handles the case where you want to send an email to a certain person, but not require that person to be on the ticket. E.g. whenever a ticket is created, you want to send an email to a certain group of people, but not add that group to the ticket.

This action does not require any Perl code, just a database edit. It uses code already in RT.

Create the following file, named [[SendEmailAction]].install:

<pre>
# Used to install a scrip action.
#
# To install,
# execute
# /path/to/rt3/sbin/rt-setup-database --action insert \
# --datafile /path/to/SendEmailAction.install
#
@ScripActions = (
{ Name => 'Send Email',
Description => 'Sends a message to those specified in the template',
ExecModule => 'SendEmail',
Argument => '' },
);
</pre>

As the comments in the file indicate, you "install" this file using the '''rt-setup-database''' utility.

<pre>
rt-setup-database --action insert --datafile SendEmailAction.install
</pre>

Now when you create a scrip, you should have a new action available to you. To use it, first create a template which determines the content of the message you are sending, as well as the person or persons that will be getting this message.

Here is an example of a template you could use:

<pre>
To: user1@example.org, user2@example.org
Bcc: user3@example.org
Subject: {$Ticket->Subject}

A ticket has been created in this queue.

{$RT::WebURL}Ticket/Display.html?id={$Ticket->id}

-------------

{$Transaction->Content()}

</pre>

Now, create a scrip. Set the condition to "on create", the action to "send email", and specify your newly created template.

If your scrip was queue-specific, you may also want to create a scrip handling tickets getting assigned to the queue.

To use this action to send email to the members of an RT Group, use a template like this:

<pre>
To: { my $GroupObj = RT::Group->new($RT::SystemUser);
$GroupObj->LoadUserDefinedGroup('Group Name');
$GroupObj->MemberEmailAddressesAsString()}
Subject: {$Ticket->Subject}

A ticket has been created in this queue.

{$RT::WebURL}Ticket/Display.html?id={$Ticket->id}

-------------

{$Transaction->Content()}
</pre>

== Small problem with v3.8.4 and empty ticket body ==

SendEmail fails with Request Tracker v3.8.4 if the body of the request is empty. For example if using the rt shell to create a ticket (useful for testing) like so:

<pre>
rt create -t ticket set subject='TEST - please ignore' queue='Testing' requestor='address@thing.com'
</pre>

Then the ticket has no content and there is an error message (Ubuntu Karmic puts this is in /var/log/syslog) like:

<pre>
RT: error: unexpected end of header (/usr/share/request-tracker3.8/lib/RT/Template_Overlay.pm:356)
</pre>

BounceMerge

2016-07-19T17:04:41Z

Medea61:

This is a scrip which checks if a newly generated ticket was created by a mail bounce.

If yes, it tries to deduce the original ticket-id and merges this new ticket into the old one.

The scrip logic is quite conservative, only if the same [[TicketID]] is found both in a quoted Message-ID and a RT-Ticket: header, then the scrip merges the tickets.

Note that this requires an accurate Return-Path header. This should normally be added by the final MTA in the chain.

Note also that this causes the logged creation message to be inaccurate, suggesting that the ticket being merged into has just been created.

== Install ==

Condition: On Create

Template: Blank

Custom Condition:

return 1; # n/a

Custom Action Preparation:

return 1;

Custom Action Cleanup Code:

<pre>
#
# Merge mail bounce into old ticket.
#
# Otmar Lendl <ol@bofh.priv.at> 2009/07/24
#
my $ticket = $self->TicketObj;
my $tr = $self->TransactionObj;

# possible sources of ticket-IDs:

# Message-ID of the mail we sent:
# example: Message-ID: <rt-3.8.2-1611-1247727152-952.14150-6-0@CERT.at>
my $msgregex = '<rt-'. $RT::VERSION .'-\d+-\d+-\d+\.(\d+)-\d+-\d+@'. RT->Config->Get('Organization') .'>';

# RT-Ticket: header:
# example: RT-Ticket: CERT.at #14150
my $rttregex = '^RT-Ticket: ' . RT->Config->Get('rtname') .' #(\d+)';

my $Attachments = $tr->Attachments;
# get first attachment
my $a = $Attachments->Next;
return(1) unless ($a);

my $rp = $a->GetHeader('Return-Path');
my $ct = $a->ContentType;

# bounce?
return(1) unless (($rp eq '<>') or ($ct eq 'multipart/report'));
print STDERR "BounceMerge: Looks like a bounce ($rp/$ct). Trying to find ticket-ID.\n";
# .. which is potentially hidden in other attachments. Collect them all first.
my $mail = "";
do {
my $oh = $a->Headers;
my $oc = $a->OriginalContent;
$mail .= "\n----------------- " . $a->id . " ---------\n" . $oh if ($oh);
$mail .= "\n----------------- " . $a->id . " ---------\n" . $oc if ($oc);
} while ($a = $Attachments->Next);

# look for a message-ID:

my $id_msg = -1;
my $id_hdr = -2;

$id_msg = $1 if ($mail =~ /$msgregex/);
$id_hdr = $1 if ($mail =~ /$rttregex/m);

if (($id_hdr == $id_msg) and ($id_hdr != $ticket->EffectiveId) ) {
print STDERR "BounceMerge: Removing requestors and merging into $id_msg\n";
my @reqs = split(/[\s,]+/, $ticket->RequestorAddresses);
foreach (@reqs) {
$ticket->DeleteWatcher(
Type => "Requestor",
Email => $_,
Silent => 1) ;
}
$ticket->MergeInto($id_msg);
}

return(1);
</pre>

It's worth bearing in mind that there are cases where the bounces may not go into the queue you intended. The branch https://github.com/jmdh/rt/tree/3.8%2Fignore_subject_ticket_for_queues may be of interest, if so.

SpamFiltering

2016-07-19T16:28:31Z

Medea61: /* Collect spam/ham for training with procmail */

= Spam Filtering =

By moving all SPAM to a single queue, you can easily purge (shred) it periodically. You might also take the opportunity to purge any RT users who do not have a ticket associated with them.

Please find documented below 6 setups for processing spam (1a-1c, 2a-2c). In general, you want to filter your messages at the MTA, before they get RT if you can.

The list archives also contain a number of [http://www.gossamer-threads.com/lists/rt/users/87056?search_string=Spam filtering in RT;#87056 useful tips]

== 0. Pre-filtering & scoring messages ==

There are a number of ways of doing so, such as procmail or [http://pthbb.org/manual/software/mailfilter mailfilter] which can do other somewhat-RT-specific pre-processing as well.

== 1. Pre-filtered mail ==

There are several options for processing messages once scored:

=== a. Pre-filtered mail + ::Filter::SpamAssassin (=> Spam Queue) ===

http://codepad.org/HQmnr0AG based on

http://documentroot.com/SpamAssassin.pm based on RT::Interface::Email::Filter::SpamAssassin from 3.8.1

This updated version of the filter provides several options for handling potential spam, such as rejecting all messages above a certain score, and filing others in a SPAM queue.

=== b. Pre-filtered mail + Scrip => Queue ===

In the example below a score of 5 or more is needed. Edit preparation code if you want to modify the level.

Create new Scrip using following information:

*Condition: On Create
*Action: User Defined
*Custom action preparation code:
<pre>
# Match ***** level spam. You might want to set this higher/lower if needed
my $match = '\*\*\*\*\*';
my $inMessage = $self->TransactionObj->Attachments->First;
return 0 if (!$inMessage); # if no message attachment - assume web UI
return 0 if (!$inMessage->GetHeader('Received')); # exit if not email message

my $spamLevel = $inMessage->GetHeader('X-Spam-Level');
return ( $spamLevel !~ /$match/i ) ? 0 : 1;
</pre>

*Custom action cleanup code:
<pre>
my $newqueue = 'spam';
my ($status, $msg) = $self->TicketObj->SetQueue($newqueue);
return $status ? undef : 1;
</pre>

=== c. Pre-filtered mail + ProcMail => Spam Queue ===

A procmail recipe (for each queue/(correspond|comment) pair) can be used to send spam to a spam queue in RT. Note that:

* the flags bh need to be set so rt-mailgate sees both the body and header of the message.
* the absence of a second colon so there is no lockfile

<pre>
PATH=/usr/local/bin:/bin/:/usr/bin
LOGFILE=/var/log/procmail.log
#rt-mailgate has already saved the message in the rt database
#set DEFAULT to be somewhere real if you want procmail to save the message elsewhere
DEFAULT=/dev/null

#Messages >300000 characters proceed to recipient (unlikely to be spam)
#:0fwbh
:0wbh
* > 300000
| /usr/local/rt3/bin/rt-mailgate --queue default --action correspond --url http://localhost/

#if the spam trigger is fired send to spam queue
#:0fwbh
:0wbh
* ^X-Spam-Level: \*\*\*\*\*
| /usr/local/rt3/bin/rt-mailgate --queue spam --action correspond --url http://localhost/rt/

#if the spam trigger is not fired then send to expected destination
#:0fwbh
:0wbh
| /usr/local/rt3/bin/rt-mailgate --queue default --action correspond --url http://localhost/rt/
</pre>

=== 2. Unfiltered messages ===

=== a. Unfiltered mail + ::Filter::SpamAssassin (=> Spam Queue) ===

RT::Interface::Email::Filter::SpamAssassin above (1a) can also pass unscored messages off to SpamAssassin for processing.

=== b. Unfiltered mail + ProcMail & SpamAssassin => Spam Queue ===

This procmail recipe is similar to 1c. above, except that it handles previously unscored messages, and accepts many of the rt-mailgate parameters as environment variables so that it may be easily used with multiple aliases.

Aliases:
<pre>
rt: "|/usr/local/bin/procmail -m ACTION=correspond QUEUE=General /usr/local/etc/procmail/rt-deliver.rc"
rt-comment: "|/usr/local/bin/procmail -m ACTION=comment QUEUE=General /usr/local/etc/procmail/rt-deliver.rc"
</pre>

/usr/local/etc/procmail/rt-deliver.rc:

<pre>
#Messages >300000 characters proceed to recipient (unlikely to be spam)
:0w
* > 300000
| /usr/local/rt3/bin/rt-mailgate --queue $QUEUE --action correspond --url http://localhost/rt/

#Is it spam?
:0fw: spamassassin.lock
* < 300000
| /usr/local/bin/spamc

#if the spam trigger is fired send to spam queue
:0w
* ^X-Spam-Status: Yes
| /usr/local/rt3/bin/rt-mailgate --queue Spam --action correspond --url http://localhost/rt/

#if the spam trigger is not fired then send to expected destination
:0w
| /usr/local/rt3/bin/rt-mailgate --queue $QUEUE --action $ACTION --url http://localhost/rt/
</pre>

=== c. ProcMail + SpamAssassin + Scrip => Spam Queue ===

http://www.soundwave.net/~wmono/rt/

== 3. Mis-handled messages ==

=== a. False positives: Greylist ===

2c above outlines a general (non-procmail specific) setup (steps 1 through 6 for RT) to automatically greylist suspect messages. Legitimate requestors may reply to an autoresponse and have their misfiled message requeued.

=== b. False negatives: QuickSpamhandler ===

Note: [[QuickSpamHandler]] seems to no longer be available. The [http://search.cpan.org/~ruz/RT-Extension-ReportSpam-0.02/lib/RT/Extension/ReportSpam.pm RT::Extension::ReportSpam] is fairly similar though.

This extension provides a few tools that can be used for manual triage of SPAM in low-traffic installation, or handling the odd message that leaks through your automated filters:

* Adds alternate forms of the "Unowned Tickets" and "My Tickets" global searches, which exclude messages in the spam queue.
* Adds a link to the "Search - Unowned Tickets" query which permits you to instantly vanquish a ticket if the subject is sufficient to convince you the message is SPAM.
* Adds a link to the Ticket tool bar that will instantly vanquish the displayed ticket.

Vanquished tickets are moved to a designated SPAM queue; the default is named "Possible SPAM".

==== Installation ====

* Download the [http://zephyrgeek.qatar.cmu.edu/RT/QuickSpamHandler.tgz archive]
* Unpack it
* ./configure
* make install
* Read and act on the output from the previous command.

Really, the only tricky bit is the database update. If I ever figure out a better way to do this I'll make sure to update the archive. Hopefully someone will find this useful. If you do, please drop me a line!

=== c. False negatives: Bookmarklet ===

An alternative to QuickSpamHandler above, this bookmarklet moves the displayed ticket to the spam queue (change 12 to the appropriate ID for your queue), and sets the status to rejected.

javascript:self.location=self.location+'&Status=resolved&Queue=12'

Thus you can distinguish messages which you have already decided are spam, from those which are automatically filed into that queue.

== Collect spam/ham for training with procmail ==

In /etc/postfix, I am maintaining a file named rt-aliases. It contains, for every queue:
<pre>
rt: "|/usr/bin/procmail -m /etc/procmailrcs/general"
rt-comment: "|/usr/bin/procmail -m /etc/procmailrcs/general-comment"
</pre>

in /etc/procmailrcs, the file "general" looks like:
<pre>
PATH=/usr/local/bin:/bin:/usr/bin
LOGFILE=/var/log/procmail.log
INCLUDERC=/etc/procmailrcs/_spamfilter
</pre>

The "_spamfilter" include does the actual collection:

<pre>
# The lock file ensures that only 1 spamassassin invocation happens
# at 1 time, to keep the load down.
#
:0fw: spamassassin.lock
* < 256000
| /usr/bin/spamassassin

# Mails with a score of 15 or higher are almost certainly spam (with 0.05%
# false positives according to rules/STATISTICS.txt). Let's put them in a
# different mbox. (This one is optional.)
:0:
* ^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
/local/mailcopy/almost-certainly-spam

# Work around procmail bug: any output on stderr will cause the "F" in "From"
# to be dropped. This will re-add it.
:0
* ^^rom[ ]
{
LOG="*** Dropped F off From_ header! Fixing up. "

:0 fhw
| sed -e '1s/^/F/'
}

:0 c
/local/mailcopy/unconfirmed-ham
</pre>

== Notes & Other Resources ==

Don't forget to run `newaliases` (or equivalent) after you alter your configuration if appropriate.

* [[SpamScore2Priority]]
* [http://pm-doc.sourceforge.net/pm-tips-body.html#procmail_flags Procmail flags documentation].

SpamFiltering

2016-07-19T16:27:43Z

Medea61: /* b. Unfiltered mail + ProcMail & SpamAssassin => Spam Queue */

= Spam Filtering =

By moving all SPAM to a single queue, you can easily purge (shred) it periodically. You might also take the opportunity to purge any RT users who do not have a ticket associated with them.

Please find documented below 6 setups for processing spam (1a-1c, 2a-2c). In general, you want to filter your messages at the MTA, before they get RT if you can.

The list archives also contain a number of [http://www.gossamer-threads.com/lists/rt/users/87056?search_string=Spam filtering in RT;#87056 useful tips]

== 0. Pre-filtering & scoring messages ==

There are a number of ways of doing so, such as procmail or [http://pthbb.org/manual/software/mailfilter mailfilter] which can do other somewhat-RT-specific pre-processing as well.

== 1. Pre-filtered mail ==

There are several options for processing messages once scored:

=== a. Pre-filtered mail + ::Filter::SpamAssassin (=> Spam Queue) ===

http://codepad.org/HQmnr0AG based on

http://documentroot.com/SpamAssassin.pm based on RT::Interface::Email::Filter::SpamAssassin from 3.8.1

This updated version of the filter provides several options for handling potential spam, such as rejecting all messages above a certain score, and filing others in a SPAM queue.

=== b. Pre-filtered mail + Scrip => Queue ===

In the example below a score of 5 or more is needed. Edit preparation code if you want to modify the level.

Create new Scrip using following information:

*Condition: On Create
*Action: User Defined
*Custom action preparation code:
<pre>
# Match ***** level spam. You might want to set this higher/lower if needed
my $match = '\*\*\*\*\*';
my $inMessage = $self->TransactionObj->Attachments->First;
return 0 if (!$inMessage); # if no message attachment - assume web UI
return 0 if (!$inMessage->GetHeader('Received')); # exit if not email message

my $spamLevel = $inMessage->GetHeader('X-Spam-Level');
return ( $spamLevel !~ /$match/i ) ? 0 : 1;
</pre>

*Custom action cleanup code:
<pre>
my $newqueue = 'spam';
my ($status, $msg) = $self->TicketObj->SetQueue($newqueue);
return $status ? undef : 1;
</pre>

=== c. Pre-filtered mail + ProcMail => Spam Queue ===

A procmail recipe (for each queue/(correspond|comment) pair) can be used to send spam to a spam queue in RT. Note that:

* the flags bh need to be set so rt-mailgate sees both the body and header of the message.
* the absence of a second colon so there is no lockfile

<pre>
PATH=/usr/local/bin:/bin/:/usr/bin
LOGFILE=/var/log/procmail.log
#rt-mailgate has already saved the message in the rt database
#set DEFAULT to be somewhere real if you want procmail to save the message elsewhere
DEFAULT=/dev/null

#Messages >300000 characters proceed to recipient (unlikely to be spam)
#:0fwbh
:0wbh
* > 300000
| /usr/local/rt3/bin/rt-mailgate --queue default --action correspond --url http://localhost/

#if the spam trigger is fired send to spam queue
#:0fwbh
:0wbh
* ^X-Spam-Level: \*\*\*\*\*
| /usr/local/rt3/bin/rt-mailgate --queue spam --action correspond --url http://localhost/rt/

#if the spam trigger is not fired then send to expected destination
#:0fwbh
:0wbh
| /usr/local/rt3/bin/rt-mailgate --queue default --action correspond --url http://localhost/rt/
</pre>

=== 2. Unfiltered messages ===

=== a. Unfiltered mail + ::Filter::SpamAssassin (=> Spam Queue) ===

RT::Interface::Email::Filter::SpamAssassin above (1a) can also pass unscored messages off to SpamAssassin for processing.

=== b. Unfiltered mail + ProcMail & SpamAssassin => Spam Queue ===

This procmail recipe is similar to 1c. above, except that it handles previously unscored messages, and accepts many of the rt-mailgate parameters as environment variables so that it may be easily used with multiple aliases.

Aliases:
<pre>
rt: "|/usr/local/bin/procmail -m ACTION=correspond QUEUE=General /usr/local/etc/procmail/rt-deliver.rc"
rt-comment: "|/usr/local/bin/procmail -m ACTION=comment QUEUE=General /usr/local/etc/procmail/rt-deliver.rc"
</pre>

/usr/local/etc/procmail/rt-deliver.rc:

<pre>
#Messages >300000 characters proceed to recipient (unlikely to be spam)
:0w
* > 300000
| /usr/local/rt3/bin/rt-mailgate --queue $QUEUE --action correspond --url http://localhost/rt/

#Is it spam?
:0fw: spamassassin.lock
* < 300000
| /usr/local/bin/spamc

#if the spam trigger is fired send to spam queue
:0w
* ^X-Spam-Status: Yes
| /usr/local/rt3/bin/rt-mailgate --queue Spam --action correspond --url http://localhost/rt/

#if the spam trigger is not fired then send to expected destination
:0w
| /usr/local/rt3/bin/rt-mailgate --queue $QUEUE --action $ACTION --url http://localhost/rt/
</pre>

=== c. ProcMail + SpamAssassin + Scrip => Spam Queue ===

http://www.soundwave.net/~wmono/rt/

== 3. Mis-handled messages ==

=== a. False positives: Greylist ===

2c above outlines a general (non-procmail specific) setup (steps 1 through 6 for RT) to automatically greylist suspect messages. Legitimate requestors may reply to an autoresponse and have their misfiled message requeued.

=== b. False negatives: QuickSpamhandler ===

Note: [[QuickSpamHandler]] seems to no longer be available. The [http://search.cpan.org/~ruz/RT-Extension-ReportSpam-0.02/lib/RT/Extension/ReportSpam.pm RT::Extension::ReportSpam] is fairly similar though.

This extension provides a few tools that can be used for manual triage of SPAM in low-traffic installation, or handling the odd message that leaks through your automated filters:

* Adds alternate forms of the "Unowned Tickets" and "My Tickets" global searches, which exclude messages in the spam queue.
* Adds a link to the "Search - Unowned Tickets" query which permits you to instantly vanquish a ticket if the subject is sufficient to convince you the message is SPAM.
* Adds a link to the Ticket tool bar that will instantly vanquish the displayed ticket.

Vanquished tickets are moved to a designated SPAM queue; the default is named "Possible SPAM".

==== Installation ====

* Download the [http://zephyrgeek.qatar.cmu.edu/RT/QuickSpamHandler.tgz archive]
* Unpack it
* ./configure
* make install
* Read and act on the output from the previous command.

Really, the only tricky bit is the database update. If I ever figure out a better way to do this I'll make sure to update the archive. Hopefully someone will find this useful. If you do, please drop me a line!

=== c. False negatives: Bookmarklet ===

An alternative to QuickSpamHandler above, this bookmarklet moves the displayed ticket to the spam queue (change 12 to the appropriate ID for your queue), and sets the status to rejected.

javascript:self.location=self.location+'&Status=resolved&Queue=12'

Thus you can distinguish messages which you have already decided are spam, from those which are automatically filed into that queue.

== Collect spam/ham for training with procmail ==

In /etc/postfix, I am maintaining a file named rt-aliases. It contains, for every queue:

rt: "|/usr/bin/procmail -m /etc/procmailrcs/general"
rt-comment: "|/usr/bin/procmail -m /etc/procmailrcs/general-comment"

in /etc/procmailrcs, the file "general" looks like:

PATH=/usr/local/bin:/bin:/usr/bin
LOGFILE=/var/log/procmail.log
INCLUDERC=/etc/procmailrcs/_spamfilter

The "_spamfilter" include does the actual collection:

<nowiki># The lock file ensures that only 1 spamassassin invocation happens
# at 1 time, to keep the load down.
#
:0fw: spamassassin.lock
* < 256000
| /usr/bin/spamassassin

# Mails with a score of 15 or higher are almost certainly spam (with 0.05%
# false positives according to rules/STATISTICS.txt). Let's put them in a
# different mbox. (This one is optional.)
:0:
* ^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
/local/mailcopy/almost-certainly-spam

# Work around procmail bug: any output on stderr will cause the "F" in "From"
# to be dropped. This will re-add it.
:0
* ^^rom[ ]
{
LOG="*** Dropped F off From_ header! Fixing up. "

:0 fhw
| sed -e '1s/^/F/'
}

:0 c
/local/mailcopy/unconfirmed-ham
</nowiki>

== Notes & Other Resources ==

Don't forget to run `newaliases` (or equivalent) after you alter your configuration if appropriate.

* [[SpamScore2Priority]]
* [http://pm-doc.sourceforge.net/pm-tips-body.html#procmail_flags Procmail flags documentation].

SpamFiltering

2016-07-19T16:26:55Z

Medea61: /* c. Pre-filtered mail + ProcMail => Spam Queue */

= Spam Filtering =

By moving all SPAM to a single queue, you can easily purge (shred) it periodically. You might also take the opportunity to purge any RT users who do not have a ticket associated with them.

Please find documented below 6 setups for processing spam (1a-1c, 2a-2c). In general, you want to filter your messages at the MTA, before they get RT if you can.

The list archives also contain a number of [http://www.gossamer-threads.com/lists/rt/users/87056?search_string=Spam filtering in RT;#87056 useful tips]

== 0. Pre-filtering & scoring messages ==

There are a number of ways of doing so, such as procmail or [http://pthbb.org/manual/software/mailfilter mailfilter] which can do other somewhat-RT-specific pre-processing as well.

== 1. Pre-filtered mail ==

There are several options for processing messages once scored:

=== a. Pre-filtered mail + ::Filter::SpamAssassin (=> Spam Queue) ===

http://codepad.org/HQmnr0AG based on

http://documentroot.com/SpamAssassin.pm based on RT::Interface::Email::Filter::SpamAssassin from 3.8.1

This updated version of the filter provides several options for handling potential spam, such as rejecting all messages above a certain score, and filing others in a SPAM queue.

=== b. Pre-filtered mail + Scrip => Queue ===

In the example below a score of 5 or more is needed. Edit preparation code if you want to modify the level.

Create new Scrip using following information:

*Condition: On Create
*Action: User Defined
*Custom action preparation code:
<pre>
# Match ***** level spam. You might want to set this higher/lower if needed
my $match = '\*\*\*\*\*';
my $inMessage = $self->TransactionObj->Attachments->First;
return 0 if (!$inMessage); # if no message attachment - assume web UI
return 0 if (!$inMessage->GetHeader('Received')); # exit if not email message

my $spamLevel = $inMessage->GetHeader('X-Spam-Level');
return ( $spamLevel !~ /$match/i ) ? 0 : 1;
</pre>

*Custom action cleanup code:
<pre>
my $newqueue = 'spam';
my ($status, $msg) = $self->TicketObj->SetQueue($newqueue);
return $status ? undef : 1;
</pre>

=== c. Pre-filtered mail + ProcMail => Spam Queue ===

A procmail recipe (for each queue/(correspond|comment) pair) can be used to send spam to a spam queue in RT. Note that:

* the flags bh need to be set so rt-mailgate sees both the body and header of the message.
* the absence of a second colon so there is no lockfile

<pre>
PATH=/usr/local/bin:/bin/:/usr/bin
LOGFILE=/var/log/procmail.log
#rt-mailgate has already saved the message in the rt database
#set DEFAULT to be somewhere real if you want procmail to save the message elsewhere
DEFAULT=/dev/null

#Messages >300000 characters proceed to recipient (unlikely to be spam)
#:0fwbh
:0wbh
* > 300000
| /usr/local/rt3/bin/rt-mailgate --queue default --action correspond --url http://localhost/

#if the spam trigger is fired send to spam queue
#:0fwbh
:0wbh
* ^X-Spam-Level: \*\*\*\*\*
| /usr/local/rt3/bin/rt-mailgate --queue spam --action correspond --url http://localhost/rt/

#if the spam trigger is not fired then send to expected destination
#:0fwbh
:0wbh
| /usr/local/rt3/bin/rt-mailgate --queue default --action correspond --url http://localhost/rt/
</pre>

=== 2. Unfiltered messages ===

=== a. Unfiltered mail + ::Filter::SpamAssassin (=> Spam Queue) ===

RT::Interface::Email::Filter::SpamAssassin above (1a) can also pass unscored messages off to SpamAssassin for processing.

=== b. Unfiltered mail + ProcMail & SpamAssassin => Spam Queue ===

This procmail recipe is similar to 1c. above, except that it handles previously unscored messages, and accepts many of the rt-mailgate parameters as environment variables so that it may be easily used with multiple aliases.

Aliases:

rt: "|/usr/local/bin/procmail -m ACTION=correspond QUEUE=General /usr/local/etc/procmail/rt-deliver.rc"
rt-comment: "|/usr/local/bin/procmail -m ACTION=comment QUEUE=General /usr/local/etc/procmail/rt-deliver.rc"

/usr/local/etc/procmail/rt-deliver.rc:

<nowiki>#Messages >300000 characters proceed to recipient (unlikely to be spam)
:0w
* > 300000
| /usr/local/rt3/bin/rt-mailgate --queue $QUEUE --action correspond --url http://localhost/rt/

#Is it spam?
:0fw: spamassassin.lock
* < 300000
| /usr/local/bin/spamc

#if the spam trigger is fired send to spam queue
:0w
* ^X-Spam-Status: Yes
| /usr/local/rt3/bin/rt-mailgate --queue Spam --action correspond --url http://localhost/rt/

#if the spam trigger is not fired then send to expected destination
:0w
| /usr/local/rt3/bin/rt-mailgate --queue $QUEUE --action $ACTION --url http://localhost/rt/
</nowiki>

=== c. ProcMail + SpamAssassin + Scrip => Spam Queue ===

http://www.soundwave.net/~wmono/rt/

== 3. Mis-handled messages ==

=== a. False positives: Greylist ===

2c above outlines a general (non-procmail specific) setup (steps 1 through 6 for RT) to automatically greylist suspect messages. Legitimate requestors may reply to an autoresponse and have their misfiled message requeued.

=== b. False negatives: QuickSpamhandler ===

Note: [[QuickSpamHandler]] seems to no longer be available. The [http://search.cpan.org/~ruz/RT-Extension-ReportSpam-0.02/lib/RT/Extension/ReportSpam.pm RT::Extension::ReportSpam] is fairly similar though.

This extension provides a few tools that can be used for manual triage of SPAM in low-traffic installation, or handling the odd message that leaks through your automated filters:

* Adds alternate forms of the "Unowned Tickets" and "My Tickets" global searches, which exclude messages in the spam queue.
* Adds a link to the "Search - Unowned Tickets" query which permits you to instantly vanquish a ticket if the subject is sufficient to convince you the message is SPAM.
* Adds a link to the Ticket tool bar that will instantly vanquish the displayed ticket.

Vanquished tickets are moved to a designated SPAM queue; the default is named "Possible SPAM".

==== Installation ====

* Download the [http://zephyrgeek.qatar.cmu.edu/RT/QuickSpamHandler.tgz archive]
* Unpack it
* ./configure
* make install
* Read and act on the output from the previous command.

Really, the only tricky bit is the database update. If I ever figure out a better way to do this I'll make sure to update the archive. Hopefully someone will find this useful. If you do, please drop me a line!

=== c. False negatives: Bookmarklet ===

An alternative to QuickSpamHandler above, this bookmarklet moves the displayed ticket to the spam queue (change 12 to the appropriate ID for your queue), and sets the status to rejected.

javascript:self.location=self.location+'&Status=resolved&Queue=12'

Thus you can distinguish messages which you have already decided are spam, from those which are automatically filed into that queue.

== Collect spam/ham for training with procmail ==

In /etc/postfix, I am maintaining a file named rt-aliases. It contains, for every queue:

rt: "|/usr/bin/procmail -m /etc/procmailrcs/general"
rt-comment: "|/usr/bin/procmail -m /etc/procmailrcs/general-comment"

in /etc/procmailrcs, the file "general" looks like:

PATH=/usr/local/bin:/bin:/usr/bin
LOGFILE=/var/log/procmail.log
INCLUDERC=/etc/procmailrcs/_spamfilter

The "_spamfilter" include does the actual collection:

<nowiki># The lock file ensures that only 1 spamassassin invocation happens
# at 1 time, to keep the load down.
#
:0fw: spamassassin.lock
* < 256000
| /usr/bin/spamassassin

# Mails with a score of 15 or higher are almost certainly spam (with 0.05%
# false positives according to rules/STATISTICS.txt). Let's put them in a
# different mbox. (This one is optional.)
:0:
* ^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
/local/mailcopy/almost-certainly-spam

# Work around procmail bug: any output on stderr will cause the "F" in "From"
# to be dropped. This will re-add it.
:0
* ^^rom[ ]
{
LOG="*** Dropped F off From_ header! Fixing up. "

:0 fhw
| sed -e '1s/^/F/'
}

:0 c
/local/mailcopy/unconfirmed-ham
</nowiki>

== Notes & Other Resources ==

Don't forget to run `newaliases` (or equivalent) after you alter your configuration if appropriate.

* [[SpamScore2Priority]]
* [http://pm-doc.sourceforge.net/pm-tips-body.html#procmail_flags Procmail flags documentation].

SpamFiltering

2016-07-19T16:26:03Z

Medea61: /* b. Pre-filtered mail + Scrip => Queue */

= Spam Filtering =

By moving all SPAM to a single queue, you can easily purge (shred) it periodically. You might also take the opportunity to purge any RT users who do not have a ticket associated with them.

Please find documented below 6 setups for processing spam (1a-1c, 2a-2c). In general, you want to filter your messages at the MTA, before they get RT if you can.

The list archives also contain a number of [http://www.gossamer-threads.com/lists/rt/users/87056?search_string=Spam filtering in RT;#87056 useful tips]

== 0. Pre-filtering & scoring messages ==

There are a number of ways of doing so, such as procmail or [http://pthbb.org/manual/software/mailfilter mailfilter] which can do other somewhat-RT-specific pre-processing as well.

== 1. Pre-filtered mail ==

There are several options for processing messages once scored:

=== a. Pre-filtered mail + ::Filter::SpamAssassin (=> Spam Queue) ===

http://codepad.org/HQmnr0AG based on

http://documentroot.com/SpamAssassin.pm based on RT::Interface::Email::Filter::SpamAssassin from 3.8.1

This updated version of the filter provides several options for handling potential spam, such as rejecting all messages above a certain score, and filing others in a SPAM queue.

=== b. Pre-filtered mail + Scrip => Queue ===

In the example below a score of 5 or more is needed. Edit preparation code if you want to modify the level.

Create new Scrip using following information:

*Condition: On Create
*Action: User Defined
*Custom action preparation code:
<pre>
# Match ***** level spam. You might want to set this higher/lower if needed
my $match = '\*\*\*\*\*';
my $inMessage = $self->TransactionObj->Attachments->First;
return 0 if (!$inMessage); # if no message attachment - assume web UI
return 0 if (!$inMessage->GetHeader('Received')); # exit if not email message

my $spamLevel = $inMessage->GetHeader('X-Spam-Level');
return ( $spamLevel !~ /$match/i ) ? 0 : 1;
</pre>

*Custom action cleanup code:
<pre>
my $newqueue = 'spam';
my ($status, $msg) = $self->TicketObj->SetQueue($newqueue);
return $status ? undef : 1;
</pre>

=== c. Pre-filtered mail + ProcMail => Spam Queue ===

A procmail recipe (for each queue/(correspond|comment) pair) can be used to send spam to a spam queue in RT. Note that:

* the flags bh need to be set so rt-mailgate sees both the body and header of the message.
* the absence of a second colon so there is no lockfile

<nowiki>PATH=/usr/local/bin:/bin/:/usr/bin
LOGFILE=/var/log/procmail.log
#rt-mailgate has already saved the message in the rt database
#set DEFAULT to be somewhere real if you want procmail to save the message elsewhere
DEFAULT=/dev/null

#Messages >300000 characters proceed to recipient (unlikely to be spam)
#:0fwbh
:0wbh
* > 300000
| /usr/local/rt3/bin/rt-mailgate --queue default --action correspond --url http://localhost/

#if the spam trigger is fired send to spam queue
#:0fwbh
:0wbh
* ^X-Spam-Level: \*\*\*\*\*
| /usr/local/rt3/bin/rt-mailgate --queue spam --action correspond --url http://localhost/rt/

#if the spam trigger is not fired then send to expected destination
#:0fwbh
:0wbh
| /usr/local/rt3/bin/rt-mailgate --queue default --action correspond --url http://localhost/rt/
</nowiki>

=== 2. Unfiltered messages ===

=== a. Unfiltered mail + ::Filter::SpamAssassin (=> Spam Queue) ===

RT::Interface::Email::Filter::SpamAssassin above (1a) can also pass unscored messages off to SpamAssassin for processing.

=== b. Unfiltered mail + ProcMail & SpamAssassin => Spam Queue ===

This procmail recipe is similar to 1c. above, except that it handles previously unscored messages, and accepts many of the rt-mailgate parameters as environment variables so that it may be easily used with multiple aliases.

Aliases:

rt: "|/usr/local/bin/procmail -m ACTION=correspond QUEUE=General /usr/local/etc/procmail/rt-deliver.rc"
rt-comment: "|/usr/local/bin/procmail -m ACTION=comment QUEUE=General /usr/local/etc/procmail/rt-deliver.rc"

/usr/local/etc/procmail/rt-deliver.rc:

<nowiki>#Messages >300000 characters proceed to recipient (unlikely to be spam)
:0w
* > 300000
| /usr/local/rt3/bin/rt-mailgate --queue $QUEUE --action correspond --url http://localhost/rt/

#Is it spam?
:0fw: spamassassin.lock
* < 300000
| /usr/local/bin/spamc

#if the spam trigger is fired send to spam queue
:0w
* ^X-Spam-Status: Yes
| /usr/local/rt3/bin/rt-mailgate --queue Spam --action correspond --url http://localhost/rt/

#if the spam trigger is not fired then send to expected destination
:0w
| /usr/local/rt3/bin/rt-mailgate --queue $QUEUE --action $ACTION --url http://localhost/rt/
</nowiki>

=== c. ProcMail + SpamAssassin + Scrip => Spam Queue ===

http://www.soundwave.net/~wmono/rt/

== 3. Mis-handled messages ==

=== a. False positives: Greylist ===

2c above outlines a general (non-procmail specific) setup (steps 1 through 6 for RT) to automatically greylist suspect messages. Legitimate requestors may reply to an autoresponse and have their misfiled message requeued.

=== b. False negatives: QuickSpamhandler ===

Note: [[QuickSpamHandler]] seems to no longer be available. The [http://search.cpan.org/~ruz/RT-Extension-ReportSpam-0.02/lib/RT/Extension/ReportSpam.pm RT::Extension::ReportSpam] is fairly similar though.

This extension provides a few tools that can be used for manual triage of SPAM in low-traffic installation, or handling the odd message that leaks through your automated filters:

* Adds alternate forms of the "Unowned Tickets" and "My Tickets" global searches, which exclude messages in the spam queue.
* Adds a link to the "Search - Unowned Tickets" query which permits you to instantly vanquish a ticket if the subject is sufficient to convince you the message is SPAM.
* Adds a link to the Ticket tool bar that will instantly vanquish the displayed ticket.

Vanquished tickets are moved to a designated SPAM queue; the default is named "Possible SPAM".

==== Installation ====

* Download the [http://zephyrgeek.qatar.cmu.edu/RT/QuickSpamHandler.tgz archive]
* Unpack it
* ./configure
* make install
* Read and act on the output from the previous command.

Really, the only tricky bit is the database update. If I ever figure out a better way to do this I'll make sure to update the archive. Hopefully someone will find this useful. If you do, please drop me a line!

=== c. False negatives: Bookmarklet ===

An alternative to QuickSpamHandler above, this bookmarklet moves the displayed ticket to the spam queue (change 12 to the appropriate ID for your queue), and sets the status to rejected.

javascript:self.location=self.location+'&Status=resolved&Queue=12'

Thus you can distinguish messages which you have already decided are spam, from those which are automatically filed into that queue.

== Collect spam/ham for training with procmail ==

In /etc/postfix, I am maintaining a file named rt-aliases. It contains, for every queue:

rt: "|/usr/bin/procmail -m /etc/procmailrcs/general"
rt-comment: "|/usr/bin/procmail -m /etc/procmailrcs/general-comment"

in /etc/procmailrcs, the file "general" looks like:

PATH=/usr/local/bin:/bin:/usr/bin
LOGFILE=/var/log/procmail.log
INCLUDERC=/etc/procmailrcs/_spamfilter

The "_spamfilter" include does the actual collection:

<nowiki># The lock file ensures that only 1 spamassassin invocation happens
# at 1 time, to keep the load down.
#
:0fw: spamassassin.lock
* < 256000
| /usr/bin/spamassassin

# Mails with a score of 15 or higher are almost certainly spam (with 0.05%
# false positives according to rules/STATISTICS.txt). Let's put them in a
# different mbox. (This one is optional.)
:0:
* ^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
/local/mailcopy/almost-certainly-spam

# Work around procmail bug: any output on stderr will cause the "F" in "From"
# to be dropped. This will re-add it.
:0
* ^^rom[ ]
{
LOG="*** Dropped F off From_ header! Fixing up. "

:0 fhw
| sed -e '1s/^/F/'
}

:0 c
/local/mailcopy/unconfirmed-ham
</nowiki>

== Notes & Other Resources ==

Don't forget to run `newaliases` (or equivalent) after you alter your configuration if appropriate.

* [[SpamScore2Priority]]
* [http://pm-doc.sourceforge.net/pm-tips-body.html#procmail_flags Procmail flags documentation].

SpamFiltering

2016-07-19T16:23:38Z

Medea61: Undo revision 26281 by Medea61 (talk)

= Spam Filtering =

By moving all SPAM to a single queue, you can easily purge (shred) it periodically. You might also take the opportunity to purge any RT users who do not have a ticket associated with them.

Please find documented below 6 setups for processing spam (1a-1c, 2a-2c). In general, you want to filter your messages at the MTA, before they get RT if you can.

The list archives also contain a number of [http://www.gossamer-threads.com/lists/rt/users/87056?search_string=Spam filtering in RT;#87056 useful tips]

== 0. Pre-filtering & scoring messages ==

There are a number of ways of doing so, such as procmail or [http://pthbb.org/manual/software/mailfilter mailfilter] which can do other somewhat-RT-specific pre-processing as well.

== 1. Pre-filtered mail ==

There are several options for processing messages once scored:

=== a. Pre-filtered mail + ::Filter::SpamAssassin (=> Spam Queue) ===

http://codepad.org/HQmnr0AG based on

http://documentroot.com/SpamAssassin.pm based on RT::Interface::Email::Filter::SpamAssassin from 3.8.1

This updated version of the filter provides several options for handling potential spam, such as rejecting all messages above a certain score, and filing others in a SPAM queue.

=== b. Pre-filtered mail + Scrip => Queue ===

In the example below a score of 5 or more is needed. Edit preparation code if you want to modify the level.

Create new Scrip using following information:

*Condition: On Create *Action: User Defined *Custom action preparation code:

<nowiki># Match ***** level spam. You might want to set this higher/lower if needed
my $match = '\*\*\*\*\*';
my $inMessage = $self->TransactionObj->Attachments->First;
return 0 if (!$inMessage); # if no message attachment - assume web UI
return 0 if (!$inMessage->GetHeader('Received')); # exit if not email message

my $spamLevel = $inMessage->GetHeader('X-Spam-Level');
return ( $spamLevel !~ /$match/i ) ? 0 : 1;
</nowiki>

*Custom action cleanup code:

my $newqueue = 'spam';
my ($status, $msg) = $self->TicketObj->SetQueue($newqueue);
return $status ? undef : 1;

=== c. Pre-filtered mail + ProcMail => Spam Queue ===

A procmail recipe (for each queue/(correspond|comment) pair) can be used to send spam to a spam queue in RT. Note that:

* the flags bh need to be set so rt-mailgate sees both the body and header of the message.
* the absence of a second colon so there is no lockfile

<nowiki>PATH=/usr/local/bin:/bin/:/usr/bin
LOGFILE=/var/log/procmail.log
#rt-mailgate has already saved the message in the rt database
#set DEFAULT to be somewhere real if you want procmail to save the message elsewhere
DEFAULT=/dev/null

#Messages >300000 characters proceed to recipient (unlikely to be spam)
#:0fwbh
:0wbh
* > 300000
| /usr/local/rt3/bin/rt-mailgate --queue default --action correspond --url http://localhost/

#if the spam trigger is fired send to spam queue
#:0fwbh
:0wbh
* ^X-Spam-Level: \*\*\*\*\*
| /usr/local/rt3/bin/rt-mailgate --queue spam --action correspond --url http://localhost/rt/

#if the spam trigger is not fired then send to expected destination
#:0fwbh
:0wbh
| /usr/local/rt3/bin/rt-mailgate --queue default --action correspond --url http://localhost/rt/
</nowiki>

=== 2. Unfiltered messages ===

=== a. Unfiltered mail + ::Filter::SpamAssassin (=> Spam Queue) ===

RT::Interface::Email::Filter::SpamAssassin above (1a) can also pass unscored messages off to SpamAssassin for processing.

=== b. Unfiltered mail + ProcMail & SpamAssassin => Spam Queue ===

This procmail recipe is similar to 1c. above, except that it handles previously unscored messages, and accepts many of the rt-mailgate parameters as environment variables so that it may be easily used with multiple aliases.

Aliases:

rt: "|/usr/local/bin/procmail -m ACTION=correspond QUEUE=General /usr/local/etc/procmail/rt-deliver.rc"
rt-comment: "|/usr/local/bin/procmail -m ACTION=comment QUEUE=General /usr/local/etc/procmail/rt-deliver.rc"

/usr/local/etc/procmail/rt-deliver.rc:

<nowiki>#Messages >300000 characters proceed to recipient (unlikely to be spam)
:0w
* > 300000
| /usr/local/rt3/bin/rt-mailgate --queue $QUEUE --action correspond --url http://localhost/rt/

#Is it spam?
:0fw: spamassassin.lock
* < 300000
| /usr/local/bin/spamc

#if the spam trigger is fired send to spam queue
:0w
* ^X-Spam-Status: Yes
| /usr/local/rt3/bin/rt-mailgate --queue Spam --action correspond --url http://localhost/rt/

#if the spam trigger is not fired then send to expected destination
:0w
| /usr/local/rt3/bin/rt-mailgate --queue $QUEUE --action $ACTION --url http://localhost/rt/
</nowiki>

=== c. ProcMail + SpamAssassin + Scrip => Spam Queue ===

http://www.soundwave.net/~wmono/rt/

== 3. Mis-handled messages ==

=== a. False positives: Greylist ===

2c above outlines a general (non-procmail specific) setup (steps 1 through 6 for RT) to automatically greylist suspect messages. Legitimate requestors may reply to an autoresponse and have their misfiled message requeued.

=== b. False negatives: QuickSpamhandler ===

Note: [[QuickSpamHandler]] seems to no longer be available. The [http://search.cpan.org/~ruz/RT-Extension-ReportSpam-0.02/lib/RT/Extension/ReportSpam.pm RT::Extension::ReportSpam] is fairly similar though.

This extension provides a few tools that can be used for manual triage of SPAM in low-traffic installation, or handling the odd message that leaks through your automated filters:

* Adds alternate forms of the "Unowned Tickets" and "My Tickets" global searches, which exclude messages in the spam queue.
* Adds a link to the "Search - Unowned Tickets" query which permits you to instantly vanquish a ticket if the subject is sufficient to convince you the message is SPAM.
* Adds a link to the Ticket tool bar that will instantly vanquish the displayed ticket.

Vanquished tickets are moved to a designated SPAM queue; the default is named "Possible SPAM".

==== Installation ====

* Download the [http://zephyrgeek.qatar.cmu.edu/RT/QuickSpamHandler.tgz archive]
* Unpack it
* ./configure
* make install
* Read and act on the output from the previous command.

Really, the only tricky bit is the database update. If I ever figure out a better way to do this I'll make sure to update the archive. Hopefully someone will find this useful. If you do, please drop me a line!

=== c. False negatives: Bookmarklet ===

An alternative to QuickSpamHandler above, this bookmarklet moves the displayed ticket to the spam queue (change 12 to the appropriate ID for your queue), and sets the status to rejected.

javascript:self.location=self.location+'&Status=resolved&Queue=12'

Thus you can distinguish messages which you have already decided are spam, from those which are automatically filed into that queue.

== Collect spam/ham for training with procmail ==

In /etc/postfix, I am maintaining a file named rt-aliases. It contains, for every queue:

rt: "|/usr/bin/procmail -m /etc/procmailrcs/general"
rt-comment: "|/usr/bin/procmail -m /etc/procmailrcs/general-comment"

in /etc/procmailrcs, the file "general" looks like:

PATH=/usr/local/bin:/bin:/usr/bin
LOGFILE=/var/log/procmail.log
INCLUDERC=/etc/procmailrcs/_spamfilter

The "_spamfilter" include does the actual collection:

<nowiki># The lock file ensures that only 1 spamassassin invocation happens
# at 1 time, to keep the load down.
#
:0fw: spamassassin.lock
* < 256000
| /usr/bin/spamassassin

# Mails with a score of 15 or higher are almost certainly spam (with 0.05%
# false positives according to rules/STATISTICS.txt). Let's put them in a
# different mbox. (This one is optional.)
:0:
* ^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
/local/mailcopy/almost-certainly-spam

# Work around procmail bug: any output on stderr will cause the "F" in "From"
# to be dropped. This will re-add it.
:0
* ^^rom[ ]
{
LOG="*** Dropped F off From_ header! Fixing up. "

:0 fhw
| sed -e '1s/^/F/'
}

:0 c
/local/mailcopy/unconfirmed-ham
</nowiki>

== Notes & Other Resources ==

Don't forget to run `newaliases` (or equivalent) after you alter your configuration if appropriate.

* [[SpamScore2Priority]]
* [http://pm-doc.sourceforge.net/pm-tips-body.html#procmail_flags Procmail flags documentation].

SpamFiltering

2016-07-19T16:23:21Z

Medea61:

= Spam Filtering =

By moving all SPAM to a single queue, you can easily purge (shred) it periodically. You might also take the opportunity to purge any RT users who do not have a ticket associated with them.

Please find documented below 6 setups for processing spam (1a-1c, 2a-2c). In general, you want to filter your messages at the MTA, before they get RT if you can.

The list archives also contain a number of [http://www.gossamer-threads.com/lists/rt/users/87056?search_string=Spam filtering in RT;#87056 useful tips]

== 0. Pre-filtering & scoring messages ==

There are a number of ways of doing so, such as procmail or [http://pthbb.org/manual/software/mailfilter mailfilter] which can do other somewhat-RT-specific pre-processing as well.

== 1. Pre-filtered mail ==

There are several options for processing messages once scored:

=== a. Pre-filtered mail + ::Filter::SpamAssassin (=> Spam Queue) ===

http://codepad.org/HQmnr0AG based on

http://documentroot.com/SpamAssassin.pm based on RT::Interface::Email::Filter::SpamAssassin from 3.8.1

This updated version of the filter provides several options for handling potential spam, such as rejecting all messages above a certain score, and filing others in a SPAM queue.

=== b. Pre-filtered mail + Scrip => Queue ===

In the example below a score of 5 or more is needed. Edit preparation code if you want to modify the level.

Create new Scrip using following information:

*Condition: On Create
*Action: User Defined
*Custom action preparation code: <code>
# Match ***** level spam. You might want to set this higher/lower if needed
my $match = '\*\*\*\*\*';
my $inMessage = $self->TransactionObj->Attachments->First;
return 0 if (!$inMessage); # if no message attachment - assume web UI
return 0 if (!$inMessage->GetHeader('Received')); # exit if not email message

my $spamLevel = $inMessage->GetHeader('X-Spam-Level');
return ( $spamLevel !~ /$match/i ) ? 0 : 1;
</code>

*Custom action cleanup code: <code>
my $newqueue = 'spam';
my ($status, $msg) = $self->TicketObj->SetQueue($newqueue);
return $status ? undef : 1;
</code>

=== c. Pre-filtered mail + ProcMail => Spam Queue ===

A procmail recipe (for each queue/(correspond|comment) pair) can be used to send spam to a spam queue in RT. Note that:

* the flags bh need to be set so rt-mailgate sees both the body and header of the message.
* the absence of a second colon so there is no lockfile

<nowiki>PATH=/usr/local/bin:/bin/:/usr/bin
LOGFILE=/var/log/procmail.log
#rt-mailgate has already saved the message in the rt database
#set DEFAULT to be somewhere real if you want procmail to save the message elsewhere
DEFAULT=/dev/null

#Messages >300000 characters proceed to recipient (unlikely to be spam)
#:0fwbh
:0wbh
* > 300000
| /usr/local/rt3/bin/rt-mailgate --queue default --action correspond --url http://localhost/

#if the spam trigger is fired send to spam queue
#:0fwbh
:0wbh
* ^X-Spam-Level: \*\*\*\*\*
| /usr/local/rt3/bin/rt-mailgate --queue spam --action correspond --url http://localhost/rt/

#if the spam trigger is not fired then send to expected destination
#:0fwbh
:0wbh
| /usr/local/rt3/bin/rt-mailgate --queue default --action correspond --url http://localhost/rt/
</nowiki>

=== 2. Unfiltered messages ===

=== a. Unfiltered mail + ::Filter::SpamAssassin (=> Spam Queue) ===

RT::Interface::Email::Filter::SpamAssassin above (1a) can also pass unscored messages off to SpamAssassin for processing.

=== b. Unfiltered mail + ProcMail & SpamAssassin => Spam Queue ===

This procmail recipe is similar to 1c. above, except that it handles previously unscored messages, and accepts many of the rt-mailgate parameters as environment variables so that it may be easily used with multiple aliases.

Aliases:

rt: "|/usr/local/bin/procmail -m ACTION=correspond QUEUE=General /usr/local/etc/procmail/rt-deliver.rc"
rt-comment: "|/usr/local/bin/procmail -m ACTION=comment QUEUE=General /usr/local/etc/procmail/rt-deliver.rc"

/usr/local/etc/procmail/rt-deliver.rc:

<nowiki>#Messages >300000 characters proceed to recipient (unlikely to be spam)
:0w
* > 300000
| /usr/local/rt3/bin/rt-mailgate --queue $QUEUE --action correspond --url http://localhost/rt/

#Is it spam?
:0fw: spamassassin.lock
* < 300000
| /usr/local/bin/spamc

#if the spam trigger is fired send to spam queue
:0w
* ^X-Spam-Status: Yes
| /usr/local/rt3/bin/rt-mailgate --queue Spam --action correspond --url http://localhost/rt/

#if the spam trigger is not fired then send to expected destination
:0w
| /usr/local/rt3/bin/rt-mailgate --queue $QUEUE --action $ACTION --url http://localhost/rt/
</nowiki>

=== c. ProcMail + SpamAssassin + Scrip => Spam Queue ===

http://www.soundwave.net/~wmono/rt/

== 3. Mis-handled messages ==

=== a. False positives: Greylist ===

2c above outlines a general (non-procmail specific) setup (steps 1 through 6 for RT) to automatically greylist suspect messages. Legitimate requestors may reply to an autoresponse and have their misfiled message requeued.

=== b. False negatives: QuickSpamhandler ===

Note: [[QuickSpamHandler]] seems to no longer be available. The [http://search.cpan.org/~ruz/RT-Extension-ReportSpam-0.02/lib/RT/Extension/ReportSpam.pm RT::Extension::ReportSpam] is fairly similar though.

This extension provides a few tools that can be used for manual triage of SPAM in low-traffic installation, or handling the odd message that leaks through your automated filters:

* Adds alternate forms of the "Unowned Tickets" and "My Tickets" global searches, which exclude messages in the spam queue.
* Adds a link to the "Search - Unowned Tickets" query which permits you to instantly vanquish a ticket if the subject is sufficient to convince you the message is SPAM.
* Adds a link to the Ticket tool bar that will instantly vanquish the displayed ticket.

Vanquished tickets are moved to a designated SPAM queue; the default is named "Possible SPAM".

==== Installation ====

* Download the [http://zephyrgeek.qatar.cmu.edu/RT/QuickSpamHandler.tgz archive]
* Unpack it
* ./configure
* make install
* Read and act on the output from the previous command.

Really, the only tricky bit is the database update. If I ever figure out a better way to do this I'll make sure to update the archive. Hopefully someone will find this useful. If you do, please drop me a line!

=== c. False negatives: Bookmarklet ===

An alternative to QuickSpamHandler above, this bookmarklet moves the displayed ticket to the spam queue (change 12 to the appropriate ID for your queue), and sets the status to rejected.

javascript:self.location=self.location+'&Status=resolved&Queue=12'

Thus you can distinguish messages which you have already decided are spam, from those which are automatically filed into that queue.

== Collect spam/ham for training with procmail ==

In /etc/postfix, I am maintaining a file named rt-aliases. It contains, for every queue:

rt: "|/usr/bin/procmail -m /etc/procmailrcs/general"
rt-comment: "|/usr/bin/procmail -m /etc/procmailrcs/general-comment"

in /etc/procmailrcs, the file "general" looks like:

PATH=/usr/local/bin:/bin:/usr/bin
LOGFILE=/var/log/procmail.log
INCLUDERC=/etc/procmailrcs/_spamfilter

The "_spamfilter" include does the actual collection:

<nowiki># The lock file ensures that only 1 spamassassin invocation happens
# at 1 time, to keep the load down.
#
:0fw: spamassassin.lock
* < 256000
| /usr/bin/spamassassin

# Mails with a score of 15 or higher are almost certainly spam (with 0.05%
# false positives according to rules/STATISTICS.txt). Let's put them in a
# different mbox. (This one is optional.)
:0:
* ^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*
/local/mailcopy/almost-certainly-spam

# Work around procmail bug: any output on stderr will cause the "F" in "From"
# to be dropped. This will re-add it.
:0
* ^^rom[ ]
{
LOG="*** Dropped F off From_ header! Fixing up. "

:0 fhw
| sed -e '1s/^/F/'
}

:0 c
/local/mailcopy/unconfirmed-ham
</nowiki>

== Notes & Other Resources ==

Don't forget to run `newaliases` (or equivalent) after you alter your configuration if appropriate.

* [[SpamScore2Priority]]
* [http://pm-doc.sourceforge.net/pm-tips-body.html#procmail_flags Procmail flags documentation].