RT-Mailgate timeout error after upgrade to 4.2.6

We are fighting an issue after updating RT from 4.2.3 to 4.2.6 and rt-mailgate. We also updated our OS to Ubuntu 14.04. Everything seems to be working in RT except rt-mailgate. I’ve isolated it to an LWP::Protocol::https::Socket: Timeout error returned from the post to the RESTful service: my $r = $ua->post( $full_url, $post_params, Content_Type => ‘form-data’ );

I increased the timeout from 180 to 750 added extra debugging to the code to get more information. I replaced our URL with localhost for security:

/opt/rt4/bin/rt-mailgate: connecting to https://localhost/REST/1.0/NoAuth/mail-gateway
ua->timeout: 750
ua->post full_url: https://localhost/REST/1.0/NoAuth/mail-gateway
ua->post post_params: HASH(0x149a6d0)
r->content : Can’t connect to localhost:443

LWP::Protocol::https::Socket: Timeout at /usr/share/perl5/LWP/Protocol/http.pm line 41.

HTTP request failed: 500 Can’t connect to localhost:443. Your webserver logs may have more information or there may be a network problem.

/opt/rt4/bin/rt-mailgate: undefined server error
fetchmail: MDA returned nonzero status 75
not flushed

There are no log entries in the apache error.log. We have Set($LogToFile , ‘debug’); and did see one error that we corrected (a missing $RTAddressRegexp configuration). There are no other errors in the rt.log file. I don’t even see an entry in the access.log. Fiddler gives us the same error (504 - Gateway Timeout Error). If I execute consecutive posts very quickly in Fiddler, after about seven 504 errors, I finally get a string of 200 (success) responses and some entries in the rt.log file to indicate it couldn’t find a valid user (because I didn’t supply one). If I let it set for a minute, I get the 504 errors again.

Thank you for any help,

Matthew E. Richards

I increased the timeout from 180 to 750 added extra debugging to the code to
get more information. I replaced our URL with localhost for security:

Are you actually listening with SSL on localhost? Is your webserver
configured to listen and allow that through to RT?

see an entry in the access.log. Fiddler gives us the same error (504 - Gateway
Timeout Error). If I execute consecutive posts very quickly in Fiddler, after
about seven 504 errors, I finally get a string of 200 (success) responses and
some entries in the rt.log file to indicate it couldn’t find a valid user
(because I didn’t supply one). If I let it set for a minute, I get the 504
errors again.

Is fiddler running on the machine connecting to localhost or somewhere
else? It’s a much more relevant test to use something like curl to
connect to localhost with the same arguments as rt-mailgate.

rt-mailgate isn’t doing anything complicated, and if RT isn’t logging
anything in debug mode, then normally this means your webserver is
bound only to the external hostname.

-kevin

Hi Kevin,

Thank you for the reply.

Are you actually listening with SSL on localhost? Is your webserver
configured to listen and allow that through to RT?

443 is listening on localhost. As you suggested, we tried curl from the localhost with both the FQDN and localhost URLs. We had limited success (without any message content), but it still fails with rt-mailgate. I suspect we need some content to test it further with curl. Do you have a sample curl command line with post params for testing?

user@rt:~$ curl -I https://rt.fully.qualified.domain.name/REST/1.0/NoAuth/mail-gateway
HTTP/1.1 200 OK
Server: Apache/2.4.7 (Ubuntu)
X-Frame-Options: DENY
Vary: Accept-Encoding
Content-Type: text/plain; charset=utf-8

user@rt:~$ curl -I https://localhost/REST/1.0/NoAuth/mail-gateway
HTTP/1.1 200 OK
Server: Apache/2.4.7 (Ubuntu)
X-Frame-Options: DENY
Vary: Accept-Encoding
Content-Type: text/plain; charset=utf-8

Running rt-mailgate with fetchmail:

2 messages for RTUSER at hostmaster.fully.qualified.domain.name (36925 octets).
fetchmail: POP3> LIST 1
fetchmail: POP3< +OK 1 34826
fetchmail: POP3> TOP 1 99999999
fetchmail: POP3< +OK
reading message RTUSER@hostmaster.fully.qualified.domain.name:1 of 2 (34826 octets) #.***.........**************........**************........**************.......**************....*****.*****/opt/rt4/bin/rt-mailgate: temp file is ‘/tmp/63WuokOupY/OIpKtEaLCc’
/opt/rt4/bin/rt-mailgate: connecting to https://rt.fully.qualified.domain.name /REST/1.0/NoAuth/mail-gateway
HTTP request failed: 500 Can’t connect to rt.fully.qualified.domain.name:443. Your webserver logs may have more information or there may be a network problem.

/opt/rt4/bin/rt-mailgate: undefined server error
fetchmail: MDA returned nonzero status 75
not flushed
fetchmail: POP3> LIST 2
fetchmail: POP3< +OK 2 2099
fetchmail: POP3> TOP 2 99999999
fetchmail: POP3< +OK

Again, when we added some additional debugging messages and the actual error is:
LWP::Protocol::https::Socket: Timeout at /usr/share/perl5/LWP/Protocol/http.pm line 41.

443 is listening on localhost. As you suggested, we tried curl from
the localhost with both the FQDN and localhost URLs. We had limited
success (without any message content), but it still fails with rt-
mailgate. I suspect we need some content to test it further with curl.
Do you have a sample curl command line with post params for testing?

Just run rt-mailgate by hand, handing it a correctly formatted
message and the --debug setting. If it works sporadically, you have some
serious problem with your webserver config.

If you’re going to the localhost, I’m not actually sure why you’re
involving SSL, but that’s a separate issue.

-kevin

If you’re going to the localhost, I’m not actually sure why you’re
involving SSL, but that’s a separate issue.

Actually, that was the issue. You’re right, there’s no need to use SSL with localhost. We have a rewrite from 80 to 443 for all interfaces and it always forces us to use https. I guess we could have created a non-SSL site just for localhost. The DoD has its own root CA that we added in a ca_file, but I think it’s very slow and was causing the timeouts. I changed the rt-mailgate get_useragent to “$ua->ssl_opts(SSL_verify_mode => ‘SSL_VERIFY_NONE’);” and that solved the issue. It’s a temporary fix until we create a locahost:80 binding. I don’t like maintaining custom source. Thanks for all the help.

Matt

If you’re going to the localhost, I’m not actually sure why you’re
involving SSL, but that’s a separate issue.

Actually, that was the issue. You’re right, there’s no need to use SSL
with localhost. We have a rewrite from 80 to 443 for all interfaces
and it always forces us to use https. I guess we could have created a
non-SSL site just for localhost. The DoD has its own root CA that we
added in a ca_file, but I think it’s very slow and was causing the
timeouts. I changed the rt-mailgate get_useragent to "$ua-

ssl_opts(SSL_verify_mode => ‘SSL_VERIFY_NONE’);" and that solved the
issue. It’s a temporary fix until we create a locahost:80 binding. I
don’t like maintaining custom source. Thanks for all the help.

If you don’t want to verify, why not just use the flag?

$ ./bin/rt-mailgate --help | grep verify
“–ca-file” or “–no-verify-ssl”, below.
authority that should be used to verify the website’s SSL certificate.
preferentially use this option over “–no-verify-ssl”, as it will
“–no-verify-ssl”

-kevin