[rt-users] Dealing with people who send email to Helpdesk and CC others

Drew Barnes barnesaw at ucrwcu.rwc.uc.edu
Fri Mar 4 12:32:10 EST 2005


Speaking with out mail administrator, I believe we are putting mail that 
is directed to our rt address and has Re: in the subject in a hold 
queue.  He goes over the hold queue a few times a day and can manually 
release the messages which may be necessary.

He is doing that in Postfix.  Can you do something similar in procmail?

DB


Fran Fabrizio wrote:

>
> Yes, thanks. :-)  I read that... right before I intentionally changed 
> the setting to 1, as I mentioned.  :-)  This isn't the issue I'm 
> facing.  I tried to point that out but apparently not very well.
>
> User1 sends an email to user2, user3, and helpdesk.
> User2 "reply all"s to user1's email, sending an email to user1, user3, 
> helpdesk.
> Two tickets have just been created.
>
> Turning off the ParseNewMessageForTicketCcs won't help at all here.
>
> Besides user training to scan the email recipients and realize the 
> ramifications of having helpdesk in the recip list, is there anything 
> that RT can do to prevent this?  Such as figuring out that "Re: 
> Foobar" as a subject line might be related to the "Foobar" subject 
> line that it just turned into a ticket earlier that day?
> Maybe I should just have procmail drop anything headed to RT that has 
> Re: in it without an RT tag.  Seems kludgy though and will definitely 
> kill some legitimate attempts to make a ticket.
>
> -Fran
>
> Drew Barnes wrote:
>
>> # If $ParseNewMessageForTicketCcs is true, RT will attempt to divine
>> # Ticket 'Cc' watchers from the To and Cc lines of incoming messages
>> # Be forewarned that if you have _any_ addresses which forward mail to
>> # RT automatically and you enable this option without modifying
>> # "RTAddressRegexp" below, you will get yourself into a heap of trouble.
>>
>> Set($ParseNewMessageForTicketCcs , undef);
>>
>> # RTAddressRegexp is used to make sure RT doesn't add itself as a 
>> ticket CC if
>> # the setting above is enabled.
>>
>>
>> Fran Fabrizio wrote:
>>
>>>
>>> What's the best way to avoid this scenario:
>>>
>>> 1.  Jeff sends a note with subject "Machine Broken" to Helpdesk and 
>>> CC's Barrett, Tony and John.
>>> 2.  Helpdesk opens a ticket titled "Machine Broken" with Requestors 
>>> Jeff, Barrett, Tony, John and sends a receipt to Jeff with subject 
>>> "[Helpdesk #2008] Helpdesk Update: Machine Broken" to note that it 
>>> has received your request.
>>> 3.  Barrett does Reply All to Jeff's note "Machine Broken".  When he 
>>> does this, his "Re: Machine Broken" reply will go to Jeff, Tony, 
>>> John and Helpdesk.
>>> 4.  This opens another ticket in the Helpdesk titled "Re: Machine 
>>> Broken" and Barrett will receive a receipt from Helpdesk with 
>>> Subject "[Helpdesk #2008] Helpdesk Update: Re: Machine Broken".
>>> 5.  Tony then replies to Jeff's note.  Yet another ticket is 
>>> created.  Etc....
>>>
>>> Right now I enable $ParseNewMessageForTicketCcs but I'm not sure 
>>> that setting comes into play here.  The real issue is that people 
>>> are used to doing Reply All, and don't bother to see if Helpdesk is 
>>> one of the people they are replying to.
>>> I can't figure out a graceful way to handle it.  I want to be 
>>> including all of those others on the ticket, but I don't want their 
>>> replies to be opening new tickets.  Even if I don't 
>>> ParseNewMessageForTicketCcs, they'll still open duplicate tickets 
>>> when they do Reply All.  Is there anything to be done here?
>>>
>>> Thanks,
>>> Fran
>>>
>
>



More information about the rt-users mailing list