I’ve been going around in circles with this - but it is probably
something quite simple.
I am unable to create requests using the mail interface, unless I
configure the queue to accept create requests from non-members.
The users appear to be members of the queue, so I am not sure
what is wrong.
example reply from rt: ---------------------------------
I’ve been going around in circles with this - but it is probably
something quite simple.
I am unable to create requests using the mail interface, unless I
configure the queue to accept create requests from non-members.
The users appear to be members of the queue, so I am not sure
what is wrong.
I don’t know what rules rt uses to determine if an email source equates
to a particular queue member. But, toward that positive recognition,
you might try:
making sure you’re sending email from the same address as what you’ve
told rt belongs to the queue member in question;
making sure your email client doesn’t pervert your source address on
emails it sends (so that it’s not what you think it is).
example reply from rt: ---------------------------------
Pretty simple: RT’s mail gateway does not trust your email return address
as proof that you are who you say you are. Your choices are to
allow non-members to create requests, look at the %rt user and %rt pass
commands for the mail gateway (I don’t remember if they’ll actually work for
this) or use a different create mechanism.
-jOn Wed, Aug 09, 2000 at 04:13:42PM +1000, Jim Clark wrote:
I’ve been going around in circles with this - but it is probably
something quite simple.
I am unable to create requests using the mail interface, unless I
configure the queue to accept create requests from non-members.
The users appear to be members of the queue, so I am not sure
what is wrong.
example reply from rt: ---------------------------------
jesse reed vincent — root@eruditorum.org — jesse@fsck.com
pgp keyprint: 50 41 9C 03 D0 BC BC C8 2C B9 77 26 6F E1 EB 91
I admit that X is the second worst windowing system in the world, but all the
others I’ve used are tied for first.
Pretty simple: RT’s mail gateway does not trust your email return address
as proof that you are who you say you are. Your choices are to
allow non-members to create requests, look at the %rt user and %rt pass
commands for the mail gateway (I don’t remember if they’ll actually work for
this) or use a different create mechanism.
Thanks Jesse. I had tried the %rt user/%rt pass commands, but without success.
I did not really wish to open up the system with the ‘allow non-members to
create’
option, but found the relevant piece of perl and made a small change to map the
email address to a user_id for subsequent authentication. I feel this is a
better
compromise than providing indiscriminate create privilege.
If anyone else is interested in doing this, I can provide a patch.
