Re: [rt-users] no new tickets for Mail Delivery failures.
On Tue, 17 Sep 2013, Arun ragini wrote: > Is there any way to stop creating new tickets for mail delivery failures > when RT creates tickets. We did this in the MTA (in our case 'exim') and with an extra RT-Queue named 'trash' :-) How to do this exactly, depends on the MTA-Program. Bounces, and by the same method blatant SPAMs too, are redirected from the normal incoming queue to the queue named 'trash' and this extra 'silent' queue never does any 'correspondence' automatically. A few times per day we look into the trash-queue for false positves and throw away all the 'real garbage'. Yours Stucki -- Christoph von Stuckrad * * |nickname |Mail \ Freie Universitaet Berlin |/_*|'stucki' |Tel(Mo.,Mi.):+49 30 838-75 459| Mathematik & Informatik EDV |\ *|if online| (Di,Do,Fr):+49 30 77 39 6600| Takustr. 9 / 14195 Berlin * * |on IRCnet|Fax(home): +49 30 77 39 6601/ -- RT Training in New York, October 8th and 9th: http://bestpractical.com/training
Re: [rt-users] Users simultaneously replying
On Tue, 15 Jan 2013, Samuel Paris wrote: > Lock the job when a reply is being written? > Or any other suggestions to prevent this for happening? That's what 'take' is for - only one worker can 'take' a ticket. (But it depends on the discipline to 'take first, then answer'!) Less strict would be to 'look for open state', which is set on answering, but will fail if multiple workers look into one queue. For more than those, you will have to define state(s) and create new scrips I believe. Stucki -- Christoph von Stuckrad * * |nickname |Mail \ Freie Universitaet Berlin |/_*|'stucki' |Tel(Mo.,Mi.):+49 30 838-75 459| Mathematik & Informatik EDV |\ *|if online| (Di,Do,Fr):+49 30 77 39 6600| Takustr. 9 / 14195 Berlin * * |on IRCnet|Fax(home): +49 30 77 39 6601/
Re: [rt-users] Multi-tenant
On Thu, 13 Dec 2012, Shuvam Misra wrote: ... > (i.e. multi-tenant support), will anyone want to set up separate servers > then? I would have thought the reverse question is the natural one. Having read only the last thee mails and not much time now, I only want to tell, we did exactly tht, we did split a multi-tenant RT into (only!) two sepearte instances. Here were some more inssues than simply multi-versus-sigle group usage. But one of the reasons might be important. The overall-rights-matrix on only-one-userbase makes it difficult to wall in each of the groups, so they never see or notice one of the others. It *is* possible, but error-prone, if the 'groups' try to administer their own 'set of queues'. One wrong click or 'right' and information leaks will happen. In sigle-tenant-setups this stays impossible and virtual hosts are relatively cheap. Stucki -- Christoph von Stuckrad * * |nickname |Mail \ Freie Universitaet Berlin |/_*|'stucki' |Tel(Mo.,Mi.):+49 30 838-75 459| Mathematik & Informatik EDV |\ *|if online| (Di,Do,Fr):+49 30 77 39 6600| Takustr. 9 / 14195 Berlin * * |on IRCnet|Fax(home): +49 30 77 39 6601/ We're hiring! http://bestpractical.com/jobs
Re: [rt-users] Creating Tickets from forwarded emails?
On Sun, 14 Oct 2012, Jonathan Mills wrote: > Yes, I've read of that solution also. However, ... to do each time > ... will fail ... I second that, having seen lots of these in the years we use RT. (Even if 'we' normally have some 'Bounce'-Method, it sometimes fails). AND just by coincidence I aM searching for the same(!?) Solution for another Problem! IF somebody creates a kind of 'umbrella list' for errors/support-calls, and one of the recipients is a RT-queue, then this queue - must not reply to the list (else we get loops) - does not use (know?) the real sender for the requestor, but uses the liSts sender/reply-to address. The latter is the same problem as 'forwarded' in this thread. Only there never can be anybody, to fix it by explicitely setting some Adresses -- the only way would be a 'scrip' or 'Filter' to switch from (whateber RT does now) to preferring/accepting the ORIGINAL 'From: address' Header. Did somebody see such a fix? Thanks, Stucki -- Christoph von Stuckrad * * |nickname |Mail \ Freie Universitaet Berlin |/_*|'stucki' |Tel(Mo.,Mi.):+49 30 838-75 459| Mathematik & Informatik EDV |\ *|if online| (Di,Do,Fr):+49 30 77 39 6600| Takustr. 9 / 14195 Berlin * * |on IRCnet|Fax(home): +49 30 77 39 6601/ We're hiring! http://bestpractical.com/jobs
Re: [rt-users] rt mail merge?
On Mon, 30 Apr 2012, Josh Tackitt wrote: > Currently our plan is to just use other mail merge software to send the > email with the reply-to set to an RT address so that at least when they > reply the ticket will be created. Which would be ok. It'd just be very > nice to have a ticket # before they reply. Why not turn this around? Create a queue which creates the outgoing mails (to users) as an 'answer' (by template) and start the works by sending mails 'faked from the addresses to send to'. So the 'fakes' create the tickets, the tickets create the mails to the users, and the users reply as usual... Stucki -- Christoph von Stuckrad * * |nickname |Mail \ Freie Universitaet Berlin |/_*|'stucki' |Tel(Mo.,Mi.):+49 30 838-75 459| Mathematik & Informatik EDV |\ *|if online| (Di,Do,Fr):+49 30 77 39 6600| Takustr. 9 / 14195 Berlin * * |on IRCnet|Fax(home): +49 30 77 39 6601/
Re: [rt-users] why my rt4 loop create new ticket or reply ticket from the same email
On Sat, 17 Dec 2011, nectar wrote: > create ticket#5 or other new tickets with the same email content. More ... > I tried to check RT configure, postfix configure and apache configure > files. Still can not find solution. Do you have advise? I had such behavior, when my MTA (in my case exim, not postfix) always believed the delivery had failed and retried forever. So try to find out, which returncode comes from rt's mailgate, and which returncodes postfix does accept as 'correctly delivered'. Stucki -- Christoph von Stuckrad * * |nickname |Mail \ Freie Universitaet Berlin |/_*|'stucki' |Tel(Mo.,Mi.):+49 30 838-75 459| Mathematik & Informatik EDV |\ *|if online| (Di,Do,Fr):+49 30 77 39 6600| Takustr. 9 / 14195 Berlin * * |on IRCnet|Fax(home): +49 30 77 39 6601/ RT Training Sessions (http://bestpractical.com/services/training.html) * Boston March 5 & 6, 2012
