rt-crontool is not useable with users outside of user root (not recommended) and group www-data. The
documentation of RT-Crontool specifies:
---
This tool allows the user to run arbitrary perl modules from within RT. If this tool were setgid, a hostile
local user could use this tool to gain administrative access to RT. It is incredibly important that
nonprivileged users not be allowed to run this tool. It is suggested that you create a non-privileged unix user
with the correct group membership and RT access to run this tool (see User Configuration below).

[...]

rt-crontool should ideally be run by a special unprivileged operating system user who has also been entered in
RT as a privileged user with global [= ModifyTicket ] and [= ShowTicket ] rights. If you have created an
operating system user named rtcrontool, for instance, then create an RT user with Username and Unix login set to
rtcrontool, check Let this user be granted rights, and assign a password. Then under Configuration/Global/User
rights, add the two rights to the user you just created. This user should have read access to the RT files such
as RT_Config.pm and RT_SiteConfig.pm. If, for example, the rt group has read access to all the installed RT
files, you should assign your created user to that group (under UNIXen).

http://requesttracker.wikia.com/wiki/UseRtCrontool
---

It also seems, that runnint rt-crontool as root is inappropriate ("Somebody indicates that you can run the tool
as root (uid 0), but that didn't work properly for me when using rt-crontool to do priority escalation.").

In addition, simply using a unprivilged system account requires that account to be in the group www-data, which
is doable, but not necessarily nice as the RT_SiteConfig.pm file's permissions prevent access from other users:

severity 676322 wishlist
retitle 676322 Provide a general purpose 'rt' group for non-web utilities to run under
thanks

I think this pretty site dependent. The permissions of the config file
are under the system administrator's control, so you are free to
implement whatever you think is appropriate. There are also database
local user ACLs to think about (for SQLite and PostgreSQL ident auth,
at least).

That said, creating an 'rt' group and adding www-data to it for new
installs might not be a bad idea, but it's definitely low-priority for
me at the moment.

Retitling and downgrading, since the sysadmin is free to change the
permissions to suit site-specific requirements; no change in the
package is strictly required.

Thanks,
Dominic.

Dear submitter,

as the package request-tracker4 has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/1134418

The version of this package that was in Debian prior to this removal
can still be found using https://snapshot.debian.org/.

Please note that the changes have been done on the master archive and
will not propagate to any mirrors until the next dinstall run at the
earliest.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Thorsten Alteholz (the ftpmaster behind the curtain)