Re: [rt-users] Excluding Commands from CommandbyMail parsing

[Parish, Brent]

Hi.

Dunno if it is the best way, but what I do it in RT 4.4.1 is edit the file:
   
/opt/rt4/local/plugins/RT-Extension-CommandByMail/lib/RT/Extension/CommandByMail.pm

Around line 349 look for this block of code, and add the line indicated with 
the plus (+) in front of it (without including the plus sign itself).

 my $found_pseudoheaders = 0;
 foreach my $line (@content) {
 next if $line =~ /^\s*$/ && ! $found_pseudoheaders;
+ last if $line =~ m/^(from:|cid:)/i;
 last if $line !~ /^(?:(\S+(?:{.*})?)\s*?:\s*?(.*)\s*?|)$/;
 last if not defined $1 and $found_pseudoheaders;
 next if not defined $1;

What this does is bail out of processing further lines as mail commands once it 
finds a line beginning with “From: “  (e.g. from a forwarded email).
It ALSO drops out if it finds “cid:”, which we sometimes saw with inline images 
being forwarded.

Please note that on older versions of RT, this block of code was found 
somewhere around line 228 in:

/opt/rt4/local/plugins/RT-Extension-CommandByMail/lib/RT/Interface/Email/Filter/TakeAction.pm

Thanks,
Brent



From: rt-users [mailto:rt-users-boun...@lists.bestpractical.com] On Behalf Of 
Chris McClement
Sent: Sunday, October 02, 2016 7:56 PM
To: rt-users@lists.bestpractical.com
Subject: [rt-users] Excluding Commands from CommandbyMail parsing

I've implemented the CommandbyMail extension 
(http://search.cpan.org/dist/RT-Extension-CommandByMail/lib/RT/Extension/CommandByMail.pm<https://urldefense.proofpoint.com/v2/url?u=http-3A__search.cpan.org_dist_RT-2DExtension-2DCommandByMail_lib_RT_Extension_CommandByMail.pm=DQMFaQ=VCWpAYkS3z1bOCIxc-BPGZarCq9MRCAVxZJE051VqH8=luSRdPePk6fhFa3rH2PFBzWEtgcJguY0a__6vpfaX-I=w9n7nGyNHOocCsnkMnUOldv0qFl-mPDh51ajkbOaN3U=m5LJCFX4expBhfaKyApPYQfuwomxu0xiMr9dCbEBbAY=>)
 in my RT 4.4.4 installation. It works well - almost too well!  I am getting 
"Extended Mailgate Errors" returned because the plugin is parsing the message 
body for "Command: value" (which it is meant to do) and picking up, in emails 
forwarded to RT:

"To: x...@abc.com<mailto:x...@abc.com>"
"From: x...@abc.com<mailto:x...@abc.com>"
"sent: the_date_sent"

And trying to process them as commands.

In addition, forwarded emails have "Subject: [Support ID #12345] 
some_new_subject" and this is changing the subject of the RT job to the new 
subject, which is different from the subject used when the ticket was 
originally created.

Is there a way to stop CommandbyMail from parsing "to:" "from" and "sent:" as 
commands, or at least configuring it to not return errors when it fails to 
match it to a valid command? And is there a way to prevent parsing "Subject: 
" so that my subjects no longer change?


-
RT 4.4 and RTIR training sessions, and a new workshop day! 
https://bestpractical.com/training
* Boston - October 24-26
* Los Angeles - Q1 2017

[rt-users] Excluding Commands from CommandbyMail parsing

[Chris McClement]

I've implemented the CommandbyMail extension (
http://search.cpan.org/dist/RT-Extension-CommandByMail/lib/RT/Extension/CommandByMail.pm)
in my RT 4.4.4 installation. It works well - almost too well!  I am getting
"Extended Mailgate Errors" returned because the plugin is parsing the
message body for "Command: value" (which it is meant to do) and picking up,
in emails forwarded to RT:

"To: x...@abc.com"
"From: x...@abc.com"
"sent: the_date_sent"

And trying to process them as commands.

In addition, forwarded emails have "Subject: [Support ID #12345]
some_new_subject" and this is changing the subject of the RT job to the new
subject, which is different from the subject used when the ticket was
originally created.

Is there a way to stop CommandbyMail from parsing "to:" "from" and "sent:"
as commands, or at least configuring it to not return errors when it fails
to match it to a valid command? And is there a way to prevent parsing
"Subject: " so that my subjects no longer change?
-
RT 4.4 and RTIR training sessions, and a new workshop day! 
https://bestpractical.com/training
* Boston - October 24-26
* Los Angeles - Q1 2017