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?

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

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?

  Do you have something setup to feed emails into RT?

I sort followed this guide Howto setup Request-Tracker 3.6 on Debian Etch | Debian Admin 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@lists.bestpractical.com [mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Wagner Pereira
Sent: Tuesday, January 26, 2010 9:50 AM
To: RT-Users@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?

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

http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

2010 RT Training Sessions!
San Francisco, CA, USA - Feb 22 & 23
Dublin, Ireland - Mar 15 & 16
Boston, MA, USA - April 5 & 6
Washington DC, USA - Oct 25 & 26

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

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@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

GNU General Public License v2.0 - GNU Project - Free Software Foundation.

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 for more.

=head1 OPTIONS

=over 3

=item C<–action>

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

If you’ve set the RT configuration variable B<$RT::UnsafeEmailCommands>,
C and C 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,
C or C as actions.

Note that C and C actions ignore message text if used
alone. Include a C or C action if you want RT
to record the incoming message.

The default action is C.

=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@host or user+foo@host to
user@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, 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 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 CAuth::MailFrom - that is,
authentication of the person is done based on the C 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 CRT::Interface::Email: to the name,
to form a package name, and then C's this module. The module is
expected to provide a C subroutine, which takes a hash of
several parameters:

=over 4

=item Message

A CMIME::Entity object representing the email

=item CurrentUser

An CRT::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 CRT::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:

Mauricio (and Jason),

I’ve implemented this model drawed on: Twitpic

That means I haven’t the fetchmail as an other layer in my
infrastructure; in both sides I wrote aliases to delivery the messages,
either from mail server (Courier) to RT server (Postfix) and from
Postfix to rt-mailgate. But it still doesn’t work fine.

Check my aliases files out below:

At the mail server side:

This line delivers the message to RT server (Postfix) which then

delivers to rt-mailgate and cares to create the new ticket
rt@pop-sp.rnp.br: rt@rtracker.rt.pop-sp.rnp.br

And at the RT server side:
rt: “|/usr/bin/rt-mailgate-3.6 --queue general --action correspond --url
https://rtracker.rt.pop-sp.rnp.br/rt/ --debug”

Hugs,

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

Tel. (11) 3091-8901

Mauricio Tavares escreveu:> On Tue, Jan 26, 2010 at 12:23 PM, Wagner Pereira wpereira@pop-sp.rnp.br wrote:

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.

[…]
Wagner (and Jason),

  I run RT in an ubuntu 9.04 box (actually a VM but hey). I looked

in my docs and did not had to edit rt-mailgate. I too use fetchmail;
my /etc/fetchmailrc looks like this

  set syslog;
  set daemon 30;

  poll "mail.domain.com"
  with protocol imap
  username rt password weak_password
  mda "/usr/bin/perl /usr/bin/rt-mailgate --url http://localhost/ \
  --queue support --action correspond"

and I set it up to start as daemon using /etc/default/fetchmail

  # This file will be used to declare some vars for fetchmail
  #
  # Uncomment the following if you don't want localized log messages
  # export LC_ALL=C

  # If you want to specify any additional OPTION to the start
  # scripts specify them here
  # OPTIONS=...

  # Declare here if we want to start fetchmail. 'yes' or 'no'
  START_DAEMON=yes
  #

That is fine but right now who cares? Most important line from
everything I’ve written above is

mda “/usr/bin/perl /usr/bin/rt-mailgate --url http://localhost/
–queue support --action correspond”

This is the line that grabs the mail fetchmail has retrieved from our
mail server and sends to rt. So, what if you run that very same perl
command (in quotes), piping the test mail to it? I just want to see if
you can feed the test email to rt. If that works, we can then worry
about getting the mail from the mail server.