[rt-users] I give up!

Wagner Pereira wpereira at pop-sp.rnp.br
Tue Jan 26 12:23:58 EST 2010


Hi, Jason.

Mauricio Tavares asked me the same, in a previous message, and below is 
my answer.

Some colleagues suggested me don't use fetchmail, because this would 
make the scenario more complex than the necessary.

---------------------------------------------
I've installed the rt-mailgate. See below how the rt-mailgate-3.6 is set 
up. Actually, I edited nothing in it until now.

#!/usr/bin/perl -w
# BEGIN BPS TAGGED BLOCK {{{
#
# COPYRIGHT:
#
# This software is Copyright (c) 1996-2008 Best Practical Solutions, LLC
#                                          <jesse at bestpractical.com>
#
# (Except where explicitly superseded by other copyright notices)
#
#
# LICENSE:
#
# This work is made available to you under the terms of Version 2 of
# the GNU General Public License. A copy of that license should have
# been provided with this software, but in any event can be snarfed
# from www.gnu.org.
#
# This work is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software
# Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
# 02110-1301 or visit their web page on the internet at
# http://www.gnu.org/licenses/old-licenses/gpl-2.0.html.
#
#
# CONTRIBUTION SUBMISSION POLICY:
#
# (The following paragraph is not intended to limit the rights granted
# to you to modify and distribute this software under the terms of
# the GNU General Public License and is only of importance to you if
# you choose to contribute your changes and enhancements to the
# community by submitting them to Best Practical Solutions, LLC.)
#
# By intentionally submitting any modifications, corrections or
# derivatives to this work, or any other work intended for use with
# Request Tracker, to Best Practical Solutions, LLC, you confirm that
# you are the copyright holder for those contributions and you grant
# Best Practical Solutions,  LLC a nonexclusive, worldwide, irrevocable,
# royalty-free, perpetual, license to use, copy, create derivative
# works based on those contributions, and sublicense and distribute
# those contributions and any derivatives thereof.
#
# END BPS TAGGED BLOCK }}}
=head1 NAME

rt-mailgate - Mail interface to RT3.

=cut


use strict;
use warnings;
use Getopt::Long;
use LWP::UserAgent;

use constant EX_TEMPFAIL => 75;

my %opts;
GetOptions( \%opts, "queue=s", "action=s", "url=s", "jar=s", "help", 
"debug", "extension=s", "timeout=i" );

if ( $opts{help} ) {
   require Pod::Usage;
   import Pod::Usage;
   pod2usage("RT Mail Gateway\n");
   exit 1;    # Don't want to succeed if this is really an email!
}

for (qw(url)) {
   die "$0 invoked improperly\n\nNo $_ provided to mail gateway!\n" 
unless $opts{$_};
}

my $ua      = LWP::UserAgent->new();
$ua->cookie_jar( { file => $opts{jar} } );

my %args = (
   SessionType => 'REST', # Surpress login box
);
foreach ( qw(queue action) ) {
   $args{$_} = $opts{$_} if defined $opts{$_};
};

# Read the message in from STDIN
$args{'message'} = do { local (@ARGV, $/); <> };

unless ( $args{message} =~ /\S/ ) {
   print STDERR "$0: no message passed on STDIN!\n";
   exit 0;
}

if ($opts{'extension'}) {
       $args{$opts{'extension'}} = $ENV{'EXTENSION'};
}

# Set up cookie here.

my $full_url = $opts{'url'}. "/REST/1.0/NoAuth/mail-gateway";
warn "Connecting to $full_url" if $opts{'debug'};



$ua->timeout(exists($opts{'timeout'}) ? $opts{'timeout'} : 180);
my $r = $ua->post( $full_url, {%args} );
check_failure($r);

my $content = $r->content;
warn $content if ($opts{debug});

