Weird Behavior

RT Users
1

So I have an instance of RT installed, and thing seem to work fine.
Except users with a MAC that are using the Alpine client seem to not be
able to properly reply to a ticket. They can create new tickets jsut
fine, but when attempting to respond to a ticket, every response creates
a new ticket.

Any ideas on why that might happen?

Thanks

Mark

2

So I have an instance of RT installed, and thing seem to work fine.
Except users with a MAC that are using the Alpine client seem to not be
able to properly reply to a ticket. They can create new tickets jsut
fine, but when attempting to respond to a ticket, every response creates
a new ticket.

Any ideas on why that might happen?

Is alpine mussing with the Subject field somehow?

Jeremy

3

So for testing I ran the following

cat |/usr/sbin/rt-mailgate --queue xxxxxxx --action correspond --url
https://xxxxxxx.xx.xxx.edu/rt --debug

Then pasted the following in

Delivered-To: xxxxx@xx.xxx.eduSubject: [xxxxx xx.xxx.edu #1091]
To: xxxxx@xx.xxx.edu
From: Xxxx Xxxxxxxx xxxx@xxx.edu
Return-Path: xxxx@xxx.edu

testing

And this created a new ticket #1111

I thought all this had to do was match what was in the subject brackets
and the ticket number and it would add it. What am I missing here?

4

In “Subject: [xxxxx xx.xxx.edu #1091]”, does “xxxxx xx.xxx.edu” precisely
match either of your $rtname config value or a queue’s “Subject Tag”
setting? The fact that there’s a space in there suggests that it might not.On 3 July 2014 13:19, Mark Campbell mcc171@psu.edu wrote:

So for testing I ran the following

cat |/usr/sbin/rt-mailgate --queue xxxxxxx --action correspond --url
https://xxxxxxx.xx.xxx.edu/rt --debug

Then pasted the following in

Delivered-To: xxxxx@xx.xxx.edu
Subject: [xxxxx xx.xxx.edu #1091]
To: xxxxx@xx.xxx.edu
From: Xxxx Xxxxxxxx xxxx@xxx.edu
Return-Path: xxxx@xxx.edu

testing

And this created a new ticket #1111

I thought all this had to do was match what was in the subject brackets
and the ticket number and it would add it. What am I missing here?

On 7/2/2014 4:08 PM, Mark Campbell wrote:

So I have an instance of RT installed, and thing seem to work fine.
Except users with a MAC that are using the Alpine client seem to not be
able to properly reply to a ticket. They can create new tickets jsut fine,
but when attempting to respond to a ticket, every response creates a new
ticket.

Any ideas on why that might happen?

Thanks

Mark

–
RT Training - Boston, September 9-10
http://bestpractical.com/training

5

So the $rtname is cg.xxx.edu

The subject tag on the queue is configured as the CGTag cg.xxx.edu

Should it simply be the rtname?On 7/2/2014 11:23 PM, Alex Peters wrote:

In “Subject: [xxxxx xx.xxx.edu http://xx.xxx.edu #1091]”, does
“xxxxx xx.xxx.edu http://xx.xxx.edu” precisely match either of your
$rtname config value or a queue’s “Subject Tag” setting? The fact
that there’s a space in there suggests that it might not.

On 3 July 2014 13:19, Mark Campbell <mcc171@psu.edu mailto:mcc171@psu.edu> wrote:

So for testing I ran the following


cat |/usr/sbin/rt-mailgate --queue xxxxxxx --action correspond
--url https://xxxxxxx.xx.xxx.edu/rt --debug




Then pasted the following in

Delivered-To: xxxxx@xx.xxx.edu <mailto:xxxxx@xx.xxx.edu>
Subject: [xxxxx xx.xxx.edu <http://xx.xxx.edu> #1091]
To: xxxxx@xx.xxx.edu <mailto:xxxxx@xx.xxx.edu>
From: Xxxx Xxxxxxxx <xxxx@xxx.edu <mailto:xxxx@xxx.edu>>
Return-Path:    <xxxx@xxx.edu <mailto:xxxx@xxx.edu>>


testing


And this created a new ticket #1111

I thought all this had to do was match what was in the subject
brackets and the ticket number and it would add it.  What am I
missing here?





On 7/2/2014 4:08 PM, Mark Campbell wrote:

    So I have an instance of RT installed, and thing seem to work
    fine. Except users with a MAC that are using the Alpine client
    seem to not be able to properly reply to a ticket.  They can
    create new tickets jsut fine, but when attempting to respond
    to a ticket, every response creates a new ticket.

    Any ideas on why that might happen?

    Thanks

    Mark


-- 
RT Training - Boston, September 9-10
http://bestpractical.com/training
6

I’m not sure what “the CGTag” means but if the subject tag on the queue is
exactly the same as the $rtname, you can leave the subject tag blank (it
will default to $rtname).

Basically the only thing between those square brackets in the Subject line
of the email should be the $rtname or a queue’s subject tag, followed by a
space, a hash and a ticket number.

If that’s the case and it’s still not working, RT debug logs might come in
handy.On 3 July 2014 13:30, Mark Campbell mcc171@psu.edu wrote:

So the $rtname is cg.xxx.edu

The subject tag on the queue is configured as the CGTag cg.xxx.edu

Should it simply be the rtname?

On 7/2/2014 11:23 PM, Alex Peters wrote:

In “Subject: [xxxxx xx.xxx.edu #1091]”, does “xxxxx xx.xxx.edu” precisely
match either of your $rtname config value or a queue’s “Subject Tag”
setting? The fact that there’s a space in there suggests that it might not.

On 3 July 2014 13:19, Mark Campbell mcc171@psu.edu wrote:

So for testing I ran the following

cat |/usr/sbin/rt-mailgate --queue xxxxxxx --action correspond --url
https://xxxxxxx.xx.xxx.edu/rt --debug

Then pasted the following in

Delivered-To: xxxxx@xx.xxx.edu
Subject: [xxxxx xx.xxx.edu #1091]
To: xxxxx@xx.xxx.edu
From: Xxxx Xxxxxxxx xxxx@xxx.edu
Return-Path: xxxx@xxx.edu

testing

And this created a new ticket #1111

I thought all this had to do was match what was in the subject brackets
and the ticket number and it would add it. What am I missing here?

On 7/2/2014 4:08 PM, Mark Campbell wrote:

So I have an instance of RT installed, and thing seem to work fine.
Except users with a MAC that are using the Alpine client seem to not be
able to properly reply to a ticket. They can create new tickets jsut fine,
but when attempting to respond to a ticket, every response creates a new
ticket.

Any ideas on why that might happen?

Thanks

Mark

–
RT Training - Boston, September 9-10
http://bestpractical.com/training

–
RT Training - Boston, September 9-10
http://bestpractical.com/training

7

Sorry CG tag would be what we use to describe the queue and cg.xxx.edu
as the rtname. For instance the Networking queue would look like

[Networking cg.xxx.edu #1091]

So in the subject tag field for the queue configuration we have
“Networking cg.xxx.edu”

Is this not allowed? or would the space between Networking and
cg.xxx.edu cause issues?

MarkOn 7/2/2014 11:34 PM, Alex Peters wrote:

I’m not sure what “the CGTag” means but if the subject tag on the
queue is exactly the same as the $rtname, you can leave the subject
tag blank (it will default to $rtname).

Basically the only thing between those square brackets in the Subject
line of the email should be the $rtname or a queue’s subject tag,
followed by a space, a hash and a ticket number.

If that’s the case and it’s still not working, RT debug logs might
come in handy.

On 3 July 2014 13:30, Mark Campbell <mcc171@psu.edu mailto:mcc171@psu.edu> wrote:

So the $rtname is cg.xxx.edu <http://cg.xxx.edu>

The subject tag on the queue is configured as the CGTag cg.xxx.edu
<http://cg.xxx.edu>

Should it simply be the rtname?




On 7/2/2014 11:23 PM, Alex Peters wrote:

In "Subject: [xxxxx xx.xxx.edu <http://xx.xxx.edu> #1091]", does
"xxxxx xx.xxx.edu <http://xx.xxx.edu>" precisely match either of
your $rtname config value or a queue's "Subject Tag" setting?
 The fact that there's a space in there suggests that it might not.


On 3 July 2014 13:19, Mark Campbell <mcc171@psu.edu <mailto:mcc171@psu.edu>> wrote:


    So for testing I ran the following


    cat |/usr/sbin/rt-mailgate --queue xxxxxxx --action
    correspond --url https://xxxxxxx.xx.xxx.edu/rt --debug




    Then pasted the following in

    Delivered-To: xxxxx@xx.xxx.edu <mailto:xxxxx@xx.xxx.edu>
    Subject: [xxxxx xx.xxx.edu <http://xx.xxx.edu> #1091]
    To: xxxxx@xx.xxx.edu <mailto:xxxxx@xx.xxx.edu>
    From: Xxxx Xxxxxxxx <xxxx@xxx.edu <mailto:xxxx@xxx.edu>>
    Return-Path:    <xxxx@xxx.edu <mailto:xxxx@xxx.edu>>


    testing


    And this created a new ticket #1111

    I thought all this had to do was match what was in the
    subject brackets and the ticket number and it would add it.
     What am I missing here?





    On 7/2/2014 4:08 PM, Mark Campbell wrote:

        So I have an instance of RT installed, and thing seem to
        work fine. Except users with a MAC that are using the
        Alpine client seem to not be able to properly reply to a
        ticket.  They can create new tickets jsut fine, but when
        attempting to respond to a ticket, every response creates
        a new ticket.

        Any ideas on why that might happen?

        Thanks

        Mark


    -- 
    RT Training - Boston, September 9-10
    http://bestpractical.com/training

--
RT Training - Boston, September 9-10
http://bestpractical.com/training
8

As far as I know, that is acceptable as long as the Subject Tag value for
the queue explicitly includes the $rtname value within it.

Your example Subject string of “[Networking cg.xxx.edu #1091]” should be
acceptable if the Subject Tag value for one of your queues is precisely "
Networking cg.xxx.edu".

For debugging purposes, you can also simply use “[$rtname #1091]”
(replacing “$rtname” with the actual $rtname value) to rule out the queue’s
Subject Tag value as the problem. That is, if your $rtname is “cg.xxx.edu”,
consider sending a test mail with Subject “[cg.edu.au #1091]” to rule out
queue-specific Subject Tag problems.

If you’re still having no luck, consider posting RT’s debug log when it
accepts the mail for processing.On 3 July 2014 13:56, Mark Campbell mcc171@psu.edu wrote:

Sorry CG tag would be what we use to describe the queue and cg.xxx.edu
as the rtname. For instance the Networking queue would look like

[Networking cg.xxx.edu #1091]

So in the subject tag field for the queue configuration we have
“Networking cg.xxx.edu”

Is this not allowed? or would the space between Networking and cg.xxx.edu
cause issues?

Mark

On 7/2/2014 11:34 PM, Alex Peters wrote:

I’m not sure what “the CGTag” means but if the subject tag on the queue is
exactly the same as the $rtname, you can leave the subject tag blank (it
will default to $rtname).

Basically the only thing between those square brackets in the Subject
line of the email should be the $rtname or a queue’s subject tag, followed
by a space, a hash and a ticket number.

If that’s the case and it’s still not working, RT debug logs might come
in handy.

On 3 July 2014 13:30, Mark Campbell mcc171@psu.edu wrote:

So the $rtname is cg.xxx.edu

The subject tag on the queue is configured as the CGTag cg.xxx.edu

Should it simply be the rtname?

On 7/2/2014 11:23 PM, Alex Peters wrote:

In “Subject: [xxxxx xx.xxx.edu #1091]”, does “xxxxx xx.xxx.edu”
precisely match either of your $rtname config value or a queue’s “Subject
Tag” setting? The fact that there’s a space in there suggests that it
might not.

On 3 July 2014 13:19, Mark Campbell mcc171@psu.edu wrote:

So for testing I ran the following

cat |/usr/sbin/rt-mailgate --queue xxxxxxx --action correspond --url
https://xxxxxxx.xx.xxx.edu/rt --debug

Then pasted the following in

Delivered-To: xxxxx@xx.xxx.edu
Subject: [xxxxx xx.xxx.edu #1091]
To: xxxxx@xx.xxx.edu
From: Xxxx Xxxxxxxx xxxx@xxx.edu
Return-Path: xxxx@xxx.edu

testing

And this created a new ticket #1111

I thought all this had to do was match what was in the subject brackets
and the ticket number and it would add it. What am I missing here?

On 7/2/2014 4:08 PM, Mark Campbell wrote:

So I have an instance of RT installed, and thing seem to work fine.
Except users with a MAC that are using the Alpine client seem to not be
able to properly reply to a ticket. They can create new tickets jsut fine,
but when attempting to respond to a ticket, every response creates a new
ticket.

Any ideas on why that might happen?

Thanks

Mark

–
RT Training - Boston, September 9-10
http://bestpractical.com/training

–
RT Training - Boston, September 9-10
http://bestpractical.com/training

9

So the subject tag had an extra space in it which must be removed by
something somewhere or by certain clients of something.

Either way it is now only configured to have 1 and it seems to work now.

Thanks for the help.

MarkOn 7/3/2014 12:01 AM, Alex Peters wrote:

As far as I know, that is acceptable as long as the Subject Tag value
for the queue explicitly includes the $rtname value within it.

Your example Subject string of “[Networking cg.xxx.edu
http://cg.xxx.edu #1091]” should be acceptable if the Subject Tag
value for one of your queues is precisely “Networking cg.xxx.edu
http://cg.xxx.edu”.

For debugging purposes, you can also simply use “[$rtname #1091]”
(replacing “$rtname” with the actual $rtname value) to rule out the
queue’s Subject Tag value as the problem. That is, if your $rtname is
“cg.xxx.edu http://cg.xxx.edu”, consider sending a test mail with
Subject “[cg.edu.au http://cg.edu.au #1091]” to rule out
queue-specific Subject Tag problems.

If you’re still having no luck, consider posting RT’s debug log when
it accepts the mail for processing.

On 3 July 2014 13:56, Mark Campbell <mcc171@psu.edu mailto:mcc171@psu.edu> wrote:

Sorry CG tag would be what we use to describe the queue and
cg.xxx.edu <http://cg.xxx.edu> as the rtname.  For instance the
Networking queue would look like

[Networking cg.xxx.edu <http://cg.xxx.edu> #1091]

So in the subject tag field for the queue configuration we have
"Networking cg.xxx.edu <http://cg.xxx.edu>"

Is this not allowed? or would the space between Networking and
cg.xxx.edu <http://cg.xxx.edu> cause issues?

Mark




On 7/2/2014 11:34 PM, Alex Peters wrote:

I'm not sure what "the CGTag" means but if the subject tag on the
queue is exactly the same as the $rtname, you can leave the
subject tag blank (it will default to $rtname).

Basically the only thing between those square brackets in the
Subject line of the email should be the $rtname or a queue's
subject tag, followed by a space, a hash and a ticket number.

If that's the case and it's still not working, RT debug logs
might come in handy.


On 3 July 2014 13:30, Mark Campbell <mcc171@psu.edu <mailto:mcc171@psu.edu>> wrote:

    So the $rtname is cg.xxx.edu <http://cg.xxx.edu>

    The subject tag on the queue is configured as the CGTag
    cg.xxx.edu <http://cg.xxx.edu>

    Should it simply be the rtname?




    On 7/2/2014 11:23 PM, Alex Peters wrote:

    In "Subject: [xxxxx xx.xxx.edu <http://xx.xxx.edu> #1091]",
    does "xxxxx xx.xxx.edu <http://xx.xxx.edu>" precisely match
    either of your $rtname config value or a queue's "Subject
    Tag" setting?  The fact that there's a space in there
    suggests that it might not.


    On 3 July 2014 13:19, Mark Campbell <mcc171@psu.edu <mailto:mcc171@psu.edu>> wrote:


        So for testing I ran the following


        cat |/usr/sbin/rt-mailgate --queue xxxxxxx --action
        correspond --url https://xxxxxxx.xx.xxx.edu/rt --debug




        Then pasted the following in

        Delivered-To: xxxxx@xx.xxx.edu <mailto:xxxxx@xx.xxx.edu>
        Subject: [xxxxx xx.xxx.edu <http://xx.xxx.edu> #1091]
        To: xxxxx@xx.xxx.edu <mailto:xxxxx@xx.xxx.edu>
        From: Xxxx Xxxxxxxx <xxxx@xxx.edu <mailto:xxxx@xxx.edu>>
        Return-Path:    <xxxx@xxx.edu <mailto:xxxx@xxx.edu>>


        testing


        And this created a new ticket #1111

        I thought all this had to do was match what was in the
        subject brackets and the ticket number and it would add
        it.  What am I missing here?





        On 7/2/2014 4:08 PM, Mark Campbell wrote:

            So I have an instance of RT installed, and thing
            seem to work fine. Except users with a MAC that are
            using the Alpine client seem to not be able to
            properly reply to a ticket.  They can create new
            tickets jsut fine, but when attempting to respond to
            a ticket, every response creates a new ticket.

            Any ideas on why that might happen?

            Thanks

            Mark


        -- 
        RT Training - Boston, September 9-10
        http://bestpractical.com/training

    --
    RT Training - Boston, September 9-10
    http://bestpractical.com/training