Emails causing duplicate tickets?

Hi all,
I just ran into a very odd problem. I opened a ticket via email, which
worked. But I then saw three more tickets open from that same email, each
at the next mail polling. I haven’t seen this problem before, and I don’t
know where to look to tell RT what to do with fetched emails. As I said, I
only just started seeing this, which means I must have changed something.
All I did was add a few more queues to my fetchmailrc file, though. Are
there fetchmail options I should add, or is this an RT setting? If the
latter, is it in the web UI or somewhere in a configuration file? Thanks
for any help.

Alex Hall
Automatic Distributors, IT department
ahall@autodist.com

Hi all,
I just ran into a very odd problem. I opened a ticket via email, which worked. But I then saw three more tickets open from that same email, each at the next mail polling. I haven’t seen this problem before, and I don’t know where to look to tell RT what to do with fetched emails. As I said, I only just started seeing this, which means I must have changed something. All I did was add a few more queues to my fetchmailrc file, though. Are there fetchmail options I should add, or is this an RT setting? If the latter, is it in the web UI or somewhere in a configuration file? Thanks for any help.

Is fetchmail being told to delete mail from the mailbox after it has been fetched? Deleting mail from the mailbox is the default behaviour AFAIK. In any event, with or without deleting mail after it is fetched you’ll probably want to use the ‘uidl’ keyword in your configuration to keep track of what messages are considered new on your side of things instead of relying on the server to decide what’s new and what’s not.

From ‘man 1 fetchmailrc’:

   -U | --uidl
          (Keyword: uidl)
          Force UIDL use (effective only with POP3).  Force client-side tracking of 'newness' of messages (UIDL stands for "unique ID listing"
          and  is  described  in RFC1939).  Use with 'keep' to use a mailbox as a baby news drop for a group of users. The fact that seen mes‐
          sages are skipped is logged, unless error logging is done through syslog while running in daemon  mode.   Note  that  fetchmail  may
          automatically  enable  this  option depending on upstream server capabilities.  Note also that this option may be removed and forced
          enabled in a future fetchmail version. See also: --idfile.

Landon Stewart
Lead Analyst - Abuse and Security Management
INTERNAP ®
:e-mail: lstewart@internap.commailto:lstewart@internap.com
:earth_africa: www.internap.comhttp://www.internap.com

That’s the behavior I want. My problem is that the email then stays in the
inbox or imap subfolder without being deleted. This causes RT to make a new
ticket from that same email over and over again, since it always thinks
it’s a new message, even though it already processed it.On Wed, Sep 7, 2016 at 2:08 PM, Kenneth Crocker kenn.crocker@gmail.com wrote:

Alex,

In order for RT to know NOT to create a new email, there is supposed to be
a reference to an existing ticket number in the subject or something like
that. If people are just sending emails to RT with no referring ticket
number, RT will think it is a new ticket request.

Kenn

On Wed, Sep 7, 2016 at 10:13 AM, Alex Hall ahall@autodist.com wrote:

Hi all,
I just ran into a very odd problem. I opened a ticket via email, which
worked. But I then saw three more tickets open from that same email, each
at the next mail polling. I haven’t seen this problem before, and I don’t
know where to look to tell RT what to do with fetched emails. As I said, I
only just started seeing this, which means I must have changed something.
All I did was add a few more queues to my fetchmailrc file, though. Are
there fetchmail options I should add, or is this an RT setting? If the
latter, is it in the web UI or somewhere in a configuration file? Thanks
for any help.


Alex Hall
Automatic Distributors, IT department
ahall@autodist.com


RT 4.4 and RTIR training sessions, and a new workshop day!
https://bestpractical.com/training

  • Boston - October 24-26
  • Los Angeles - Q1 2017

Alex Hall
Automatic Distributors, IT department
ahall@autodist.com