User autocreation

We don’t think we dare enable auto-user creation due to spam issues.

But the usual flow is like this:

  1. User emails support@ourdomain with an issue.
  2. One of us creates an RT ticket, then replies, CCing RT, putting the [ourdomain #nnn] in the Subject.
  3. Occasionally a customer is well-behaved enough to do a REPLY ALL, but that fails to update RT because the user isn’t in RT.

Is there an easy way (presumably a scrip) to say “Any user that’s ever been on a TO or CC list gets auto-added as an unprivileged user”?

At Wednesday 5/3/2006 02:17 PM, Phil Smith III wrote:

We don’t think we dare enable auto-user creation due to spam issues.

But the usual flow is like this:

  1. User emails support@ourdomain with an issue.
  2. One of us creates an RT ticket, then replies, CCing RT, putting
    the [ourdomain #nnn] in the Subject.
  3. Occasionally a customer is well-behaved enough to do a REPLY ALL,
    but that fails to update RT because the user isn’t in RT.

Is there an easy way (presumably a scrip) to say “Any user that’s
ever been on a TO or CC list gets auto-added as an unprivileged user”?

I can’t think of one - this info is hidden away in transactions and
it would seem costly to trawl through all transactions each time a
reply came in.

The whole flow described seems prone to mistakes - for example, I’ll
guess people occasionally make typos when putting [ourdomain #nnn] in
the Subject. The issue of customers doing reply or reply all isn’t a
question of good behavior - why should the customer be expected to
know what your workflow is and that you need them to “reply all”?

A good spam filter and a more conventional use of RT might work out better -

Steve

Phil,

We’re really new to RT and encountered a different but similar problem
of email mapping. Though this probably won’t solve your problem, it
might give you a hint on where to go. What we wanted for inbound email
was the following logic:

  1. If the email is from an account in our domain (i.e. X@bu.edu), then
    set the requestor to X (i.e. elg instead of elg@bu.edu) and create the
    account if necessary.

  2. If the email comes from somewhere else but the email address is known
    to the system (i.e. someone updated their profile), set the requestor to
    that account.

  3. For all other mail, set the requestor to a fixed account. In our
    case, the account is called “external_user”.

We’re still checking to see if/how we could do this with a Scrip but, in
the mean time, we created our own mail authentication module to handle
the logic. We created a new file in "rt/lib/RT/Interface/Email/Auth"
called “BUMailFrom.pm” which is a copy of the MailFrom.pm authentication
file and added a line to RT_SiteConfig.pm with:

@RT::MailPlugins = ( "Auth::BUMailFrom" );

The differences between BUMailFrom.pm and MailFrom.pm are:

$ diff BUMailFrom.pm MailFrom.pm
46c46
< package RT::Interface::email::Auth::BUMailFrom;

package RT::Interface::email::Auth::MailFrom;
48a49,50

This is what the ordinary, non-enhanced gateway does at the moment.

60d61
<
63,76c64
< my $username;
<
< if ( $Address =~ m/.*@bu.edu$/i ) {
< $username = $Address;
< $username =~ s/@bu.edu$//;
< if ( $Name == $Address ) {
< $name = $username;
< }
< $CurrentUser->LoadByName($username);
< }
<
< unless ( $CurrentUser->Id ) {
< $CurrentUser->LoadByEmail($Address);
< }

$CurrentUser->LoadByEmail($Address);

82,87d69
< unless ( $CurrentUser->Id ) {
< if ( !( $Address =~ m/.*@bu.edu$/i )) {
< $CurrentUser->LoadByName(“external_user”);
< }
< }
<
90a73

97c80
< $RT::Logger->crit( “Auth::BUMailFrom couldn’t find the
’Unprivileged’ internal group” );

    $RT::Logger->crit( "Auth::MailFrom couldn't find the

‘Unprivileged’ internal group" );
104c87
< $RT::Logger->crit( “Auth::BUMailFrom couldn’t find the
’Everyone’ internal group”);

    $RT::Logger->crit( "Auth::MailFrom couldn't find the

‘Everyone’ internal group");
189,194c172
< if ( $Address =~ m/.*@bu.edu$/i ) {
< $CurrentUser = CreateUser( $username, $Address, $Name, $Address,
$args{‘Message’} );
< }
< else {
< $CurrentUser = CreateUser( undef, $Address, $Name, $Address,
$args{‘Message’} );
< }

$CurrentUser = CreateUser( undef, $Address, $Name, $Address,

$args{‘Message’} );

This seems to work in our testbed but, as we haven’t put the system into
production yet, I can’t yet tell you if there are any oddities.

Eric Gauthier
Network Engineer
617-353-8218 ~^~ elg@nsegc.bu.edu
Boston University - Office of IT-----Original Message-----
From: rt-users-bounces@lists.bestpractical.com
[mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Phil
Smith III
Sent: Wednesday, May 03, 2006 2:18 PM
To: rt-users@lists.bestpractical.com
Subject: [rt-users] User autocreation

We don’t think we dare enable auto-user creation due to spam issues.

But the usual flow is like this:

  1. User emails support@ourdomain with an issue.
  2. One of us creates an RT ticket, then replies, CCing RT, putting the
    [ourdomain #nnn] in the Subject.
  3. Occasionally a customer is well-behaved enough to do a REPLY ALL, but
    that fails to update RT because the user isn’t in RT.

Is there an easy way (presumably a scrip) to say “Any user that’s ever
been on a TO or CC list gets auto-added as an unprivileged user”?

http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com Commercial support:
sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

We’re hiring! Come hack Perl for Best Practical:

Well…ok. I’m not clear on a few things:

  • How do typos in the Subject: affect this? Typos mean extra tickets if it doesn’t recognize the “magic string”; what else will they affect?

  • I was being semi-facetious about “well-behaved”, but your point is well taken. I guess I could just remember to forward every note they send me back to RT, but that’s also error-prone.

  • What do you mean by “a more conventional use of RT”?

…phsiiiFrom: Stephen Turner [mailto:sturner@MIT.EDU]
Sent: Wednesday, May 03, 2006 2:57 PM
To: Phil Smith III; rt-users@lists.bestpractical.com
Subject: Re: [rt-users] User autocreation

At Wednesday 5/3/2006 02:17 PM, Phil Smith III wrote:

We don’t think we dare enable auto-user creation due to spam issues.

But the usual flow is like this:

  1. User emails support@ourdomain with an issue.
  2. One of us creates an RT ticket, then replies, CCing RT, putting
    the [ourdomain #nnn] in the Subject.
  3. Occasionally a customer is well-behaved enough to do a REPLY ALL,
    but that fails to update RT because the user isn’t in RT.

Is there an easy way (presumably a scrip) to say “Any user that’s
ever been on a TO or CC list gets auto-added as an unprivileged user”?

I can’t think of one - this info is hidden away in transactions and
it would seem costly to trawl through all transactions each time a
reply came in.

The whole flow described seems prone to mistakes - for example, I’ll
guess people occasionally make typos when putting [ourdomain #nnn] in
the Subject. The issue of customers doing reply or reply all isn’t a
question of good behavior - why should the customer be expected to
know what your workflow is and that you need them to “reply all”?

A good spam filter and a more conventional use of RT might work out better -

Steve

At Wednesday 5/3/2006 03:44 PM, Phil Smith III wrote:

Well…ok. I’m not clear on a few things:

  • How do typos in the Subject: affect this? Typos mean extra
    tickets if it doesn’t recognize the “magic string”; what else will they affect?

I just meant what you describe - typos will mean that replies don’t
get appended to the correct ticket, they will generate new tickets.

  • I was being semi-facetious about “well-behaved”, but your point is
    well taken. I guess I could just remember to forward every note
    they send me back to RT, but that’s also error-prone.

  • What do you mean by “a more conventional use of RT”?

Hello Phil,

I was thinking that the support@ourdomain address would be a feed
into RT and that autocreation would be turned on (assuming you solve
the spam problem outside of RT). The scrips would take care of
notifying your staff and directing mail to the customer. Then, any
reply would automatically come back to RT and be added to the right ticket.

It sounds like you’re using your email list as the primary means of
communication, and that RT is just a back-end archive. Trouble is,
it’s impossible to ensure that all the email correspondence gets into
RT attached to the right ticket. I’m even wondering if using RT is
overkill in this situation - perhaps an archive of mail sent to your
email list would work as well?

Steve

I agree with Stephen, but if you’re going to use current scheme then:

  • you staff should fill requestor field with customer’s email and RT
    would autocreate user
  • look into ParseTicketForCc option in the config, but I don’t
    remember if it works replis/comments
  • this discussion a bit of off-topic for rt-devel@On 5/3/06, Phil Smith III lists@akphs.com wrote:

We don’t think we dare enable auto-user creation due to spam issues.

But the usual flow is like this:

  1. User emails support@ourdomain with an issue.
  2. One of us creates an RT ticket, then replies, CCing RT, putting the [ourdomain #nnn] in the Subject.
  3. Occasionally a customer is well-behaved enough to do a REPLY ALL, but that fails to update RT because the user isn’t in RT.

Is there an easy way (presumably a scrip) to say “Any user that’s ever been on a TO or CC list gets auto-added as an unprivileged user”?


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

We’re hiring! Come hack Perl for Best Practical: http://bestpractical.com/about/jobs.html

Best regards, Ruslan.

Thanks. Re your list point: that’s why I posted it on rt-users ;-)-----Original Message-----
From: Ruslan Zakirov [mailto:ruslan.zakirov@gmail.com]
Sent: Wednesday, May 03, 2006 5:07 PM
To: Phil Smith III
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] User autocreation

I agree with Stephen, but if you’re going to use current scheme then:

  • you staff should fill requestor field with customer’s email and RT
    would autocreate user
  • look into ParseTicketForCc option in the config, but I don’t
    remember if it works replis/comments
  • this discussion a bit of off-topic for rt-devel@