"No permission to create tickets in the queue 'Orders'" - RT then drops the message

When two messages with the same sender, a new non-privileged user in RT,
come in at the same time, only one makes it into the queue, while the other
just gets dropped.

We handle customer orders and always get two messages per order: one for the
order itself, the other for the payment (from the gateway, PayPal, etc).
Both of the messages come with the same sender e-mail address, the
customer’s. The messages are collected in a remote account until Fetchmail
retrieves them and distributes them locally.

The problem seems to occur when Fetchmail hands Postfix the two messages.
Because Postfix is so fast, it hands both messages to rt-mailgate almost
simultaneously. When the sender is the same for both messages, and the
sender is a new user (from RT’s perspective), only one of the two messages
makes it into the Orders queue. The other just disappears. In the log, we
get this:

Mar 13 16:26:17 RTSRV RT: No permission to create tickets in the queue
’Orders’ (/opt/rt3/lib/RT/Interface/Email.pm:678)
Mar 13 16:26:17 RTSRV RT: Create failed: 0 / 0 / No permission to create
tickets in the queue ‘Orders’ (/opt/rt3/lib/RT/Interface/Email.pm:684)

The queue is setup correctly, with Everyone having ticket creation
privileges. And it works fine most of the time. But every once in a while,
this problem occurs.

Here are the basic facts:

RT 3.0.8
Perl 5.8.0
Apache 1.3.29
MySQL 3.23.58 (InnoDB)

I know I’m supposed to upgrade and I’m working on that. But is this problem
really related to 3.0.8 running on MySQL 3.23.58?

Thanks!

Chago

When two messages with the same sender, a new
non-privileged user in RT,
come in at the same time, only one makes it into the queue,
while the other
just gets dropped.

I’m having a similar problem in 1 queue, except the second message doesn’t
make it in either. If that sender opens a ticket in another queue, then
they’re ok.

The problem seems to occur when Fetchmail hands Postfix the
two messages.

We don’t use Fetchmail. We have Postfix running as a daemon taking email
directed from aliases on our main mail host.

Mar 13 16:26:17 RTSRV RT: No permission to create tickets in the queue
’Orders’ (/opt/rt3/lib/RT/Interface/Email.pm:678)
Mar 13 16:26:17 RTSRV RT: Create failed: 0 / 0 / No
permission to create
tickets in the queue ‘Orders’
(/opt/rt3/lib/RT/Interface/Email.pm:684)

Mine looks very similar, with path changes and such of course.

The queue is setup correctly, with Everyone having ticket creation

I thought so on mine too. All my queues use the “global” permissions and
they all work right. I specifically added everyone/create to this queue and
it helped, but didn’t solve (now its intermittant).

Here are the basic facts:

RT 3.0.8

We’re still on 3.0.7.

Perl 5.8.0
Apache 1.3.29
MySQL 3.23.58 (InnoDB)

We’re on 4.0-something, so I don’t think this is a mysql thing.

Here is other thing about my setup and queue… We added a custom
auto-response template. We’ve done similar to other queues and they work,
but maybe something about this template causes this?

Anyone? Anyone?

Brnet

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I guess a ‘me too’ might be in order here, since there do seem to be a few of
us that have this problem. I think you hit the nail on the head; I just had
this problem yesterday and it was when two spam mails came in from the same
requestor at the same time; one of them got the ‘no permission to create
tickets…’ error.

Our setup is:
RT 3.0.9
Perl 5.8.3
Apache 1.3.29 + mod_perl 1.29
MySQL 4.0.17

I noticed RT 3.0.10 had this in it’s changelog:

Core
Better emailing of error messages after “permission denied” errors

Does anybody have any clairification on what this does? Might it help us in
this situation?

  • -Doug

Douglas E. Warner dwarner@ctinetworks.com Network Engineer
CTI/PAdotNET http://ctinetworks.com +1 717 975 9000
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAat+ZJV36su0A0xIRAnLVAJ4lzLOoubqYy33HCwb7e9zzV2wG/wCcD1C5
Iu1eY+eheqmPK8iy9xWs8vg=
=iTIx
-----END PGP SIGNATURE-----