Re: [rt-users] attachment scanner

[Ruslan Zakirov]

Hi,

Do that out of RT. If you want to scan uploaded attachments then there
is no solution I know about.

On Fri, Oct 22, 2010 at 6:11 PM, Roedel, Mark  wrote:
> Has anybody done any scripting to scan attachments for viruses or check for
> sensitive data like SSN’s before aceepting them onto a ticket?
>
>
>
>
>
> Mark Roedel
>
> Webmaster
>
> Enrollment Services
>
> LeTourneau University
>
> 903-233-3535 (w) | 903-233-3105 (f)
>
> www.letu.edu | www.facebook.com/myletu | www.twitter.com/LETUadmissions
>
>
>
>



-- 
Best regards, Ruslan.

Re: [rt-users] Some RTIR automation?

[Ruslan Zakirov]

Hi,

It's totally doable with scrips. RTIR itself has a lot of examples
with bits you need. Basicly you need:

When IR is created with and IP is set or when IP is changed from no
value to a value, link to existing incident or create a new one. First
part is a condition and second part is an action.

For example lib/RT/Condition/RTIR_BlockActivation.pm is quite close.
Checks whether ticket is created with active state or state is changed
to active.

Action is not that straightforward, but try it and if you have
problems return back to us with detailed questions.

On Fri, Oct 22, 2010 at 9:19 PM, Landon Stewart  wrote:
> Many times a day I will login to RT+RTIR and consolidate Incident Reports
> into Incidents using the IP address field in RTIR.  Is there any way to
> automate the consolidation process of Incident Reports into Incidents where
> there's an IP address?  I would imagine it's possible but I'm not sure what
> to try even.
>
> For those who may not have seen it - RTIR is an addon for RT.  It creates
> three queues called Incident Reports, Incidents and Investigations.
> Incident Reports can be merged or multiple Incident Reports can be linked to
> a single Incident.  An Incident can be used to create a new ticket called an
> Investigation.  In our case we use this to consolidate abuse issues reported
> by outside parties by linking individual Incident Reports into Incidents and
> then opening an investigation with our customer.  After our customer replies
> to the Investigation and we can then respond to all the Incident Reports
> separately and all at once when the Incident is resolved.
>
> I had thought, maybe using code in a template, to script the creation of an
> Incident if no other open Incident exists with the IP address(es) from the
> Incident Reports.  If an Incident exists with that IP address and it's open
> it links the new incident report with that incident.  Can a script inside a
> template create an Incident?
>
> Then at regular times I can simply list the incidents and open
> investigations where needed and look for incident reports with no IP address
> in them (rare).
>
> Does anyone have any ideas on how to go about this?
>
> Thanks to anyone who has any ideas on where to start here.
>
> --
> Landon Stewart 
> SuperbHosting.Net by Superb Internet Corp.
> Toll Free (US/Canada): 888-354-6128 x 4199
> Direct: 206-438-5879
> Web hosting and more "Ahead of the Rest": http://www.superbhosting.net
>



-- 
Best regards, Ruslan.

Re: [rt-users] Templates and custom ScripActions

[Ruslan Zakirov]

Hello,

Template is a piece of text that can be used from your action code.
Look at SendMail.pm and ExtractCustomFieldValues extension. Both use
templates and in completly different way.

If you want to send some email from your action then probably the
right way is to record a comment or reply on the ticket from action
and let notification scrips do thier job.

On Fri, Oct 22, 2010 at 7:15 PM, Francis L Fabrizio  wrote:
> Do I have to do something specific when creating a Scrip and using Action: 
> User Defined in order to get RT to process the associated template with the 
> scrip?
>
> I have created a custom scrip, and just for testing purposes, I made the 
> custom condition, custom action prep, and custom action cleanup all set to 
> "return 1;", and associated my desired template with the scrip.  The scrip 
> fires and returns successfully, but the template is never touched.
>
> Are there specific steps I need to take in my custom action code in order to 
> load, parse, and send notifications from a template?
>
> Thanks,
> Fran

-- 
Best regards, Ruslan.

Re: [rt-users] General permissions question

[Ruslan Zakirov]

On Fri, Oct 22, 2010 at 5:34 PM, Josh Narins wrote:

>  I have three classes of users, I'm wondering if my privileges/groups
> setup is what RT intends.
>
>
>
> Class 1: Administrators. These three people can do anything.
>
>
Put them in the group.


