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 ]
man rt-mailgate for more.
Specifies what happens to email sent to this alias. The avaliable
basic actions are:
If you've set the RT configuration variable $RT::UnsafeEmailCommands,
resolve are also available. 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-resolve as actions.
resolve actions ignore message text if used
alone. Include a
correspond action if you want RT
to record the incoming message.
The default action is
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
procmail, or in a .forward or
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 different machine.
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
@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::MailPlugins array, if
they behave as described below.
What's actually going on in the above is that
@RT::MailPlugins is a
list of Perl modules; RT prepends
RT::Interface::Email:: to the name,
to form a package name, and then
use's this module. The module is
expected to provide a
GetCurrentUser subroutine, which takes a hash of
MIME::Entityobject representing the email
It returns two values, the new
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.
-1 is returned, then the processing of the plug-ins
stops immediately and the message is ignored.