Answers (articles) from agents are shown twice

Infos:

  • Used Zammad version: 3.4.0
  • Used Zammad installation source: source
  • Operating system: Debian 10
  • Browser + version: latest Firefox or Chrome

Expected behavior:

  • If the agent answers in a ticket, his answer should only appear once in the ticket overview.

Actual behavior:

  • When the agent replies in a ticket, he sees his reply and a short time later the same reply again. If the agent has closed the ticket with his first answer, the ticket is open again after the second answer appears.
    The customer gets the answer only once.

Steps to reproduce the behavior:

I’m not sure. We use the Google channel to retrieve and send our mails. We integrated the G-Suite account “support@unsereFirma.de” into Zammad this way.
I attach screenshots to show the problem:

Another observation of mine: when I download the raw eml files from both answers, they are almost the same. In the second email the following lines are added to the beginning of the file, which are missing in the first answer:

Return-Path: support@trollgames.de
Received: from gmail.com ([2a01:488:66:1000:b24d:4b84:0:1])
by smtp.gmail.com with ESMTPSA id s19sm11540922wrb.54.2020.07.30.06.29.38
for <:redacted:r@trollgames.de>
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Thu, 30 Jul 2020 06:29:38 -0700 (PDT)

It looks to me like gmail and Zammad don’t really agree on whether the mail has been sent or not. And that’s why Zammad stores the same email twice in its database. But in the end I have no idea and need your help.

We had this topic a few times.
This is a very good indicator that your sender did send a mail to Zammad and used a mail address Zammad doesn’t know.

Ususally Zammad filters out mail addresses that it does know as it’s own addresses.
Basically what goes wrong here is that you write to your own Zammad address.

Fix your alias setup and you should be fine.
More input on that topic can be found here:
https://admin-docs.zammad.org/en/latest/channels/email/index.html

OK, I managed to get rid of the duplicate answers by setting all groups to have “support@meineFirma.de” as sender.

What irritates me is that this problem was created “just like that”. We were running Zammad in version 2.9 and without changing anything in G-Suite, or Zammad, we suddenly got these double answers.
Partly because of this I switched to version 3.4, but this problem remained.

Aaannd double answers are still there. Man, this is frustrating. When I answer the ticket and closes it immediatly, there is no “ghost” answer. But the support team has another workflow than my tests and they get these ghost answers. I will now try to replicate which exact action that the teams executes leads to the ghost answers and will report these.

A preliminary status of my research:

I can reliably create tickets that do not get “ghost” replies and I can reliably create tickets that get “ghost” replies.

But I still do not know what the problem is. So far I know what was not the problem:

  • the sender address
  • the alias configuration of Google or Zammad
  • the recipient address
  • the ReplyTo header

No matter how the above points are changed, the error pattern is always the same: When I send a mail to Zammad with PHPMailer, the ghost replies appear as soon as the agent answers the ticket. When I send a mail from Thunderbird, or gmail, no ghost replies appear.

I have read everything I could find under the link you posted me. I’ve been trying to get everything right about the aliases. And the setup has been working for years, I had these ghost answers only for a few months without changing anything about the aliases.
For clarity I’ll write down how I use my aliases:

  • There is a G-Suite account that has multiple aliases set up through the Google Admin Console.
  • In Zammad this G-Suite account is set up in the channel “Google” and there are also the “secondary addresses” set up, as described on this page: Secondary Addresses — Zammad Admin Documentation documentation
  • For each of these email addresses there is a group that has the address set as the sender.

This setup has worked for years. So I cannot explain why I should have a problem in my alias setup.

Also, I get the ghost replies even if I write to the email address that is not an alias, the main address of the G-Suite account.

I have tried pretty much everything I could think of to try over the last week. I varied the sender address, the recipient address, I disabled the groups, all filters, triggers and alias addresses. I found out that no email headers or the program I use to send the mail are relevant. The error pattern is always exactly the same: If certain words appear in the subject, then I get the ghost reply. These words are some of our product names. We support six products with Zammad. Three of the product names trigger ghost replies. Not with the others. It is irrelevant to which address I send the mail or in which group the ticket ends up. That alone is irritating enough. What irritates me completely is that these words only appear in the group and role names within Zammad. For example: the email address for one of our products is “productname@company.de”. The corresponding group in Zammad is called “Product Name German” and the role is called “Product Name”. If the string “Product Name” appears in the subject, the ghost replies will appear. But if I change the group name or role name to e.g. “foobar” or “Foo Bar”, the behaviour remains the same. Emails that have the string “Product Name” in the subject will receive ghost replies.

This problem takes me to the edge of madness. I’m a programmer myself and I’m looking for deterministic behavior of a software. What I can observe here is deterministic, but it still doesn’t make sense: With Zammad I have a software that always behaves the same way, namely if certain strings are in the subject, ghost replies are generated. But if I remove these strings from the software (change the name of the group and the role), the behaviour remains the same. How can Zammad react to a string that is no longer contained in Zammad?
It must be due to the nature of the email sent to Zammad. But since I can download the .eml files Zammad gets, I can diff it and see that the emails are exactly the same (except for timestamps, IPs and hashes). Only the content of the subject decides.
I love Zammad and my agents too. But this behavior makes Zammad unusable in the long run. Please help me to get out of this mess!

1 Like

This sounds like you do have triggers active that send mails in specific situations?
Double check your trigger configuration, the issue may life there.

The only other valid reason for “ghost answers” is if you reply to a Zammad alias via Zammad.
This causes Zammad to fetch the mail later on.

What also might help is to check the first and seocnd (ghost) article.
Not just by “type” (press onto the background so the greyish bars appear), but also -if the second article is a mail- the raw message. This may help you to understand what happened.

If a trigger is not at fault, it most likely is a mail alias that routes to the mailbox of Zammad.
If that’s the case, Zammad proberbly doesn’t know that this alias is its alias. If Zammad doesn’t know it’s aliases, it won’t remove them when hitting “reply all” or “reply” and that causes ghost answers as well.

Further help over this extend is a pretty complicated task, because I’d had to see the issue with my own eyes, but well… :-/

Well if it’s exactly the same, please provide the headers of both mails you’re talking about.
Please redact sensitive information but importantly if you do ensure that I can see if mail addresses are the same. So ensure that you redact the same content the same way all over the headers so I can see them as “belonging together”.

Other wise I can’t help you.


What I wanted to add:
What you’re talking about is no default behavior of Zammad. The tips and hints I gave above and on earlier posts are the only legitimate reason for this issue to appear.

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.