Thanks for you comments, they got me thinking a deeper into our problem.
We’ve been experimenting with RT this week at OpenLDAP.org for servicing various “help” and “contact” by email services… info@opendlap.org, webmaster@openldap.org, etc. We have a general policy here at OpenLDAP.org to avoid email auto-responders, so as not to contribute to the backscatter problem. But we also like “self help” services.
We presently have the ‘On Create Autoreply To Requestors’ scrip disabled.
I see there is a suggestion in the Wiki article http://requesttracker.wikia.com/wiki/AutogeneratedPassword for generating passwords on first create (from email) from the user, and including this in the autoreply on create message. I’m wondering if I might apply this patch to the response ticket so that on response to a user without a password will cause a password to be generated. That would provide some “self help” opportunities to the user. Any thoughts on how best to do this?
For all other possible emails to the requestor, never send if the password hasn’t ever been set. Any thoughts on how to accomplish this?
Without even reading the Wiki, what I recall off the top of my head is that you need to replace the default Autoreply Template with the one from the Wiki. After that, you need to enable the scrip you disabled. This will have your desired action.
Unfortunately that’s not an option for us as it would cause us to generate backscatter.
I note that preventing backscatter, especially backscatter to those we have no relationship with, is more importance to us than enabling self help.
Again, what we want is to never send an email to a requestor without a human generating a correspondence to that requestor (and hence setting up their password). Until then, we want to assume the email had a forged from address. Am I on the right track above? or is there a better way to setup RT to behave in this manner?
In that case, I believe you want full human intervention on creating users and assigning them passwords. In that case, there is no need for using a scrip. That is not the way I know RT to work.
The problem here is the number of steps. We really don’t want to have the owner doing anything more than they normally would do, just respond to the ticket they just took.
“Until then, we want to assume the email had a forged from address” - makes me wonder how the human will verify that the e-mail address is legit.
Well, the human is not really checking the email address but the ticket as a whole. If the ticket doesn’t look legit, then it our assumption that the requestor is not legit for this ticket. We expect our ticket handlers to use the ‘Report Spam’ extension to mark it as Spam.
Now if the ticket is legit, we then respond to it.
I was initially think not to send any automated mail to a requestor without a password until a human has manually responded. But now I’m thinking it would be even better to generally not send any automated mail to requestor/CCs until a human a human has manually responded.
This could be implemented, I’m thinking, using flag on the ticket, which would be false until responded to by a human, to enable/disable automated email to the requestor/CCs.
I think what you need is a “customized registration” page somewhere, which uses captcha, submits the details to a custom script that then injects the details into RT and generates a response to the registrant with their password, and details on how to track their request via your RT.
We’re using RT to handle events we expect to be initiated via email. We have no expectation that the requestor would attempt to look at the website before submitting their initial email. The first email they’ll get from us will be the manually generated ticket in response to their initial email. Our initial correspondence seems like the appropriate place to include any web access information, including providing any necessary credentials.