"namespace pollution" and $rtname

RT Users
1

Hi All,

Can anyone provide a real-world example of why domain name needs to be
used for $rtname? Google’s not coming up with much from the list
archives, and I’d rather use something cleaner like “Bug” or “Ticket”
for that string…

RT_Config.pm says “Your domain name is recommended, so as not to pollute
the namespace”, but the “namespace” we’re talking about here is only the
Subject line of those messages sent or from the RT mail interface. The
only case for which I can think of issues cropping up at all is if one
RT instance were to send mail directly to another RT instance, or if a
mail user were to forward a message from one RT instance to another
without changing the subject line; something which seems plausible but
remote. Has any of this ever actually happened in anyone’s experience,
with any ticketing system?

Or are there plans afoot anywhere to peer RT instances on purpose via
e-mail, such that namespace issues might later become important even if
they aren’t now?

Steve
Stephen G. Traugott (KG6HDQ)
UNIX/Linux Infrastructure Architect, TerraLuna LLC
stevegt@TerraLuna.Org
http://www.stevegt.com – http://Infrastructures.Org

2

RT_Config.pm says “Your domain name is recommended, so as not to pollute
the namespace”, but the “namespace” we’re talking about here is only the
Subject line of those messages sent or from the RT mail interface. The
only case for which I can think of issues cropping up at all is if one
RT instance were to send mail directly to another RT instance, or if a
mail user were to forward a message from one RT instance to another
without changing the subject line; something which seems plausible but
remote. Has any of this ever actually happened in anyone’s experience,
with any ticketing system?

Yes. We (CMU ECE Facilities) may forward tickets not about one of our
services to another group on campus which might use RT, or vice versa.
Likewise I saw what looked suspiciously like RT tickets get relayed
between Speakeasy and Covad when they set up my DSL. Popularity has
problems all its own. :slight_smile:

brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com
system administrator [WAY too many hats] allbery@ece.cmu.edu
electrical and computer engineering, carnegie mellon univ. KF8NH

3

Steve Traugott wrote:

Can anyone provide a real-world example of why domain name needs to be
used for $rtname? Google’s not coming up with much from the list
archives, and I’d rather use something cleaner like “Bug” or “Ticket”
for that string…

Just consider someone, a customer of yours maybe, forward a message
titled “Re: [Ticket #4712] not a bug” to your RT, which you confi-
gured with $rtname “Ticket”.
That message would be either incorporated in your RT’s ticket number
4712 or rejected because you’re not yet have 4712 tickets.
Either way, it’s not what should happen and your customer might be-
come rather confused if something like that actually would happen.

This might seem constructed at first sight, but this possibility quite
exists, at least with generics like “ticket”, “bug”, “request” … By
using your domain name, one could easily even have two RTs talk to
each other :wink:

mail user were to forward a message from one RT instance to another
without changing the subject line; something which seems plausible but
remote. Has any of this ever actually happened in anyone’s experience,
with any ticketing system?

I know of two ISPs unsig RT for at least some part of their communication.
Both do use their FQDN as their $rtname as well, so forwarding messages
from one ISP to the other does not break anything.

Or are there plans afoot anywhere to peer RT instances on purpose via
e-mail, such that namespace issues might later become important even if
they aren’t now?

Consider my example above, using generics like “Ticket”, you quite pos-
sibly might get in that kind of trouble. What’s wrong with “[TerraLuna.Org #1]”?
kai

Kai ‘wusel’ Siering eMail @ home: wusel@uu.org
Traveller on the Information Highway doing full-time administration.
The views expressed here are not neccessarily those of any employer.

Asterisk @ Home: FWD #476654 / +1-747-668-6567 / +49-2222-948-000847

4

Good answers, guys. You’ve got me convinced. :wink:

Thanks,

Steve
Stephen G. Traugott (KG6HDQ)
UNIX/Linux Infrastructure Architect, TerraLuna LLC
stevegt@TerraLuna.Org
http://www.stevegt.com – http://Infrastructures.Org