Note: This page will get updated with more information as time goes on…

There are important facets to running a business, including: customer service, internal requests, external requests. Management of these requests is commonly misunderstood by associates/employees. These systems provide accountability while also allowing coworkers to spread the wealth in terms of opportunities to make a difference in another’s life.

Navigating and completing a tutorial is far different than configuring and operating a ticket system. The basics can be completed, but the configuration depends on the needs of the organization more so than just an online tutorial. However, before any configuring there is a major hurdle to using an email ticket system, which is the basic issues of email.

In the journey to write the page, there have been many stumbles that have been overcome. However, there is a basic issue that must be solved prior to taking on this task: reverse DNS or PTR records must exist for the IP address of the Request Tracker installation. It is noted in the PTR records link that the records are used for validation, which is important to get the receiving email service to accept emails. There are additional records that must be handled as well, like SPF and DKIM. These are barriers that cannot bee solved without the help of colocation fees or appropriate internet connection plans.

Establishment of a Let’s Encrypt SSL Certificate

Today, web traffic is often handled over a secure connection to prevent malicious eavesdropping by third parties. The eavesdropping can lead to other issues, like security breaches, and other forms of malice. It is important to keep the information traveling over the Internet encrypted such that only the two parties involved in the conversation understand the conversation. Third parties may still be able to see a conversation occurring, but they cannot tell what is being said.

The initial step is to install the certbot program on a Debian 12 server. (This is after all the appropriate software has been updated and upgraded.)

sudo apt-get update && sudo apt-get upgrade -y ; apt-get install certbot

After the installation of the program, I decided it would be most advantageous to utilize the DNS challenge to issue a certificate as the box is being prepared in a remote location. (There is no ability to use an HTTP-01 challenge at the moment.)

sudo certbot certonly --manual --preferred-challenges dns -d "tickets.mydomain.com"

The program will issue instructions on the creation of a specific DNS record that may be queried by the Let’s Encrypt services to ensure validation. There is a place within the instructions where the program stops and waits for the user to press “Enter.” The DNS record must be inserted and verified as ready to go before pressing the Enter key.

The certbot will respond with the appropriate files for the fullchain.pem and privkey.pem once Let’s Encrypt has issued an SSL certificate.

Installing Apache + Request Tracker

It is simple enough in Debian 12 (Bookworm) to do the basic installation of Request Tracker. Normally, it might be worth it to investigate the use of containerization software, like Docker, but this is just for a quick setup.

sudo apt-get install rt5-apache2 rt5-db-mysql rt5-doc-html request-tracker5 mariadb-server

The defaults are pretty sane when it comes to installing the system. I just accepted those, except for “RTName.” I did change the name to something that makes more sense to the domain name being used.

There is a personal preference of mysql/mariadb over postgres.

sudo a2enmod rewrite suexec include fcgid perl ssl
sudo a2ensite default-ssl
sudo a2dissite 000-default

There was also the addition of the security certificates to the apache config in /etc/apache2/sites-enabled/default-ssl.conf:

ServerName tickets.yourdomain.com
SSLCertificateFile      /etc/letsencrypt/live/tickets.yourdomain.com/cert.pem
SSLCertificateKeyFile   /etc/letsencrypt/live/tickets.yourdomain.com/privkey.pem
SSLCertificateChainFile /etc/letsencrypt/live/tickets.yourdomain.com/fullchain.pem

Afterward, there are some minor massages that need to be made:

cd /etc/request-tracker5/RT_SiteConfig.d
sudo cp 50-debconf.pm 90-local.pm
sudo vim 90-local.pm

Afterward, there are a few things to set:

Set($rtname, 'yourdomain');
Set($Organization, 'tickets.yourdomain.com');
Set($CorrespondAddress , 'rt@tickets.yourdomain.com');
Set($CommentAddress , 'rt-comment@tickets.yourdomain.com');
# THE WEBSERVER:
Set($WebPath , "/rt");
Set($WebBaseURL , "https://tickets.yourdomain.com");

There are many configurations to be made within RT to customize its look and feel as well as its operation. Then there is the mail service piece!

Configuring Exim4

There is a basic configuration that can be done using dpkg-reconfigure exim4-config. It is possible to run request tracker just as a web service to handle internal tickets whereby there is no mail service. (Request Tracker does not require email to function.)

After running certbot and getting a valid SSL certificate, it is imperative to get it functioning within the various services. It was not a serious issue to reconfigure apache2 to use the certificates. However, exim4 is a little more complex in its configuration.

After much testing to change the location of the SSL keys, it was determined to be much easier to just copy the keys into /etc/exim4. There were various methods tried, including modifying the configuration of Exim. Following some of the online tutorials caused errors in the configuration. (tls_* cannot be set twice.)

sudo cp /etc/letsencrypt/live/yourdomain.com/fullchain.pem /etc/exim4/exim.crt
sudo cp /etc/letsencrypt/live/yourdomain.com/privkey.pem /etc/exim4/exim.key

That should be enough to get email working with the appropriate STARTTLS commands that most email services require. However, tests to one of the most popular email services yielded the following results in /var/log/exim4/mainlog:

2025-05-17 21:00:08 1uGVC1-0002SY-1D ** youremail@gmail.com R=dnslookup T=remote_smtp H=gmail-smtp-in.l.google.com [74.125.21.26] X=TLS1.3:ECDHE_X25519__ECDSA_SECP256R1_SHA256__AES_256_GCM:256 CV=yes DN="CN=mx.google.com": SMTP error from remote mail server after pipelined end of data: 550-5.7.26 Your email has been blocked because the sender is unauthenticated.\n550-5.7.26 Gmail requires all senders to authenticate with either SPF or DKIM.\n550-5.7.26\n550-5.7.26  Authentication results:\n550-5.7.26  DKIM = did not pass\n550-5.7.26  SPF [] with ip: [209.xxx.yyy.zzz] = did not pass\n550-5.7.26\n550-5.7.26  For instructions on setting up authentication, go to\n550 5.7.26  https://support.google.com/mail/answer/81126#authentication 3f1490d57ef6-e7b6afc5591si4473863276.217 - gsmtp

And

2025-05-17 21:00:08 1uGVC1-0002Sk-30 ** youremail@gmail.com R=dnslookup T=remote_smtp H=gmail-smtp-in.l.google.com [74.125.21.26] X=TLS1.3:ECDHE_X25519__ECDSA_SECP256R1_SHA256__AES_256_GCM:256 CV=yes DN="CN=mx.google.com": SMTP error from remote mail server after pipelined end of data: 550-5.7.25 [209.65.191.38] The IP address sending this message does not have a\n550-5.7.25 PTR record setup, or the corresponding forward DNS entry does not\n550-5.7.25 match the sending IP. As a policy, Gmail does not accept messages\n550-5.7.25 from IPs with missing PTR records. For more information, go to\n550-5.7.25  https://support.google.com/a?p=sender-guidelines-ip\n550-5.7.25 To learn more about Gmail requirements for bulk senders, visit\n550 5.7.25  https://support.google.com/a?p=sender-guidelines. 3f1490d57ef6-e7b6aff71c7si796017276.416 - gsmtp