7.1.1 exim
From: seph
Date: 10 Aug 2001 18:07:09 -0700
User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7
Subject: [rt-users] rt-mailgate and exim
List-Id: For users of RT: Request Tracker
I recently installed rt2 onto a machine that was using exim as it's
MTA. While configuring the various aliases I figured there ought be a
better way. So I hacked at my exim.conf for a bit (with help from a
friend) and ended up with a machine where I can send mail to
rt-queue+action@host, and it will DTRT.
basicly I told exim that I had a local user "rt" (I don't) and that -
was a prefix and + was a suffix, and that it should send all mail for
this user to a transport. The transport just execs rt-mailgate with
the relevant command line flags.
my end setup will have my hacked exim.conf on the rt2 host, and my
domain's main mail server will have aliases like:
abuse: rt-abuse+correspond@rt2
I find this much simpler than having big long aliases somewhere.
anyhow, I figured I'd share....
in the TRANSPORTS section of my exim.conf I've added:
# my rt hack
local_delivery_rt:
driver = pipe
command = "/usr/local/rt2/bin/rt-mailgate --queue ${quote:$local_part} --action ${quote:${substr_1:$local_part_suffix}}"
return_path_add
return_output
prefix = ""
suffix = ""
user = www-data
and in the DIRECTORS section I've added:
localuser_rt:
driver = smartuser
suffix = +*
prefix = *-
new_address = ${quote:${lc:${local_part}}}@${domain}
transport = local_delivery_rt
7.1.2 Qmail
rev 1.0 - 25 June 2001 - Karel P Kerezman
This short document will attempt to deal with the issue of how to make Qmail and Request Tracker 2 operate together in peace and harmony. I'm not going to go into too much detail about how queues are created and administered in RT2, nor am I going to explain the entire aliasing system in Qmail. If you're old enough to play with these toys, sonny, you're old enough to read the appropriate instruction manuals. =)
If you're migrating from the original RT to RT2, you may face a bit of a dilemma. This is the scenario I faced, but the tips and instructions here will apply to brand-new RT2 administrators as well. Here we sum up the basic set of problems:
- The usual place to put aliases in Qmail is ~alias. These aliases run as Qmail's alias user, with the rights and permissions thereunto pertaining. Better minds than mine could probably find a way to make this work, but I found another solution that makes pretty good organizational sense as well.
- The solution I've come up with will probably require a change in the queue email addresses. It wasn't a problem in our environment, but may be a sticky wicket in yours. You've been warned.
And so, without further ado, here's what you should do if you want to be just like me. (That's a scary thought, isn't it?)
- For each queue, create two files in ~rt, a .qmail-queue and .qmail-queuecomment file. For example I have in /home/rt the files .qmail-office and .qmail-officecomment that contain the following, respectively:
|/opt/rt2/bin/rt-mailgate --queue Office --action correspond
|/opt/rt2/bin/rt-mailgate --queue Office --action comment
- Set the correspond and comment addresses for your queue to rt-queue@hostname and rt-queuecomment@hostname, respectively. In my example, for instance, I have rt-office@lancelot.kgon.com and rt-officecomment@lancelot.kgon.com. (I freely admit that the "comment" address is a bit cumbersome. You're always free to come up with a better way to do it now that you've seen how it works.)
That's really all there is to it. But I hear you asking, "Why do I have to do it this way? Why can't you use 'office@lancelot.kgon.com' instead?" It has to do with the way Qmail handles aliases, and the way permissions affect the operation of RT2's mail gateway. As stated above, generic system aliases are stored in ~alias (usually /var/qmail/alias) and if the alias is a piped system command that command is run as the alias user. This wasn't a problem in RT1, but for some reason Qmail and RT2 don't quite cooperate when it comes to running RT2's suid-wrapped mailgate. (I invite those better versed in this situation to contribute a better explanation to this document.)
There is one user that can run rt-mailgate with impunity, though, and that's the rt user. So the logical thing to do is to place the alias files into the rt user directory. Of course, the only way these aliases will be called is if email is sent to rt-(aliasname)@(hostname). And so have we done here.
A quick tip: If you're like me, and too few are, you want to have an "incoming" queue that anyone can send mail to so as to create new tickets. In our case that's the General queue, and we have an easy-to-remember email address available for that queue. It goes something like this:
- You might as well have a "plain" .qmail file in order to deal with mail sent to rt@hostname, right? So fill it like this:
|/opt/rt2/bin/rt-mailgate --queue General --action correspond
- Then make sure that the General queue is set appropriately to allow non-members to create requests.
- Use rt@hostname as the recipient in any single-page web forms you create on your intranet to feed tasks into your system, and/or give out rt@hostname to your users along with the basic run-down on how RT2 will work for them and for your environment. (For the record, a cheesy example web form can be found at http://washuu.kgon.com/addto.htm .)
This concludes my Qmail and RT2 documentation. Comments, suggestions and constructive critiques are welcomed at rael@zero.kgon.com. Flames, of course, will be fed to our pet betta fish. Future revisions may appear pending inspiration and commentary.