Procmail

I have a problem using procmail with RT and I though you may be able to
help. I have been assigned the task of cleaning up after my department’s
Exchange administrators. All SMTP email that leaves the Exchange servers
have a disclaimer appended. For obvious reasons, I am trying to filter this
disclaimer before it hits RT. I have created a procmail recipe that uses
perl to strip the unwanted text. I though this should be invoked in the
aliases file like this:

helpdeskus: “| procmail /etc/.procmailrc | /opt/rt2/bin/rt-mailgate --queue
helpdeskus --action correspond”

It, unfortunately, sends a blank, header-less, body-less email to RT. I’m
not sure what I’m doing wrong here. I thought you may be able to suggest a
better place to invoke procmail. Maybe I should insert perl directly into
RT to perform this?

Any thoughts or suggestions on this mater would be appreciated.

Thanks,
George

This email message may contain information that is confidential and
proprietary to Babcock & Brown or a third party. If you are not the
intended recipient, please contact the sender and destroy the original and
any copies of the original message. Babcock & Brown takes measures to
protect the content of its communications. However, Babcock & Brown cannot
guarantee that email messages will not be intercepted by third parties or
that email messages will be free of errors or viruses.

Hi, sorry if this has been asked before? I didn’t find it on a quick trip
through the archives though.

Is there a way to select only certain tickets from a queue by keywords,
using the command line interface? I haven’t used RT since the v.1 days,
and I’ve so far found the keywords under the web interface to be a great
thing. I really rely on the command line interface though, as I base
shell scripts off of the CLI tools.

I was doing stuff like:

rt --limit-queue=general --summary %id5%subject80%owner10%due20%status8

I can’t find a keyword object in the documentation.

Any help or ideas? Hopefully it’s a simple thing that I haven’t figured
out in the new version yet :slight_smile:

Thanks,

Wes

disclaimer before it hits RT. I have created a procmail recipe that uses
perl to strip the unwanted text. I though this should be invoked in the
aliases file like this:

helpdeskus: “| procmail /etc/.procmailrc | /opt/rt2/bin/rt-mailgate --queue
helpdeskus --action correspond”

It, unfortunately, sends a blank, header-less, body-less email to RT. I’m
not sure what I’m doing wrong here. I thought you may be able to suggest a

You would be better off invoking rt-mailgate from within the procmailrc.
I do my mail delivery to RT via:

aliases file:
# Run rt2 as the rt2 user, not as root.
test-rt2: “| /usr/bin/procmail -m /etc/procmailrcs/rt2-test”

/etc/procmailrcs/rt2-test:

# This file MUST be owned by the rt2 user.  See '-m' description
# in the procmail man page.
HOME=/home/rt2
INCLUDERC=$HOME/.procmailrc-test

# are we still here after including?  Dump it to someone
:0
! joe_bloggs@example.com

( The above two snippets gets procmail running, as the rt2 user, a
procmail file for the specific queue. I really really dislike relying
on setuid stuff. )

/home/rt2/.procmailrc-test

# This file does any filtering/mail manipulations/etc before
# calling rt-mailgate.

HOME=/home/rt2
LOGFILE=log/procmail.log
VERBOSE=no

# Go away you naughty annoying spammer
:0
* ^From:.*badguy@example.com
/dev/null

# Place mailfiltering here
:0 f
| /home/rt2/bin/my_custom_filter_program

# Accept the mail into mailgate.  We { } enclose it incase we want
# a last-ditch filter.
:0
{
  # Use a lockfile to ensure only one rt-mailgate process.
  :0 :.procmail.lock
  | /home/rt2/bin/rt-mailgate --queue TEST --action correspond

  # Something went wrong.  Dump it to someone
  :0e
  ! joe.bloggs@example.com
}

Regards,

                         Bruce Campbell                            RIPE
               Systems/Network Engineer                             NCC
             www.ripe.net - PGP562C8B1B                      Operations

Bruce,

I just wanted to let you know that your advice has been very instrumental in
helping to get this going. I have successfully implemented and tested the
disclaimer filter. I really appreciate the time you have spent on this
issue. I owe you a beer next time you’re in NYC.

For the list, here is my final /etc/aliases entry, procmail recipe and perl
script. I hope this helps.

