RT3 RC4 auto create of non-privileged users fails

RT Users
1

Hi. I’ve got RT3 RC4 running on FreeBSD 4.7 with Postgres 7.2, using
qmail as the MTA.

Everything works fine so far except that when a non-existent user sends
e-mail to the e-mail gateway, a message is generated to RTOwner with
subject “Could not load a valid user” that says “RT could not load a valid
user, and RT’s configuration does not allow for the creation of a new user
for your email.”

I’ve poured through the mailing lists, documentation, and source code, and
can’t seem to put together why this would be happening, so here I am.

Some relevant data points:

-RT writes a similar message out through syslog when the error occurs:

“RT could not load a valid user, and RT’s configuration does not allow for
the creation of a new user for your email.
(/home/rt/lib/RT/Interface/Email.pm:483)”

-I can successfully open a ticket if I send the e-mail from an address
that belongs to a known privileged user. So I know that e-mail ->
mailgate -> RT works in some capacity that results in database writes.

-The RT 3.0 draft manual mentions a config parameter
"$LookupSenderInExternalDatabase", but I can’t find it referenced anywhere
else. The other relevant documentation always implies that the
auto-creation of non-privileged users is turned on by default. I’ve tried
setting it to 1 and 0, no luck with either.

-The .qmail file that I’m using looks like this:

| /var/qmail/bin/preline /home/rt/bin/rt-mailgate --queue ‘tech support’ --action correspond

Any help will be much appreciated!

Thanks,
Chris

2

Hi. I’ve got RT3 RC4 running on FreeBSD 4.7 with Postgres 7.2, using
qmail as the MTA.

Everything works fine so far except that when a non-existent user sends
e-mail to the e-mail gateway, a message is generated to RTOwner with
subject “Could not load a valid user” that says “RT could not load a valid
user, and RT’s configuration does not allow for the creation of a new user
for your email.”

It turns out that assigning the privilege “Create Ticket” to the Global
System Group “Unprivileged” was all that needed to happen to fix this.
The documentation I reviewed implies that this is the default behavior
without any such action being needed, so I’m hoping my pain can benefit
anyone else who might fall into the same confusion.

Chris