Mailgate errors after reaching ticket #26000

We are long time users of RT (great product!). Today RT stopped accepting ticket updates by email. After a lot of head scratching I tried restoring a 3 day old snapshot (which happened to be at ticket #25908) and it worked fine. Nothing has changed since the snapshot.

We are running 4.2.8 on Debian Jessie.

The exim error:
/usr/bin/rt-mailgate --queue foo --action correspond --url hffp :/ R=system_aliases T=address_pipe defer (0): Child process of address_pipe transport returned 75 (could mean temporary error) from command: /usr/bin/rt-mailgate

In apache logs:
“POST /rt/REST/1.0/NoAuth/mail-gateway HFFP/1.1” 302 548 “-” “rt-mailgate/4.2.8 libwww-perl/6.08”

From the command line:

cat test.msg | /usr/bin/rt-mailgate --no-verify-ssl --queue tos --action correspond --url hffp:// --debug
/usr/bin/rt-mailgate: temp file is ‘/tmp/7I_cAr5adg/7uZKOrmrB1’
/usr/bin/rt-mailgate: connecting to h t t p://
HFFP request failed: 500 Can’t connect to Your webserver logs may have more information or there may be a network problem.

/usr/bin/rt-mailgate: undefined server error

The only difference between my restored snapshot and the live server is the ticket number.

I will try upgrading RT first. If that doesn’t work I will have to start with a fresh database. Please let me know if anyone has run in to this before and if I’m missing something obvious.

Wishing everyone good health,


Note, the forum won’t allow me to post links, so I changed HTTP to HFFP.

The 302 code in the Apache web server logs. It looks like there should be a corresponding 500 error, assuming your Apache server isn’t redirecting the traffic elsewhere.

1 Like

The only thing I see from apache is the initial post:

“POST /rt/REST/1.0/NoAuth/mail-gateway HFFP/1.1” 302 548 “-” “rt-mailgate/4.2.8 libwww-perl/6.08”

I’ve established that the Rest API is working using curl. I’ll try to step through mailgate manually to see where the problem is.

Resolved. GreenJimll was right, I needed to take a closer look at apache. After testing the REST APIs and finding everything was fine as far as RT was concerned I took a look at Apache. It turns out that LetsEncrypt installed a new cert on the same day I ticked over to 26000, and rt-mailgate is not happy with the new SSL ciphers.

Stay healthy everyone.