[rt-users] RE: PROCMAIL

[George Warnagiris]

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 at 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 at 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;
>



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

On Mon, 4 Feb 2002, George Warnagiris wrote:

> 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 at 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 at 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 at 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.