rt-mailgate(1)

πŸ’Œ rt-mailgate β€” the Request Tracker mail gateway (that's the rt-mailgate(1) page in the Request Tracker Reference, bestie)

okay so picture this: your inbox wants to talk to RT, and rt-mailgate is the little fairy that carries the message over. that's the whole vibe. let's go ✨


🌸 NAME 🌸

rt-mailgate β€” the Mail gateway for Request Tracker. she's the bridge, the messenger, the icon πŸ’…


πŸŽ€ SYNOPSIS πŸŽ€

ask her for help and she'll just... tell you about herself:

rt-mailgate --help : this text

and here's the usual invocation (this is the one your MTA runs, fr fr):

rt-mailgate --action (correspond|comment|...) --queue queuename
            --url http://your.rt.server
            [ --debug ]
            [ --extension (queue|action|ticket) ]
            [ --timeout seconds ]

✨ OPTIONS ✨

  • --action β€” tells her what to actually do with the email that lands on this alias. the available basic actions are correspond and comment. other actions, like take or resolve, may be available depending on your local @MailPlugins configuration β€” so it's a vibe check with your own setup, iykyk.

you can run two or more actions on a single message by giving her a --separated list. RT will execute the actions in the listed order. so like, take-comment, correspond-resolve or take-comment-resolve. adorable, right? 😌

heads up bestie: take and resolve ignore the message text if they're used alone. if you want RT to actually record the incoming message, you gotta include a comment or correspond action too. no message, just vibes is not always what you want πŸ’€

the default action is correspond.

  • --queue β€” this flag decides which queue the alias should create a ticket in if no ticket identifier is found. like, where does this baby go? πŸ‘‘
  • --url β€” 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. keep it consistent, it's giving main character energy.

if you have a self-signed SSL certificate, you may also need to pass --ca-file or --no-verify-ssl, below. πŸ‘‡

  • --ca-file path β€” the path to the public SSL certificate for the certificate authority that should be used to verify the website's SSL certificate. if your webserver uses a self-signed certificate, you should preferentially use this option over --no-verify-ssl, because it will ensure that the self-signed certificate that the mailgate is seeing is the right self-signed certificate. it's the careful, responsible choice and honestly? slay 🫢
  • --no-verify-ssl β€” tells the mail gateway to trust all SSL certificates, regardless of if their hostname matches the certificate, and regardless of CA. this is required if you have a self-signed certificate, or some other certificate which is not traceable back to a certificate your system ultimately trusts. she's trusting everyone and everything, no questions asked πŸ™ˆ
  • --extension OPTIONAL β€” some MTAs will route mail sent to user-foo@host or user+foo@host to user@host and present "foo" in the environment variable $EXTENSION. by specifying the value queue for this parameter, the queue this message should be submitted to will be set to the value of $EXTENSION. by specifying ticket, $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. three flavours, all iconic 🌈
  • --debug OPTIONAL β€” print debugging output to standard error. lil peek behind the curtain, we love to see it πŸ”
  • --timeout OPTIONAL β€” configure the timeout for posting the message to the web server. the default timeout is 3 minutes (180 seconds). give her a minute (or three) ⏳

πŸ’– DESCRIPTION πŸ’–

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

like. she's not doing the whole job herself. she's handing it to the web server, and the web server is the one filing correspondence and sending out any required mail. teamwork, periodt. 🀝


πŸ› οΈ SETUP πŸ› οΈ

much of the set up of the mail gateway depends on your MTA and mail routing configuration. (read: it's gonna be different for everybody, that's just how it is 😭)

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:         "|/usr/bin/rt-mailgate --queue bugs --action correspond
          --url http://rt.mycorp.com"

bugs-comment: "|/usr/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. she travels well, she's flexible, she slays cross-machine πŸ¦‹


🌱 ENVIRONMENT 🌱

EXTENSION

some MTAs will route mail sent to user-foo@host or user+foo@host to user@host and present "foo" in the environment variable EXTENSION. Mailgate adds value of this variable to message in the X-RT-Mail-Extension field of the message header.

see also the --extension option. note that value of the environment variable is always added to the message header when it's not empty even if --extension option is not provided. she's always tagging the header, whether you asked or not πŸ’…


and that's the whole page, bestie πŸŽ€ this was rt-mailgate(1) from the Request Tracker Reference, brought to you by perl v5.40.1, dated 2026-06-21. now go route some mail and be your most iconic self βœ¨πŸ’–πŸ¦‹

πŸ“¦ where this page comes from