> Class 2: People who log into RT and own and resolve tickets. Each is only
> going to be working with 1-3 queues out of 10-15 queues total.
>

Not sure how you split things into queues, but if you can organize some
groups that union people that work on particular set of groups then go for
it.

Using groups makes it easier to re-assign people or promote them. A user can
be in several groups and inherit rights from all of them.

Use roles for as much as possible. Usually granting rights via roles even on
global level helps you avoid granting them directly to groups.


> Class 3: People who create tickets via email and don't need to do anything
> but reply via email.
>
>
>
> Right now I'm thinking class 1 and class 2 should be "privileged" users,
> and by AdminCCs on the particular queues they are interested in. In
> addition, the three superusers will have, as a User Right, the "Super User"
> privilege.
>

Anyway use subgroups. If you grand to many rights on top level then some of
people got overwhelmed with ammount of access they have, but don't need.


> Class 3 won't be users which are seen via Configuration->Users. I still
> haven't figured out if they count as "Everybody" or "Unprivileged." I'd like
> them to be able to view any ticket (although I suspect they will rarely use
> such a power) so I'm giving them ShowTicket and ShowComment and a few other
> minor privileges.
>

ShowTicket is enough to see replies, but RT has comments as well. Comments
are protected by ShowComment right and often used for internal dialogs right
in a ticket between privileged users.


> Does that sound about right?
>
>
> *Josh Narins*
>
> Director of Application Development
> SeniorBridge
> 845 Third Ave
> 7th Floor
> New York, NY 10022
> Tel: (212) 994-6194
> Fax: (212) 994-4260
> Mobile: (917) 488-6248
> jnar...@seniorbridge.com
> seniorbridge.com 
>
> [image: SeniorBridge]
>
> --
> *SeniorBridge Statement of Confidentiality:* The contents of this email
> message are intended for the exclusive use of the addressee(s) and may
> contain confidential or privileged information. Any dissemination,
> distribution or copying of this email by an unintended or mistaken recipient
> is strictly prohibited. In said event, kindly reply to the sender and
> destroy all entries of this message and any attachments from your system.
> Thank you.
>



-- 
Best regards, Ruslan.

Re: [rt-users] rt_client ruby: Issue with attachments in a multipart email

[Tom Lahti]

So, I went ahead and set up a test case with an RT instance here and made an 
attachment with a comma in the filename to play with.  There is now an updated 
rt-client on rubygems.org, version 0.3.3 that addresses the issue and should 
work.  Let me know if you have any problems.

There are probably additional methods in the API that you haven't seen before 
as well, read the docs.  I don't think I've broken backward compatibility on 
this gem ever, but you never know.


--
Tom Lahti, SCMDBA, LPIC-1, CLA
BIT LLC
425-251-0833 x 117




On Oct 24, 2010, at 9:00 PM, Tom Lahti wrote:

> Send me a patch.  I'm the author of that gem.  Or if you need help, send me 
> your email as a text file and I'll look into it.  
> 
> As far as I know roart does not do attachments at all, but that may have 
> changed.  I'm not involved with that gem -- it was made for Rails programmers 
> who are familiar with ActiveRecord, whereas rt-client was made (by me) for a 
> more procedural approach.  As I'm not a rails guy, that paradigm never 
> occurred to me.
> 
> In fact, I think I have some updates on my dev box that I haven't pushed to 
> gemcutter, but I'm sure I haven't addressed your issue.
> 
> On Oct 24, 2010, at 8:14 PM, Thierry Thelliez 
>  wrote:
> 
>> Ok, 2nd correction. sorry.
>> 
>> 
>> The error was not with the multipart, and not with the regular
>> expression.  It is in the line:
>> 
>>list = th["attachments"].to_s.split(",")
>> 
>> It is splitting the lines based on the presence of commas.  My
>> filename contains a comma...
>> 
>> 
>> 
>> Thierry

[rt-users] Extract X-Arf

[Bryan Taylor]

Hello,
  I am using RT for an abuse desk. I receive loads of reports from AOL's
scomp spam reporter in X-Arf format. X-Arf consists of multi-part mime
messages reporting the spam and containing the original header
information. Ideally I would like to extract some of the headers of the
second and third part into custom fields. X-Imp-User is definitely of
interest. Currently the subject of the reports is just the smtp server
it came from, making managing this a extremely tedious to almost
impossible job. Seems X-arf took off as a great reporting tool but no
way to mine the reports! I have been using
RT-Extension-ExtractCustomFieldValues but it does not appear to be
working. I have decided I will 'try' to craft ExtractCustomFieldValues
itself to possibly ExtractXarfValues as another extension if need be. 