if ( $content !~ /^(ok|not ok)/ ) {

   # It's not the server's fault if the mail is bogus. We just want to 
know that
   # *something* came out of the server.
   warn <<EOF;
RT server error.

The RT server which handled your email did not behave as expected. It
said:

$content
EOF

exit EX_TEMPFAIL;

}

exit;


sub check_failure {
   my $r = shift;
   return if $r->is_success();

   # This ordinarily oughtn't to be able to happen, suggests a bug in RT.
   # So only load these heavy modules when they're needed.
   require HTML::TreeBuilder;
   require HTML::FormatText;

   my $error = $r->error_as_HTML;
   my $tree  = HTML::TreeBuilder->new->parse($error);
   $tree->eof;

   # It'll be a cold day in hell before RT sends out bounces in HTML
   my $formatter = HTML::FormatText->new( leftmargin  => 0,
                                          rightmargin => 50 );
   warn $formatter->format($tree);
   warn "This is $0 exiting because of an undefined server error" if 
($opts{debug});
   exit EX_TEMPFAIL;
}


=head1 SYNOPSIS

   rt-mailgate --help : this text

Usual invocation (from MTA):

   rt-mailgate --action (correspond|comment|...) --queue queuename
               --url http://your.rt.server/
               [ --debug ]
               [ --extension (queue|action|ticket) ]
               [ --timeout seconds ]



See C<man rt-mailgate> for more.

=head1 OPTIONS

=over 3

=item C<--action>

Specifies what happens to email sent to this alias.  The avaliable
basic actions are: C<correspond>, C<comment>.


If you've set the RT configuration variable B<$RT::UnsafeEmailCommands>,
C<take> and C<resolve> are also available.  You can execute two or more
actions on a single message using a C<-> separated list.  RT will execute
the actions in the listed order.  For example you can use C<take-comment>,
C<correspond-resolve> or C<take-comment-resolve> as actions.

Note that C<take> and C<resolve> actions ignore message text if used
alone.  Include a  C<comment> or C<correspond> action if you want RT
to record the incoming message.

The default action is C<correspond>.

=item C<--queue>

This flag determines which queue this alias should create a ticket in if 
no ticket identifier
is found.

=item C<--url>

This flag tells the mail gateway where it can find your RT server. You 
should
probably use the same URL that users use to log into RT.


=item C<--extension> OPTIONAL

Some MTAs will route mail sent to user-foo at host or user+foo at host to 
user at host
and present "foo" in the environment variable $EXTENSION. By specifying
the value "queue" for this parameter, the queue this message should be
submitted to will be set to the value of $EXTENSION. By specifying
"ticket", $EXTENSION will be interpreted as the id of the ticket this 
message
is related to.  "action" will allow the user to specify either "comment" or
"correspond" in the address extension.

=item C<--debug> OPTIONAL

Print debugging output to standard error


=item C<--timeout> OPTIONAL

Configure the timeout for posting the message to the web server.  The
default timeout is 3 minutes (180 seconds).


=head1 DESCRIPTION

The RT mail gateway is the primary mechanism for communicating with RT
via email. This program simply directs the email to the RT web server,
which handles filing correspondence and sending out any required mail.
It is designed to be run as part of the mail delivery process, either
called directly by the MTA or C<procmail>, or in a F<.forward> or
equivalent.

=head1 SETUP

Much of the set up of the mail gateway depends on your MTA and mail
routing configuration. However, you will need first of all to create an
RT user for the mail gateway and assign it a password; this helps to
ensure that mail coming into the web server did originate from the
gateway.

Next, you need to route mail to C<rt-mailgate> for the queues you're
monitoring. For instance, if you're using F</etc/aliases> and you have a
"bugs" queue, you will want something like this:

   bugs:         "|/opt/rt3/bin/rt-mailgate --queue bugs --action 
correspond
             --url http://rt.mycorp.com/"

   bugs-comment: "|/opt/rt3/bin/rt-mailgate --queue bugs --action comment
             --url http://rt.mycorp.com/"

