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:
-
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.
-
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.
-
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:
:Auth::BUMailFrom;
package RT::Interface::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:
- User emails support@ourdomain with an issue.
- One of us creates an RT ticket, then replies, CCing RT, putting the
[ourdomain #nnn] in the Subject.
- 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: