It's really a safeguard, because not everyone that uses your RT instance is "smart" enough to prevent loops from happening.
And my example showed 2 queues... but you only need email address and a "goofy" user for a loop to happen that will cripple the system. I've had end-users reply to an email coming from <Mike Johnson via RT>(which the Reply-To: on those emails is [email protected]) and cc [email protected]. If you use the ParseNewMessageForTicketCcs, the above can become quite troublesome without RTAddressRegexp, as it would append [email protected] as a Cc email address, which would then email out to [email protected] whenever you do correspondence that a Cc would see... Hope that helps! Mike. On Tue, Jul 27, 2010 at 4:29 PM, Joseph Spenner <[email protected]>wrote: > > > --- On *Tue, 7/27/10, Mike Johnson <[email protected]>* wrote: > > > You need to include both, the queue email addresses, AND anything that > forwards email to RT. > > That setting prevents RT from sending emails that will "loop" infinitely in > your system. > > For example. > > RT is setup with the basic autoreply, and reply on correspondence etc. > > RT has 2 queues, [email protected] <http://mc/[email protected]>goes > to general, and > [email protected] <http://mc/[email protected]> goes to IT queue. > > If [email protected] <http://mc/[email protected]> emails > [email protected]<http://mc/[email protected]>the general queue will > autoreply to > [email protected] <http://mc/[email protected]> which will create a ticket > and autoreply to [email protected] > <http://mc/[email protected]>which will create a ticket and > auto-reply to > [email protected] <http://mc/[email protected]> etc etc etc.... > > Big loop, never ending, blow up RT :P > > If you set the regular expression to > [email protected]<http://mc/[email protected]>when RT emails out, > it'll filter any emails going to > [email protected] <http://mc/[email protected]>. This will > ensure no loop happens. > > SO to recap, RTAddressRegexp has to be a regular expression that ALL email > addresses that send stuff to RT will validate through. > > Hope this helps! > Mike. > > On Tue, Jul 27, 2010 at 1:35 PM, Joseph Spenner > <[email protected]<http://mc/[email protected]> > > wrote: > > Upon nearly completing my RT installation, and running: > > # make initialize-database > > I got the message: > > == > [Tue Jul 27 17:12:29 2010] [error]: The RTAddressRegexp option is not set > in the config. Not setting this option results in additional SQL queries to > check whether each address belongs to RT or not. It is especially important > to set this option if RT recieves emails on addresses that are not in the > database or config. (/home/packages/rt-3.8.8/sbin/../lib/RT/Config.pm:343) > Now inserting data > Done inserting data > Done. > == > If I have 3 queues, ie: > [email protected]<http://mc/[email protected]> > [email protected] <http://mc/[email protected]> > [email protected]<http://mc/[email protected]> > Do I need to list all those addresses (and any future addresses) in that > RTAddressRegexp option ? Or is this only if I have something at (ie:) > [email protected] > <http://mc/[email protected]>forwarding to my RT system in > which case I'd want to add: > [email protected] <http://mc/[email protected]> to > the RTAddressRegexp option ? > > > > So this 'loop' should only occur if: > > 1) auto respond/reply is enabled for the queue defined in the scrips > 2) somehow, an RT queue address (with auto reply enabled) somehow gets > included into another queues ticket > > ? > > Is this potential something new? I've been using RT2 since about 2001 and > never seen this happen. Or is it just a safeguard? > > > > > Discover RT's hidden secrets with RT Essentials from O'Reilly Media. > Buy a copy at http://rtbook.bestpractical.com > -- Mike Johnson Datatel Programmer/Analyst Northern Ontario School of Medicine 955 Oliver Road Thunder Bay, ON P7B 5E1 Phone: (807) 766-7331 Email: [email protected]
Discover RT's hidden secrets with RT Essentials from O'Reilly Media. Buy a copy at http://rtbook.bestpractical.com