George

RELEVANT /etc/aliases FILE:

#RT STuff

helpdeskus: “| /usr/bin/procmail -m /etc/procmailrcs/disclaim-filter”
#helpdeskus: “| /opt/rt2/bin/rt-mailgate --queue helpdeskus --action
correspond”

MAIN PROCMAIL RECIPE> mmain

:>

#This file must be owned by the rt user
HOME=/home/rt
INCLUDERC=$HOME/.procmailrc
LOGFILE=/tmp/disclaimstrip.log
VERBOSE=on
SHELL = /bin/bash

0
! me@domain

So now procmail is acting as the user “rt”. Here’s were it all
happens, the > INCLUDERC file /home/rt/.procmailrc:

This file does any filtering/mail manipulations/etc before # calling

rt-mailgate.
HOME=/home/rt
LOGFILE=log/procmail.log
VERBOSE=yes

Place mailfiltering here

:0 wfb
|/usr/local/scripts/strip.disclaim

0
{

Use a lockfile to ensure only one rt-mailgate process.

    :0:.procmail.lock
    |/opt/rt2/bin/rt-mailgate --queue helpdeskus --action correspond

Something went wrong. Dump it to someone

    :0e
    ! me@domain

}

And finally, here is the real simple perl script:

#!/usr/bin/perl -w

undef $/; #We want to treat STDIN as one line

$input = <>;

$input =~ s/This email message may contain information(.*?)free of
errors or
viruses.//smg;

$/ = “\n”;

print $input;

From: Bruce Campbell [mailto:bruce_campbell@ripe.net]
Sent: Tuesday, February 05, 2002 5:30 AM
To: George Warnagiris
Cc: rt-users@lists.fsck.com
Subject: Re: [rt-users] RE: PROCMAIL

disclaimer before it hits RT. I have created a procmail recipe that uses
perl to strip the unwanted text. I though this should be invoked in the
aliases file like this:

helpdeskus: “| procmail /etc/.procmailrc | /opt/rt2/bin/rt-mailgate
–queue
helpdeskus --action correspond”

It, unfortunately, sends a blank, header-less, body-less email to RT. I’m
not sure what I’m doing wrong here. I thought you may be able to suggest
a

You would be better off invoking rt-mailgate from within the procmailrc.
I do my mail delivery to RT via:

aliases file:
# Run rt2 as the rt2 user, not as root.
test-rt2: “| /usr/bin/procmail -m
/etc/procmailrcs/rt2-test”

/etc/procmailrcs/rt2-test:

# This file MUST be owned by the rt2 user.  See '-m' description
# in the procmail man page.
HOME=/home/rt2
INCLUDERC=$HOME/.procmailrc-test

# are we still here after including?  Dump it to someone
:0
! joe_bloggs@example.com

( The above two snippets gets procmail running, as the rt2 user, a
procmail file for the specific queue. I really really dislike relying
on setuid stuff. )

/home/rt2/.procmailrc-test

# This file does any filtering/mail manipulations/etc before
# calling rt-mailgate.

HOME=/home/rt2
LOGFILE=log/procmail.log
VERBOSE=no

# Go away you naughty annoying spammer
:0
* ^From:.*badguy@example.com
/dev/null

# Place mailfiltering here
:0 f
| /home/rt2/bin/my_custom_filter_program

# Accept the mail into mailgate.  We { } enclose it incase we want
# a last-ditch filter.
:0
{
  # Use a lockfile to ensure only one rt-mailgate process.
  :0 :.procmail.lock
  | /home/rt2/bin/rt-mailgate --queue TEST --action correspond

  # Something went wrong.  Dump it to someone
  :0e
  ! joe.bloggs@example.com
}

Regards,

                         Bruce Campbell                            RIPE
               Systems/Network Engineer                             NCC
             www.ripe.net - PGP562C8B1B                      Operations

This email message may contain information that is confidential and
proprietary to Babcock & Brown or a third party. If you are not the
intended recipient, please contact the sender and destroy the original and
any copies of the original message. Babcock & Brown takes measures to
protect the content of its communications. However, Babcock & Brown cannot
guarantee that email messages will not be intercepted by third parties or
that email messages will be free of errors or viruses.