Thank you,
Bryan Taylor

Re: [rt-users] dont reopen

[Christian Loos]

Hi,

i just added your version of this to the wiki page.

We only allow re-opening the ticket if it is resolved less then 7 days.
If the ticket is resolved more than 7 days, the requestor gets an mail
(template), that it isn't allowed to re-open the ticket.

-Chris

Am 23.10.2010 01:46, schrieb Ruslan Zakirov:
> Hello Albert,
> 
> See http://wiki.bestpractical.com/view/AutoOpenProblem with reference
> to forking into a new ticket.
> 
> On Fri, Oct 22, 2010 at 12:12 AM, Albert Shih  wrote:
>> Hi all
>>
>> I'm using RT 3.8.8
>>
>> On reply RT reopen the ticket. I would like to known if it's possible to
>> make RT don't reopen a resolved ticket but send a message
>>
>> Many people don't known the «compose» button and only known «reply» button,
>> so I've some ticket live for ever...
>>
>> Regards.
>>
>> JAS

Re: [rt-users] Considering RT for New Web Site

[Kenneth Crocker]

Eric,

I'm not sure what you mean by "reskin" but the rest sounds easy to set up.
The permission rights are VERY flexible (I'd recommend putting all users in
Descriptive groups, named for their function and Queue/access needs).
It's easy to set up new Queues for different sets/types of tickets.
Custom Fields can be created that are either global or unique to any Queue.
Additional Status values can also be added (we use a combination of extra
Status values and a Custom Field)
Extra functionality can be coded via scrip (in perl) also on a Global or
unique to any Queue.
You can set up your own unique set of email templates both Globally and by
Queue.

Most everyone here in the list are very helpful on these issues and several
members of the BP staff jump in with critical technical knowledge as well.

Just send in your questions and I'm sure someone will be able to help.

Kenn
LBNL

On Sat, Oct 23, 2010 at 9:46 AM, Eric Berg  wrote:

> Hey, folks.  I'm hoping that you can help me in evaluating RT for a project
> i'm working on.We're brokering research, so we have clients who submit
> questions which we route anonymously to various researchers who ultimately
> publish their work products back to the client who made the request.
>
> A friend who uses RT suggested that I take a look at it when I'd begun
> telling him about the workflow requirements.
>
> Among our needs are:
>
> - user profiling, ideally within companies
> - document management.  both the questions and the research that provides
> the answers need to be revisioned.
> - flexible authorization scheme.
> - Workflow (permissions configurable by group and state/desk)
> - auditing and reporting.  We'll need to do reporting on the number of
> interactions, number of questions asked, status of all questions and
> answers, reminders on SLA violations
> - easy to reskin.
>
> From what I've gotten from poking around the web site, it looks like RT
> might be a good fit.  Waht do you guys with some RT experience think about
> using it that way?
>
> Thanks.
>
> Eric
>

Re: [rt-users] General permissions question

[Kenneth Crocker]

Josh,

You can do what you want.
By watching this list, I've noticed there are hundreds of installations that
do things differently. Some let the Requestors modify their own tickets,
etc.
What I put down was just a suggestion for you and it will most likely not
apply for others.

Kenn
LBNL

On Mon, Oct 25, 2010 at 5:44 AM, Josh Narins wrote:

