Rt 3 and @RT::MailPlugins

RT Users
1

Hi,

I’ve had a small hack in my v2 rt-mailgate, and after upgrading to v3, I
can’t really do it again, and I’ve seen this RT::MailPlugins.
I’ve read many pods and I’m still not sure of were I have to set this.
Is it in RT::Interface::Email (ugly) or in my RT_LocalConfig.pm ?

I can guess that a small explanation in rt-mailgate’s pod would be great :slight_smile:

Mathieu Arnold

2

there’s no reason you need to drop configuration variables anywhere
other than the config file. If you’ve got a patch to the pod, I’d love
it if you can bounce it to rt-3.0-bugs at fsck.com

Thanks,
JesseOn Fri, May 09, 2003 at 05:46:51PM +0200, Mathieu Arnold wrote:

Hi,

I’ve had a small hack in my v2 rt-mailgate, and after upgrading to v3, I
can’t really do it again, and I’ve seen this RT::MailPlugins.
I’ve read many pods and I’m still not sure of were I have to set this.
Is it in RT::Interface::Email (ugly) or in my RT_LocalConfig.pm ?

I can guess that a small explanation in rt-mailgate’s pod would be great :slight_smile:

–
Mathieu Arnold

rt-users mailing list
rt-users@lists.fsck.com
http://lists.fsck.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

Request Tracker... So much more than a help desk — Best Practical Solutions – Trouble Ticketing. Free.

3

±le 09/05/03 15:16 -0400, Jesse Vincent écrivait :
| there’s no reason you need to drop configuration variables anywhere
| other than the config file. If you’ve got a patch to the pod, I’d love
| it if you can bounce it to rt-3.0-bugs at fsck.com

Right, right, but there is just one sample of array conf variable, and I was
not sure what was the right way to do it.
I’ll try cook up a small patch on the week end for the pod with an anonymous
sub as exemple.

On another hand, I was using rt 3.0.1, and due to some really annoying bugs
:p, I now have a 3.0.2pre6.
I had a file in local/po/fr.po which contained a few changes to the
localization. I does not seem to work any more with 3.0.2pre6.

Regards,
Mathieu Arnold

4

±le 09/05/03 15:16 -0400, Jesse Vincent écrivait :
| there’s no reason you need to drop configuration variables anywhere
| other than the config file. If you’ve got a patch to the pod, I’d love
| it if you can bounce it to rt-3.0-bugs at fsck.com

I’ve put this in my RT_SiteConfig.pm :
@RT::MailPlugins = (
sub {
my %args = ( Message => undef,
CurrentUser => undef,
AuthLevel => undef,
Ticket => undef,
Queue => undef,
Action => undef,
@_ );
my $s = $args{‘Message’}->head->get(‘X-Spam-Level’);
if (defined($s) && $s =~ /*{8}/o) {
return (-1, undef);
}
return (0, undef);
},

    "Auth::MailFrom");

I already have spamassassin set up to tag all mails, and so, I check the
X-Spam-Level header. The thing is that it does not seems to work, it seems to
create an empty ticket owned by RT…

Any idea ?

Mathieu Arnold

5

±le 10/05/03 11:18 +0200, Mathieu Arnold écrivait :
|
|
| ±le 09/05/03 15:16 -0400, Jesse Vincent écrivait :
|| there’s no reason you need to drop configuration variables anywhere
|| other than the config file. If you’ve got a patch to the pod, I’d love
|| it if you can bounce it to rt-3.0-bugs at fsck.com
|
| I’ve put this in my RT_SiteConfig.pm :
| @RT::MailPlugins = (
| sub {
| my %args = ( Message => undef,
| CurrentUser => undef,
| AuthLevel => undef,
| Ticket => undef,
| Queue => undef,
| Action => undef,
| @_ );
| my $s = $args{‘Message’}->head->get(‘X-Spam-Level’);
| if (defined($s) && $s =~ /*{8}/o) {
| return (-1, undef);
| }
| return (0, undef);
| },
|
| “Auth::MailFrom”);
|
| I already have spamassassin set up to tag all mails, and so, I check the
| X-Spam-Level header. The thing is that it does not seems to work, it seems
| to create an empty ticket owned by RT…
|
| Any idea ?

I did this based on the Filter::Spamassassin module, and well, I guess that
all the return parameters are in the wrong way.
In Auth::MailFrom, I see :

unless ( $unpriv->Id ) {
    $RT::Logger->crit( "Auth::MailFrom couldn't find the 'Unprivileged'

internal group" );
return ( $args{‘CurrentUser’}, -1 );
}

and in Filter::SpamAssassin, I see :

    # Spammy indeed
    return (-1, undef);

which is obviously wrong seing that the one before works.

I guess someone could fix it so that no one else tries to do things the wrong
way :slight_smile:

Mathieu Arnold