[rt-users] Again: RT using reply-to field to authenticate sender email

[Kevin Falcone]

On Fri, Nov 11, 2011 at 05:32:26PM +0100, Lars Reimann wrote:
> Queue address: service-abc at example.org
> Sender address: sender at example.com (known to RT, privileged, can
> create tickets, etc)
> Third party address: recipient at example.net
> 
> Sending an email with Cc to Queue address and have Reply-to Header set
> 
> To: recipient at example.net
> Cc: service-abc at example.org
> Reply-to: recipient at example.net
> 
> yields "Could not load a valid user" for recipient at example.net
> 
> I think this may be a bug, because the original sender address is
> not used to auth against RT.

RT explicitly tries to make the Requestor of the ticket be the
Reply-To of an email.  It's been this way for many years and I don't
see it changing anytime soon.

I actually use this all the time to log tickets that show Created by
Me but set someone else as the Requestor since I'm logging the ticket
for them.

You need to configure your permissions to allow for the creation of
recipient at example.net or do a clean overlay of RT to prefer From over
Reply-To in the ParseSenderAddressFromHead method.

-kevin

> I don't know how reply addresses are normally handled via RT, but
> auth'ing a user via the Reply-to header field is wrong because it is
> almost every time different from the "From" field and to Reply-to
> address may have no rights in RT in most cases.
> 
> Imagine the following workflow:
> recipient at example.net is a list, I want to inform it of something
> while creating a ticket using the Cc field.
> In this case I am the requestor, emails should go to me and the
> Reply-to address could be set as CC or whatever.
> Giving the Reply-to address access to RT is impractical because it
> is a list address only.
> 
> Can anybody confirm or has a solution to this? Maybe there is a
> quick code-fix ;)
> 
> greetings,
> l.r.
> --------
> RT Training Sessions (http://bestpractical.com/services/training.html)
> *  Barcelona, Spain  November 28 & 29, 2011
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20111114/7d1f5ff4/attachment.sig>