Replies from customers create new ticket

Technical assistance
1

Infos:

  • Used Zammad version: 2.9.x
  • Used Zammad installation source: Docker-Compose
  • Operating system: CentOS 7
  • Browser + version: Safari (newest)

Expected behavior:

  • If a customer replies to an e-mail sent from a 3rd party software (BCC’d to Zammad), the answer should be shown within the ticket

Actual behavior:

  • The answer creates a new ticket
2

Am I interpreting this correctly?

  • A 3rd party program sends a mail:

    • From: info@yourcompany.tld (an address handled by your Zammad)
    • To: customer@example.com
    • BCC: info@yourcompany.tld (an address handled by your Zammad)
    • Subject: some subject

    The mail is received by your customer (due to To) and by your Zammad (due to BCC).

  • The customer replies:

    • From: customer@example.com
    • To: info@yourcompany.tld
    • Subject: Re: some subject

    The mail is received by your Zammad.

The problem in this case would be that the first mail creates a new ticket, let’s say #1234. Zammad would put replies containing this ticket ID into the ticket (e.g. Subject: Re: [#1234] some subject), but the customer reply of course doesn’t contain this ID.

Try enabling :gear: → Channels → Email → Settings → Additional follow-up detection → References […].

At least in theory, the customer’s reply should include a References: <message id> header that references the original mail’s Message-ID: <message-id>, and Zammad should hopefully be able to use that to put the reply into the correct ticket.

2 Likes
3

To further elaborate, this is my exact setup:

  • My accounting software sends emails as buchhaltung@domain.com
  • My newsletter software sends emails as post@domain.com
  • Both those email addresses (accounts) are monitored by Zammad, so incoming emails (and, of course, replies) will be fetched by Zammad
  • If a customer replies to an email sent by one of those 3rd party applications, Zammad creates a new ticket instead

Yes, I am aware of the fact that in the outgoing emails there’s no ticket# (because they’re not sent via Zammad itself)—but I was hoping that the ‘Additional follow-up detection’ could handle that.

Looking forward to your thoughts!

4

I have, but it doesn’t seem to work (or I’m not understanding correctly).

5

Hm, not sure why it wouldn’t work. I used it during testing when I piped ~50000 old mails into Zammad, and back then it worked, so it’s not broken in general.

Have a look at the raw mails and determine the Message-Id of the original mail. Does the response contain headers like References and In-Reply-To with this Message ID?

6

If there’s already a identical subject for the same user (and here’s the sending “from” relevant) then this will work. If you send from a Zammad-Alias, this will not work if you don’t give Zammad e.g. a Ticket-Number. Zammad simply can’t identify the customer, because in the classical thinking it would be it’s own customer in that case.

7

I really hope you guys can work out a solution to this issue. I think a lot of people have the need to send out things like newsletters or invoices and want to have them stored in Zammad so they can easily handle follow-ups from customers.

I haven’t found an alternative solution yet. (Except for heavy usage of the API, maybe.)

8

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

10

Ah, I see. In my case(s) the ‘froms’ would be different: I’m using accounting@ to send the e-mails from within my accounting software—but the customer’s reply (of course) comes from their respective e-mail-address.

Is there any way to make this work (yet)?

11

No, not really sorry.
I doubt this will ever be possible.

Reason for this is that you’re missing references to the ticket you’ve created. Zammad won’t be able to recognize it as a follow up.

12

What about the answer from @martin.von.wittich?

13

My bad.
You might want to check the Settings area of your mail channels.
https://admin-docs.zammad.org/en/latest/channels/email/settings.html

You’re looking for “additional follow-up detection”.

14

All checked—still doesn’t work. Is there any log file that could help me understand how e-mails are treated? Or maybe @martin.von.wittich can elaborate on this?

15

Beside of production.log there’s no further logfiles Zammad does write that would come in handy here.
Sounds like references from your customers are removed which could be a root cause.