>  Ken, thanks for your time.
>
>
>
> While the below looks really good both in the sense that it appears to be
> consistent and in the sense you've laid it all out for me, could I get
> someone else's opinion on it?
>
>
>
> Ruslan or Jesse perhaps?
>
>
>
> If it all looks good, then maybe (it could get posted|I could post it) to
> the wiki as an example?
>
>
>
> Thanks,
>
> Josh
>
>
>
>
> *Josh Narins*
>
> Director of Application Development
> SeniorBridge
> 845 Third Ave
> 7th Floor
> New York, NY 10022
> Tel: (212) 994-6194
> Fax: (212) 994-4260
> Mobile: (917) 488-6248
> jnar...@seniorbridge.com
> seniorbridge.com 
>
> [image: SeniorBridge]
>
> *From:* rt-users-boun...@lists.bestpractical.com [mailto:
> rt-users-boun...@lists.bestpractical.com] *On Behalf Of *Kenneth Crocker
> *Sent:* Friday, October 22, 2010 12:50 PM
> *To:* rt-users@lists.bestpractical.com
> *Subject:* Re: [rt-users] General permissions question
>
>
>
> Josh,
>
> We never grant rights to individual users, too much maintenance. I agree
> with Jesse (DUH!) to create a SuperUSer Group like "System Admins", then
> another called "Technical Support". I'd set rights as follows:
>
> Global System Rights:
>
>- Privileged:
>
>
> - CreateOwnDashboard
>   - CreateSavedSearch
>   - DeleteOwnDashboard
>   - EditSavedSearch
>   - ForwardMessage
>   - LoadSavedSearch
>   - ModifyOwnDashboard
>   - ModifySelf
>   - SeeOwnDashboard
>   - * SeeQueue (*you might want this only at a "Queue" level*)
>   - ShowSavedSearch
>   - * ShowTicket (*you might want this only for "Roles" and the
>   "support" group*)
>   - SubscribeDashboard
>   - Watch
>
> This set will allow all users rights to their own Searches, Searches saved
> for groups they are in & Dashboards set up subscriptions for any Dashboard
> they have access to & modify themselves & add watchers to tickets they are
> watchers on (basically, add Cc's)
>
>- Everyone:
>
>
> - ReplyToTicket
>   - CreateTicket
>
> This allows anyone to create a ticket and reply to email if sent to them
> from RT. If you have some form of externalAuth going on, that will keep the
> spam out.
>
>- Roles:
>
>
> - Owner;
>
>
> - ModifyTicket (a no brainer)
>  - * SeeQueue & ShowTicket Comments, etc if not by group
>
>
> - AdminCc (*we use AdminCc like a "Queue Manager*);
>
>
> - AdminUsers (*Sys Admin only?*)
>  - AdminCustomFields (*Sys Admin only?*)
>  - AssignCustomFields (*we don't want just anyone messing with
>  these*)
>  - ModifyACL (*you may want to keep this at the "Queue" level or
>  not at all and just let "SuperUsers" do it*)
>  - ModifyOwnMembership
>  - ModifyQueueWatchers (*you may want to keep this at the "Queue"
>  level or not at all and just let "SuperUsers" do it*)
>  - ModifyScrips (*you may want to keep this at the "Queue" level
>  or not at all and just let "SuperUsers" do it*)
>  - ModifyTemplate (*you may want to keep this at the "Queue" level
>  or not at all and just let "SuperUsers" do it*)
>  - ShowACL (*you may want to keep this at the "Queue" level or not
>  at all and just for "SuperUsers"*)
>  - SeeCustomFields (*ditto*)
>  - SeeGroup
>  - * SeeQueue & ShowTicket Comments, etc if not by group (*
>  SuperUser*)
>  - ShowConfigTab (*Sys Admin only?*)
>  - ShowScrips (*Sys Admin only?*)
>  - ShowTemplate (*Sys Admin only?*)
>  - StealTicket (*you may want to keep this at the "Queue" level or
>  let Support group do it*)
>  - WatchAsAdminCc
>  - *You might want to put some of these rights at the Queue level*
>
>
> - Cc;
>
>
> - SeeQueue (*if not given to "Privileged"*)
>  - ShowTicket (*if not given to "Privileged"*)
>
>
> - Requestor
>
>
> - SeeQueue (*if not given to "Privileged" or Support Group*)
>  - ShowTicket (*if not given to "Privileged" or Support Group*)
>
> Since your "Users" that create tickets will only use
> email, these two rights above would allow them to see ONLY their tickets if
> they were to ever sign into the WebUI.
>
>- User-Defined Groups:
>
>
> - SystemAdmin;
>
>
> - SuperUser
>
>
> - Technical-Support (you may want to keep some of these rights for
>   this group at the "Queue" level)
>
>
> - CommentOnTicket
>  - DeleteTicket
>  - ModifyCustomField (may want this at the "Queue" level)
>  - ModifyTicket (*

Re: [rt-users] General permissions question

[Josh Narins]

Ken, thanks for your time.

While the below looks really good both in the sense that it appears to be 
consistent and in the sense you've laid it all out for me, could I get someone 
else's opinion on it?

Ruslan or Jesse perhaps?

If it all looks good, then maybe (it could get posted|I could post it) to the 
wiki as an example?

Thanks,
Josh



Josh Narins

Director of Application Development
SeniorBridge
845 Third Ave
7th Floor
New York, NY 10022
Tel: (212) 994-6194
Fax: (212) 994-4260
Mobile: (917) 488-6248
jnar...@seniorbridge.com
seniorbridge.com

[http://www.seniorbridge.com/images/seniorbridgedisclaimerTAG.gif]
From: rt-users-boun...@lists.bestpractical.com 
[mailto:rt-users-boun...@lists.bestpractical.com] On Behalf Of Kenneth Crocker
Sent: Friday, October 22, 2010 12:50 PM
To: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] General permissions question

Josh,

We never grant rights to individual users, too much maintenance. I agree with 
Jesse (DUH!) to create a SuperUSer Group like "System Admins", then another 
called "Technical Support". I'd set rights as follows:

Global System Rights:

 *   Privileged:

*   CreateOwnDashboard
*   CreateSavedSearch
*   DeleteOwnDashboard
*   EditSavedSearch
*   ForwardMessage
*   LoadSavedSearch
*   ModifyOwnDashboard
*   ModifySelf
*   SeeOwnDashboard
*   * SeeQueue (you might want this only at a "Queue" level)
*   ShowSavedSearch
*   * ShowTicket (you might want this only for "Roles" and the "support" 
group)
*   SubscribeDashboard
*   Watch
This set will allow all users rights to their own Searches, Searches saved for 
groups they are in & Dashboards set up subscriptions for any Dashboard they 
have access to & modify themselves & add watchers to tickets they are watchers 
on (basically, add Cc's)

 *   Everyone:

*   ReplyToTicket
*   CreateTicket
This allows anyone to create a ticket and reply to email if sent to them from 
RT. If you have some form of externalAuth going on, that will keep the spam out.

 *   Roles:

*   Owner;

   *   ModifyTicket (a no brainer)
   *   * SeeQueue & ShowTicket Comments, etc if not by group

*   AdminCc (we use AdminCc like a "Queue Manager);

   *   AdminUsers (Sys Admin only?)
   *   AdminCustomFields (Sys Admin only?)
   *   AssignCustomFields (we don't want just anyone messing with these)
   *   ModifyACL (you may want to keep this at the "Queue" level or not at 
all and just let "SuperUsers" do it)
   *   ModifyOwnMembership
   *   ModifyQueueWatchers (you may want to keep this at the "Queue" level 
or not at all and just let "SuperUsers" do it)
   *   ModifyScrips (you may want to keep this at the "Queue" level or not 
at all and just let "SuperUsers" do it)
   *   ModifyTemplate (you may want to keep this at the "Queue" level or 
not at all and just let "SuperUsers" do it)
   *   ShowACL (you may want to keep this at the "Queue" level or not at 
all and just for "SuperUsers")
   *   SeeCustomFields (ditto)
   *   SeeGroup
   *   * SeeQueue & ShowTicket Comments, etc if not by group (SuperUser)
   *   ShowConfigTab (Sys Admin only?)
   *   ShowScrips (Sys Admin only?)
   *   ShowTemplate (Sys Admin only?)
   *   StealTicket (you may want to keep this at the "Queue" level or let 
Support group do it)
   *   WatchAsAdminCc
   *   You might want to put some of these rights at the Queue level

*   Cc;

   *   SeeQueue (if not given to "Privileged")
   *   ShowTicket (if not given to "Privileged")

*   Requestor

   *   SeeQueue (if not given to "Privileged" or Support Group)
   *   ShowTicket (if not given to "Privileged" or Support Group)
Since your "Users" that create tickets will only use email, 
these two rights above would allow them to see ONLY their tickets if they were 
to ever sign into the WebUI.

 *   User-Defined Groups:

*   SystemAdmin;

   *   SuperUser

*   Technical-Support (you may want to keep some of these rights for this 
group at the "Queue" level)

   *   CommentOnTicket
   *   DeleteTicket
   *   ModifyCustomField (may want this at the "Queue" level)
   *   ModifyTicket (ONLY if you want members of the group to be able to 
modify someone else's ticket - Owners already have this right)
   *   OwnTicket
   *   SeeCustomField
   *   ShowOutgoingEmail
   *   ShowTicket
   *   ShowTicketComments
   *   StealTicket (you may want to keep this at the "Queue" level)
   *   TakeTicket

Well, anyway, I'm sure you can get the gist of this. Hope this helps.

Kenn
LBNL
On Fri, Oct 22, 2010 at 6:34 AM, Josh Narins 
mailto:jnar...@seniorbridge.com>> wrote:
I have three classes of users, I'm wondering if my privileges/groups setup is 
what RT intends.

Class 1: Administrators. These three people can do anything.
Class 2: People 

Re: [rt-users] Attachments to email

[Joop]

Sory to bump this message.

Doesn't anyone have an opinion as to how RT should behave?

Regards,

Joop

Re: [rt-users] Pressing the ticket Create button twice creates the same ticket twice

[Markus.Kummer]

Hi Ruslan,

sorry for the late response but I was out of office for a week.

I tried the patch and it is working for the purpose it is made for. Only one 
ticket is created at a time.
But there are many side effects too:

If you create a "New Search" (same for "Edit Search") and press the buttons

- "Add these terms and search" (Below the "Add Criteria" box)
- "Update format and search" (At the right lower corner of the page)

the page is reloaded only and the results are not shown.
The "Show Results" button at the horizontal navigation at the top of the page 
works.

If you write a "Comment" and you press the "Update Ticket" button the page is 
reloaded either and the comment is not applied to the ticket.
The same with the "Reply", "Forward" and "Resolve" functions.
If you press "Save Changes" under "Configuration" -> "Custom Fields" while 
editing a custom field: same misbehaviour.

The "Update" button under the "Bulk Update" is working.

I cleared the cache and restarted apache before.

Best regards,

Markus

T-Systems International GmbH
SDU Telco NPS
Vorgebirgsstr. 49
53119 Bonn
Tel: + 49 228 9841 3820
E-Mail: markus.kum...@t-systems.com 

T-Systems International GmbH
Supervisory Board: René Obermann (Chairman)
Board of Management: Reinhard Clemens (Chairman), Dr. Ferri Abolhassan, Olaf 
Heyden, Joachim Langmack, Georg Pepping, Klaus Werner
Commercial register: Amtsgericht Frankfurt am Main HRB 55933
Registered office: Frankfurt am Main
WEEE -Reg.-No. DE87523644 
-Ursprüngliche Nachricht-
Von: ruslan.zaki...@gmail.com [mailto:ruslan.zaki...@gmail.com] Im Auftrag von 
Ruslan Zakirov
Gesendet: Montag, 18. Oktober 2010 23:07
An: Kummer, Markus
Cc: rt-users@lists.bestpractical.com
Betreff: Re: [rt-users] Pressing the ticket Create button twice creates the 
same ticket twice

Hi,

Try attached patch. Check if it works and let it roll for a while. If it works 
and there are no objections from other developers then I'll push it into the 
core.

Don't forget to clean mason cache and restart web server.

On Fri, Oct 15, 2010 at 10:33 AM,   wrote:
> Dear list,
>
> My environment:
>
> RT 3.8.8
> Perl 5.8.8
> apache 2.2.8
> FastCGI 2.4.6
> OS: Ubuntu or SuSE (same behaviour)
>
> I have a problem with the ticket creation. The following situation:
>
> A user wants to create a ticket and clicks the create button. Because of a 
> slow network connection the response takes some seconds. The user is 
> impatient and presses the create button again. -> Two tickets with different 
> id's but same content are created. The user can create the same ticket as 
> long as the response from the first create has come back.
>
> This did not occur in RT 3.4.6.
>
> Is there any way to deactivate the create button until the request has 
> finished?
>
> Thanks for any help.
>
> Best regards,
>
> Markus
> 
> T-Systems International GmbH
> SDU Telco NPS
> Vorgebirgsstr. 49
> 53119 Bonn
> Tel: + 49 228 9841 3820
> E-Mail: markus.kum...@t-systems.com
>
> T-Systems International GmbH
> Supervisory Board: René Obermann (Chairman) Board of Management: 
> Reinhard Clemens (Chairman), Dr. Ferri Abolhassan, Olaf Heyden, 
> Joachim Langmack, Georg Pepping, Klaus Werner Commercial register: 
> Amtsgericht Frankfurt am Main HRB 55933 Registered office: Frankfurt 
> am Main WEEE -Reg.-No. DE87523644
>
> RT Training in Washington DC, USA on Oct 25 & 26 2010 Last one this 
> year -- Learn how to get the most out of RT!
>



--
Best regards, Ruslan.