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.
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.
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.
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?
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.
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.)
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.
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?
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.
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.
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.
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.
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).
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:
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.
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.
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.