rt-mailgate - Mail gateway for Request Tracker

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

Specifies what happens to email sent to this alias. The avaliable basic actions are: CWcorrespond, CWcomment. If you've set the RT configuration variable $RT::UnsafeEmailCommands, CWtake and CWresolve are also available. You can execute two or more actions on a single message using a CW- separated list. RT will execute the actions in the listed order. For example you can use CWtake-comment, CWcorrespond-resolve or CWtake-comment-resolve as actions. Note that CWtake and CWresolve actions ignore message text if used alone. Include a CWcomment or CWcorrespond action if you want RT to record the incoming message. The default action is CWcorrespond. This flag determines which queue this alias should create a ticket in if no ticket identifier is found. 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. Some MTAs will route mail sent to user-foo@host or user+foo@host to user@host and present foo in the environment variable CW$EXTENSION. By specifying the value queue for this parameter, the queue this message should be submitted to will be set to the value of CW$EXTENSION. By specifying ticket, CW$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. Print debugging output to standard error Configure the timeout for posting the message to the web server. The default timeout is 3 minutes (180 seconds).

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 CWprocmail, or in a .forward or equivalent.

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 CWrt-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/"

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 CW@RT::MailPlugins to be a list of plugins. The default plugin, if this is not given, is CWAuth::MailFrom - that is, authentication of the person is done based on the CWFrom 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",
        # ...
    );

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

Message

A CWMIME::Entity object representing the email

CurrentUser

An CWRT::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 CWRT::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 CW-1 is returned, then the processing of the plug-ins stops immediately and the message is ignored.