rt-mailgate(1)

NAME

rt-mailgate - Mail gateway for Request Tracker

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 "man rt-mailgate" for more.

OPTIONS

"--action"

Specifies what happens to email sent to this alias.

The avaliable basic actions are: "correspond", "comment".

If you've set the RT configuration variable

$RT::UnsafeEmailCommands, "take" and "resolve" are also avail

able. You can execute two or more actions on a single message

using a "-" separated list. RT will execute the actions in the

listed order. For example you can use "take-comment", "corre

spond-resolve" or "take-comment-resolve" as actions.

Note that "take" and "resolve" actions ignore message

text if used alone. Include a "comment" or "correspond" action

if you want RT to record the incoming message.

The default action is "correspond".

"--queue"

This flag determines which queue this alias should cre

ate a ticket in if no ticket identifier is found.

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

"--extension" OPTIONAL

Some MTAs will route mail sent to user-foo@host or us

er+foo@host to user@host and present "foo" in the environment

variable $EXTENSION. By specifying the value "queue" for this pa

rameter, the queue this message should be submitted to will be

set to the value of $EXTENSION. By specifying "ticket", $EXTEN

SION will be interpreted as the id of the ticket this message is

related to. "action" will allow the user to specify either "com

ment" or "correspond" in the address extension.

"--debug" OPTIONAL

Print debugging output to standard error

"--timeout" OPTIONAL

Configure the timeout for posting the message to the

web server. The default timeout is 3 minutes (180 seconds).

DESCRIPTION

The RT mail gateway is the primary mechanism for communi

cating 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 "procmail", or in a .forward or equivalent.

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 "rt-mailgate" for the

queues you're monitoring. For instance, if you're using

/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 differ

ent machine.

CUSTOMIZATION

By default, the mail gateway will accept mail from anyone.

However, there are situations in which you will want to authenti

cate 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 @RT::MailPlugins to be a list of

plugins. The default plugin, if this is not given, is

"Auth::MailFrom" - that is, authentication of the person is done

based on the "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 @RT::MailPlug

ins array, if they behave as described below.

WRITING PLUGINS

What's actually going on in the above is that

@RT::MailPlugins is a list of Perl modules; RT prepends "RT::In

terface::Email::" to the name, to form a package name, and then

"use"'s this module. The module is expected to provide a "GetCur

rentUser" subroutine, which takes a hash of several parameters:

Message

A "MIME::Entity" object representing the email

CurrentUser

An "RT::CurrentUser" object

AuthStat

The authentication level returned from the previous

plugin.

Ticket [OPTIONAL]

The ticket under discussion

Queue [OPTIONAL]

If we don't already have a ticket id, we need to

know which queue we're talking about

Action

The action being performed. At the moment, it's one

of "comment" or "correspond"

It returns two values, the new "RT::CurrentUser" ob

ject, and the new authentication level. The authentication level

can be zero, not allowed to communicate with RT at all, (a "per

mission denied" error is mailed to the correspondent) or one,

which is the normal mode of operation. Additionally, if "-1" is

returned, then the processing of the plug-ins stops immediately

and the message is ignored.

perl v5.8.8 2007-03-03

rt-mailgate(1)