Note that you don't have to run your RT server on your mail server, as
the mail gateway will happily relay to a different machine.

=head1 CUSTOMIZATION

By default, the mail gateway will accept mail from anyone. However,
there are situations in which you will want to authenticate users
before allowing them to communicate with the system. You can do this
via a plug-in mechanism in the RT configuration.

You can set the array C<@RT::MailPlugins> to be a list of plugins. The
default plugin, if this is not given, is C<Auth::MailFrom> - that is,
authentication of the person is done based on the C<From> header of the
email. If you have additional filters or authentication mechanisms, you
can list them here and they will be called in order:

   @RT::MailPlugins = (
       "Filter::SpamAssassin",
       "Auth::LDAP",
       # ...
   );

See the documentation for any additional plugins you have.

You may also put Perl subroutines into the C<@RT::MailPlugins> array, if
they behave as described below.

=head1 WRITING PLUGINS

What's actually going on in the above is that C<@RT::MailPlugins> is a
list of Perl modules; RT prepends C<RT::Interface::Email::> to the name,
to form a package name, and then C<use>'s this module. The module is
expected to provide a C<GetCurrentUser> subroutine, which takes a hash of
several parameters:

=over 4

=item Message

A C<MIME::Entity> object representing the email

=item CurrentUser

An C<RT::CurrentUser> object

=item AuthStat

The authentication level returned from the previous plugin.

=item Ticket [OPTIONAL]

The ticket under discussion

=item Queue [OPTIONAL]

If we don't already have a ticket id, we need to know which queue we're 
talking about

=item Action

The action being performed. At the moment, it's one of "comment" or 
"correspond"

=back 4

It returns two values, the new C<RT::CurrentUser> object, and the new
authentication level. The authentication level can be zero, not allowed
to communicate with RT at all, (a "permission denied" error is mailed to
the correspondent) or one, which is the normal mode of operation.
Additionally, if C<-1> is returned, then the processing of the plug-ins
stops immediately and the message is ignored.

=cut
---------------------------------------------

-- 

Wagner Pereira

PoP-SP/RNP - Ponto de Presença da RNP em São Paulo
CCE/USP - Centro de Computação Eletrônica da Universidade de São Paulo
http://www.pop-sp.rnp.br
Tel. (11) 3091-8901



Jason Ledford escreveu:
> I sort followed this guide http://www.debianadmin.com/howto-setup-request-tracker-36-on-debian-etch.html and other guides that are very similar.
>
> The fetchmail part I think is what you are looking for.  Fetchmail will log onto your mail server via pop3 and download the messages and inject them into RT.
>
> Here is my relevant fetchmail config:
> **************
> poll my.mail.server.com
> protocol pop3 uidl
> auth password
> username "rt-support" password "somepassword"
> mda "/usr/bin/rt-mailgate-3.8 --queue MYQUEUENAME --action correspond --url http://rt.f.q.d.n/rt/"
> no keep
> *************
>
> I added the * to try and highlight that specific part.  Are you using fetchmail or how are you injecting messages into RT?
>
> -----Original Message-----
> From: rt-users-bounces at lists.bestpractical.com [mailto:rt-users-bounces at lists.bestpractical.com] On Behalf Of Wagner Pereira
> Sent: Tuesday, January 26, 2010 9:50 AM
> To: RT-Users at lists.bestpractical.com
> Subject: [rt-users] I give up!
>
> Ok, I admit: I'm lost!
>
> Since I've installed RT on my Debian lenny, it is running perfectly, OK.
>
> But, I really can't create a ticket via e-mail message. The more I edit 
> the necessary files for it, the more I am lost!
>
> My scenario is:
>
> Mail server: Debian 4.0 etch - running Courier-MTA
> RT server: Debian 5.0 lenny
>
> What should I do? What could you guys suggest me?
>
>   



More information about the rt-users mailing list