Behaviour of RTAddressRegexp

Dear RT hackers,

why don’t we add automatically queues correspond/comment address to the
RTAddressRegexp check to avoid users to maintain a huge regexp for
sometimes hundreds of queues/emails?

IMHO, RTAddressRegexp should only be needed to add aliases that has an
RT queue as target.

Dear RT hackers,

why don’t we add automatically queues correspond/comment address to the
RTAddressRegexp check to avoid users to maintain a huge regexp for
sometimes hundreds of queues/emails?

IMHO, RTAddressRegexp should only be needed to add aliases that has an
RT queue as target.

I’m with you. I recall Kevin/Ruslan having pointed out some important nuances here. There may even be existing work on a branch to improve things.

-jesse

Dear RT hackers,

why don’t we add automatically queues correspond/comment address to the
RTAddressRegexp check to avoid users to maintain a huge regexp for
sometimes hundreds of queues/emails?

IMHO, RTAddressRegexp should only be needed to add aliases that has an
RT queue as target.

I’m with you. I recall Kevin/Ruslan having pointed out some important nuances here. There may even be existing work on a branch to improve things.

I’m not with you. In trunk we do our best:

  1. if option is not set we lookup in DB
  2. we still allow regexp
  3. we warn admin via logs if regexp is not defined

It’s flexible enough to protect careless admins and allow smart to
setup fast matching and cover addresses not stored in the DB.

I saw setups

  • where not all RT addresses are in the DB
  • with many queues, but very small and fast regexp

My idea is that usually hundreds emails turns into short regular
expression. If it’s not the case for you then you can use “no value”
and DB lookups.

-jesse


List info: The rt-devel Archives

Best regards, Ruslan.

In most environments I have been, the RT system is not the primary mail
server of course, so you end up with various aliases and forwarding making
your rt environment look like a cohesive part of the email domain. Using a
regex with appropriate wild cards makes this work well.

Cheers,
Brian

On Fri, May 21, 20…
I’m not with you. In trunk we do our best:

  1. if option is not set we lookup in DB
  2. we still allow regexp
  3. we warn admin via logs if regexp is not defined

It’s flexible enough to protect careless admins and allow smart to
setup fast matching and cover addresses not stored in the DB.

I saw setups

  • where not all RT addresses are in the DB
  • with many queues, but very small and fast regexp

My idea is that usually hundreds emails turns into short regular
expression. If it’s not the case for you then you can use “no value”
and DB lookups.

-jesse


List info: http://lists.bestpractical
Best regards, Ruslan.

List info: http://lists.bestpractical.com/cgi-bin/ma

I’m not with you. In trunk we do our best:

  1. if option is not set we lookup in DB

but couldn’t we check in DB even if it’s defined? I don’t think that
it’s a performance problem, even for setups with hundreds of queues.

  1. we still allow regexp

of course, it’s needed.

  1. we warn admin via logs if regexp is not defined

and via the UI in queue modify page.

My idea is that usually hundreds emails turns into short regular
expression. If it’s not the case for you then you can use “no value”
and DB lookups.

here I have setups with lot of queues with proper emails in database,
but a few external aliases to check.

imho, the best could be to check DB if RTAddressRegex returns undef (or
add one more option to configure this).