EmailInterface
RT's config file
You should start configuration from SiteCo, all options are briefly described in the main config template, so here we'll try to add additional information that will help you understand importance of each option. As it's not complete description then you MUST always read description in the main config file.
Very important options are OwnerEmail, RTAddressRegexp and NotifyActor.
Basic options
$rtname (scalar) - name of the RT instance, is used in subject of emails to get/store ID of tickets. See also RenameInstance.
RT 3.8 has subject tag option per each queue that can allow you override strings used in subject.
$SendmailArguments (string) -- To change the return-path, you need to add the -f switch followed by your email address e.g.: -oi -t -f whatever(leftbracket)at(rightbracket)yourdomain.tld
$OwnerEmail (email address) - address of RT's administrator important error messages are send to.
Loops prevention
$LoopsToRTOwner (boolean) - send or not loops to owner
$StoreLoops (boolean) - record message even if it's loop
$RTAddressRegexp (regular expression) - used to prevent RT from ending up in a loop within itself, for example when $ParseNewMessageForTicketCcs is enabled. This can get complicated if there are several names for the server; for this reason, it's recommended you place your RT email addresses into a namespace such as rt-foo\@example.com
, rt-bar\@example.com
, etc. to make this as straightforward as possible.
- See also RTAddressRegexp which describes how to write this regular expression.
Attachments handling
$MaxAttachmentSize (int, bytes) - sets the maximum size of attachments stored in the database
$TruncateLongAttachments, $DropLongAttachments (boolean) - truncate or drop long attachments, note that truncation most probably will corrupt binary files, like images, word documents and other.
Other options
$ParseNewMessageForTicketCcs (boolean) - when $ParseNewMessageForTicketCcs is true, RT automatically adds email addresses found in the Cc header to the ticket's Cc at creation.
See also ParseFollowupMessageForTicketCcs.
$NotifyActor (boolean) - normally, when someone updates a ticket, etc., email is sent to the apropriate people, excluding the person who performed the action. RT reasons the person knows what they did. If $NotifyActor is set to a true value (e.g. 1, or just about anything but 0 or empty string), the performer of the action will be included in the notifications. Default is false (0).
RT's mail gate
RT handles its incoming emails with a rt-mailgate script that passes emails over http protocol to a RT's web server.
Note that the HTTP interface used by mailgate is not protected by default and you must take care of it yourself. Read MailGatewayAccessControl to understand how to improve security of this interface.
First of all you have to add email aliases for each queue. See the following:
- ManualInstallation
- Qmail - Using Qmail Aliases w/ RT
- Using Procmail to deliver RT-mail to queues
- EximConfig
- EximConfigVirtualDomain
- PostfixConfig
Delivering mail without many aliases
Fetching emails from POP/IMAP/MBOXes
The following articles describe several ways to obtain incoming email for RT from POP/IMAP servers or mboxes:
Mail server is another host
You can install the mailgate script on any server that has access by http(s) to a server you're running RT on. Read InstallMailgateOnly.
Handling spam
Handling bounces
Other
- EmailRouting
- html2mime
- VirtualDomain
- MSExchangeRelay - Configure Exchange to relay mail to and from RT
- PostFixSQLAliasProblem - Problems with alias map in a Postfix SQL database.
- GoogleApps - How to configure RT for use with GoogleApps.
Configuring outgoing email
Technical part
Outgoing emails can be sent using a command line program (like sendmail) or via SMTP server. It's recommended to use a robust command line program to avoid penalties. You may read perfomance considerations on SendmailTips page.
Notifications and other outgoing emails are controlled by Scrips. You can change them using the web UI.
Config
DESCRIBE ME
Sending via SMTP server
- mailx - Sending outgoing email from RT to a remote smtp-server instead of a local MTA
- mailx is a poor option. It will always override your /Content-Type/ headers, and so can't properly handle email attachments as it will replace the /multipart/mime; boundary=xxxxxx/ header with /text/plain/. -- comment from a user
- msmtp is a great option. It's very easy to use, supports attachments, TLS.
Configuring notification scrips
- ManualScrips - default set of scrips
- ScripAction - basics on creating a new actions
- NotificationsTuning - very good article on tuning notifications
NOTE: Information vital for scrip debugging. Mainly "what mail was initiated by what script". Mail header RT-Message-ID or Message-ID is the source of many usefull information. It's being created in lib/RT/Interface/Email.pm as this:
<pre>
sub GenMessageId {
my %args = (
Ticket => undef,
Scrip => undef,
ScripAction => undef,
@_
);
my $org = RT->Config->Get('Organization');
my $ticket_id = ( ref $args{'Ticket'}? $args{'Ticket'}->id : $args{'Ticket'} ) || 0;
my $scrip_id = ( ref $args{'Scrip'}? $args{'Scrip'}->id : $args{'Scrip'} ) || 0;
my $sent = ( ref $args{'ScripAction'}? $args{'ScripAction'}->{'_Message_ID'} : 0 ) || 0;
return "<rt-". $RT::VERSION ."-". $$ ."-". CORE::time() ."-". int(rand(2000)) .'.'
. $ticket_id ."-". $scrip_id ."-". $sent ."@". $org .">" ;
}
So you can easily form this mail header recognize what scrip in what ticket is responsible for the mail.