[rt-users] Avoiding backscatter & enabling self help

Kevin Falcone falcone at bestpractical.com
Mon Apr 4 09:45:45 EDT 2011


On Fri, Apr 01, 2011 at 07:06:19PM -0700, Kurt Zeilenga wrote:
> We've been experimenting with RT this week at OpenLDAP.org for servicing various "help" and "contact" by email services... info at opendlap.org, webmaster at 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

> 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
> 
-------------- 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/20110404/5b1cacf9/attachment.sig>


More information about the rt-users mailing list