Avoiding backscatter & enabling self help

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?

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?

FYI, I’m using RT 3.8.9 on FreeBSD 7-stable.

– Kurt

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.

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. “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. Perhaps you need some custom
condition that will send out a mail to the address, with a url with captcha,
let the recipient follow the captcha… scratch that. 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.

Best regards,
Odhiambo WASHINGTON,
Nairobi,KE
+254733744121/+254722743223


Damn!!

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.

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?

You could squelch requestors unless they have a password set and then
adapt the autoreply scrip to set passwords and unsquelch users. That
would also avoid your later question about never contacting a user
until they have a password, since they’d be squelched.

Keep in mind that if someone has set 3 people as requestors on a
ticket (by merging tickets from 3 people) before replying, a simple
"Notify Requestors" action would notify them using the same email.
So you’d want a separate notification for when the password gets set.

This sounds very doable, but I’m not aware of existing code that you
can just adapt into place.

-kevin