Other wise Zammad would follow up automatically.
Well… except we’re talking about closed tickets and decided to configure your group to deny follow ups to closed tickets. :slight_smile:

16

I finally had the time to work on that issue again. production.log unfortunately doesn’t seem to help in this case, but I’ve found something interesting when looking at the headers @martin.von.wittich mentioned:

The first message (which has been sent via our newsletter software, BCC’ed to an e-mail address/mailbox monitored by Zammad) has a slightly different Message-id than the second e-mail (answer from customer to e-mail address/mailbox monitored by Zammad) shows in the References header.

Message-id: <shmw5_bftcms5mbjvvdldq.2977275291@domain.de>
References: <shmw5_bftcms5mbjvvdldq.2977275290@domain.de>

Is that just a coincidence or could there be a problem within the parsing functions?

17

This leads me to believe that the 3rd party software is at fault here. What it should be doing:

  • Generate a single message with a unique Message-Id
  • Send out an exact copy of this message to each and every recipient, including your Zammad instance and the customer

What it seems to be doing instead:

  • Generate several copies of the message, each with a different Message-Id
  • Send each recipient his own copy of the message

Now your Zammad instance receives a message with the Message-Id “A”, your customer receives a message with the Message-Id “B”, and when your customer replies, his mail user agent puts a References: B header into the mail. From your Zammad instance’s point of view, these are two completely different messages because they have different IDs, and therefor the reply is not appended to the existing ticket.

18

In my opinion it’s absolutely legit and valid to generate a different message id for bcc’ed mails.

Reason for this:
If I sent a BCC I technically want to ensure that the communication with that person does run

  • under the hood for others
  • theoretically shouldn’t be the same discussion tree

Other wise this would also be an issue within Zammad in “usual” cases where the bcc recipient answers and theoretically could create a follow up in the “correct” ticket. This would draw bcc useless, because persons being able to login to Zammad and viewing this ticket will then see that something is “odd”.

There may be use cases where this is wanted, personally I’d see this as an edge case.

19

Do you know if there’s a ‘standard’ when it comes to how a 3rd party software should behave? I just tested how my newsletter software behaves, and it seems to do the same (with CC and BCC, as well).

20

No; as far as I can tell, the relevant standards (RFC5322 Internet Message Format and RFC5321 Simple Mail Transfer Protocol) don’t really specify on how BCC and Message-ID are supposed to work together.

RFC5322 says about Message-ID:

The “Message-ID:” field provides a unique message identifier that refers to a particular version of a particular message. […]
In all cases, it is the meaning that the sender of the message wishes to convey (i.e., whether this is the same message or a different message) that determines whether or not the “Message-ID:” field changes, not any particular syntactic difference that appears (or does not appear) in the message. […]

So if the 3rd party software sends exactly the same message to multiple recipients, I would argue that it is supposed to use the same Message-ID for these mails. If it sends different messages to different recipients (e.g. because it changes the salutation or something like that), it is supposed to use different Message-IDs for these mails.

Even though the standard doesn’t explicitly say, I believe that the correct behavior is derivable from the “spirit” of the email standards:

  1. The standards are clearly influenced by real-life mail concepts in that they differentiate between the envelope and the contents:
    • The envelope is represented by the information that is being transmitted via SMTP, outside of the message itself.
    • The contents are represendet by the message itself, ie. headers + body.
  2. In real-life, a blind carbon copy was made by putting a sheet of carbon paper between two sheets of paper, and typing your message on the top paper, and not mentioning the BCC recipient in the message (contrary to CC where you would mention the CC recipient in the message). So to sum it up: BCC produces several identical messages. The different recipients only come into play when putting these identical copies into different envelope, one for each recipient.
  3. Back in email, this works the same way - you create identical copies (headers + body) of the same message, and the recipients (and therefor BCC) only matter in the envelope (SMTP). And RFC5322 says very clearly that identical messages should have an identical Message-ID.