If ticket gets created via e-mail, Zammad creates accounts for all people on To: and CC (GDPR Question)

Technical assistance
1

Moved conversation to the board to keep the issues clean until resolved:
Source:

Infos:

  • Used Zammad version: 2.6.x
  • Installation method (source, package, …): package
  • Operating system: Debian 9
  • Database + version: x
  • Elasticsearch version: x
  • Browser + version: x

Expected behavior:

  • When a customer opens a ticket by writing to the set up ticket e-mail only the FROM: entry should create a Zammad user.

Actual behavior:

  • Zammad creates user profiles for all people on CC: and TO: as well
  • This is a major red flag considering the current GDPR laws as none of the people on CC: TO: have agreed to the company’s privacy policy and they are not getting informed (in the default zammad trigger setting) that a user account has been created.

Steps to reproduce the behavior:

  • Set up any ticket mail in Zammad
  • Use a external dummy customer from any mailhoster
  • Open ticket by writing to ticketmail@company.com and put other mailaccounts on CC: and TO: that have no Zammad useraccount yet

Yes I’m sure this is a bug and no feature request or a general question.

2

Hello Hannes,

to answer your question from GitHub (not sure if I should have answered there or here.)

Where do you see the difference to let’s say an Exchange server which stores an E-Mail? We do not store any other information related to this.
Why do you see the consent on the side of the receiver and not on the side of the sender?

The difference is the extra step that Zammad does which creates automatically Useraccounts on Zammad without consent from the other people on CC: and TO: that did not consent to that automatic processing of personal data.

I am no lawyer so I can only argue on my oversimplified understand of the GDPR but in short all automatic data processes of personal data without the consent of the person in question is forbidden.
One of the exceptions is if the data processing and collection is needed for a certain process e.g. customer communication, billing etc… So if a customer writes to your e-mail address from your website to get a quote or similar they are “indirectly” consenting, that their e-mail and data may be used for the follow up process. The only thing to watch out for in that case is e-mail archiving and length of storage, but that is another topic.

Now if someone puts others on TO: or CC: on such a e-mail it gets more complicated, in the worst case (lawsuit) the receiving company has to prove that the “indirect” consent was given by all other parties as that data processing was needed for purpose of working with the customer.
An article partially covering that topic can be found here, many others can be found in the web on sites of e-mail host services and law offices: GDPR - The Problem of Personal Data in Email an Backups

Now Zammad goes even a step further. Zammad grabs the potentially personal data from TO: and CC: and puts it automatically into yet another database.
One can easily argue that the FROM: customer wanted to interact with the company and thus the system used. But this argumentation gets quickly picked apart for people on TO: or CC:

Especially in the case that a Spammail writes to your supportmail that has multiple people on TO: or CC: (the actual major issue we stumbled across)
It should be quite clear that these people never had in mind to end up as an account in our Zammad installation, but due to the current settings they do without them ever knowing.

This combined with the lack of easy options to delete users from Zammad is a nightmare in regards of GDPR compliance (Not saying that I would be fond deleting all wrongly created users by the spammailer by hand).

The simplest fix I see for this is that only people that are specifically on FROM: get added to the system.
There is simply no need that people on CC: and others on TO: are already in the system.
Whoever wants to join into a ticketdiscussion will write an e-mail himself to the ticketmail under the correct Ticketnumber, with the fix Zammad will see that new person as FROM: and only add him etc.

Sorry for the wall of text but the matter is a bit more complicated to explain than I initially thought.

Best regards,
Nino

2 Likes
3

Hi Nino,

thanks for the input. I’ll take this and we will discuss this internal and with our DPO. Maybe we can add a config option for this. But I see some issues here regarding other users of Zammad, were the feature you don’t need is used heavily to keep track of discussions.

Even if we don’t sent an auto-reply we have “an E-Mail address” of someone who, maybe does not gave his consent, and store them in the mail headers and so in the ticket. It does not matter if it is firstname.lastname@domain.com or sunflower78@hotmail.co.uk
I see no silver bullet here to solve this. And those addresses might be important in the later process of a ticket. “Yes we sent him / her this E-Mail and there was a document attached to it”.

Your spam case is valid and will be partly solved when the deletion of users and tickets and all the good stuff is available in 2.8( or if any major regressions occur in 2.9.).

regards
Johannes

P.S.
The ontrack article is focused on sales and their interpretation of the subject. I read it earlier and I can say I am no fan. But I get your point.

4

Hi @Hannes,

I would agree to Nino.
It might be an issue from the GDPR perspective.

From my point of view, besides of GDPR, I could not see a use case for that behavior, so we often get annoyed by the maaaaaany accounts zammad creates.

Given I use zammad as an internal ticket system, sometimes to solve an issue I have to request additional information from the external software manufacturers.
To keep everything documented, I use zammad to request the needed information by mail.

Usually the guy of the external the software supplier setting one or more of his colleagues in CC when he replies to the request.

So zammad creates accounts for all of his colleagues he put in CC in his mail.

I have no idea why I should have these persons in zammad. They are not my customers and probably
I will never have any contact with them.
And even if I have to: I can see all CCs in the incoming mail in the ticket.

So for that use case creating an account for every CC in the mail is useless and creates a lot accounts that have to be deleted.

Maybe you could give us an idea, which use case you are thinking of, where you need the accounts for each mailaddress in CC???

Best regards
Gerhard

1 Like
5

Hi Hannes,

Thank you for your reply.
This weekend I got the chance to talk to an executing lawyer at the “Landesdatenschutzbeauftragte” NRW and her statement was, that this behaviour is definitely a red flag and would lead to further investigation and possibly prosecution if reported by e.g. a customer. This puts all hosters of Zammad in an unwanted position.

Their reasoning is as follows:
For the service hoster there is practically no possibility to prove that the people on TO: and CC: have consented to the automatic data processing of Zammad and creation of user accounts.
This is different for the FROM: user if the hosting service made sure that the associated e-mail address to use the ticket service was explicitly stating which privacy policy takes effect when writing to that address.

I hope this makes the severity of the issue clear as the above is the current definition the executing agency (for NRW at least) will follow. This might of course change in future but I am sure that no customer of Zammad would like to be the one to discuss this definition change in court.

For a second source I suggest you contact your local “Lanndesdatenschutzbeauftragte” as well. They are usually very helpful with data protection related inquiries and answer rather quickly for an government agency (i can only speak for NRW here).

Could you elaborate the use case here?
You can still choose to write people through Zammad directly that are on To: or CC: without the need to create user accounts for them.
The whole issue is about the user account that gets created automatically, the e-mail handling is not the issue here.

I agree, it was the first google link I found to the topic that “kinda” touched the subject. It was late and just before “Feierabend” on Friday, so please bear with me here :wink:

From my point of view I see the following options.

Workaround:
The option in Zammad to delete users automatically that have not opened any ticket.
This could be done e.g. with a scheduler job.

Solution:
“Simply” only create user accounts for the sender (person on FROM: on an e-mail).
This would kill of any GDPR issues in one hit.

Looking forward to the results of your internal discussion.

Best regards,
Nino

6

We started an internal discussion about “creating accounts from CC addresses” and will get back with a result later this week.
We need to check some technical dependencies first.
Things we discuss actually:

  • need for creating customers from CC addresses (config option?)
  • auto delete all customers related to spam tickets

Regarding the GDPR:
We cant agree on this. I think the Data Protection Commissioner of NRW might miss some points here, based upon the complexity of hosted vs. self hosted and who operates the system.

Here is the explanation of our DPO, which is also a lawyer specialised for such cases. Please be aware that there is always space left for interpretation until a court has ruled in a sample case.

A data controller is the person (company) that determines the purposes and means of the processing of personal data (like names, Email adresses).

In the contractual relationship between Zammad and its customers, the customer raises the personal data (PD) of their stakeholders (employees, business partners) and determines what Zammad should do with the data it sends to Zammad.

Hence, Zammads customer is the data controller and Zammad is the data processor. Zammad just deals with any data the data controller sends to Zammad, because Zammad is hired/used by the data controller to perform services which might involve the transfer of PD.

Under Art. 13 GDPR the data controller has a duty to inform the people it raises PD from (its stakeholders), about all the relevant information concerning the processing activities.
In easy words, the data controller has to tell ist stakeholders, what PD it raises, why, what it is used for, and where it will be transferred to.

Therefore, even if a Zammad Customer (data controller) sends PD of its customers to you (via cc or however), the duty to inform about this lies with the data controller in accordance with Art 13,14 GDPR. The data controller who raised the PD has the duty to inform its customers about the possible receipients of the PD (for instance by informing through its Privacy Policy). Zammad is the data processor in this contractual agreement. It just processes PD the data controller has originaly raised.

Sure. Some users use Zammad like a small CRM. They auto assign companies and users to get an overview who they are talking to. They add information to the contacts and contact them later. Also the Zammad autocomplete feature only use “accounts”. Which some of our customers use heavily (even for CC Customers).

regards
Johannes

7

Hi Hannes,

Thank you for your quick reply.

Quite possible, it was just a quick oral discussion we had where I presented an example case without naming any names or services or technical background.

I totally understand your argumentation here and I never meant to point fingers on you as the provider of the software. As you wrote, the one responsible is the data controller hence anyone running a Zammad installation.
But the current tools given to the Zammad hosters/customers are rather limited to fulfill the rules set up by the GDPR.
e.g. the only way I currently see dealing with this as the data controller is to set up auto mail reply triggers to any user account that gets created (which by my understanding of the GDPR is already to late as you should have informed the user about the data processing beforehand, not after creating his account).
Anyways, in the case of the Spammails it would mean risking being associated with known spam e-mail senders which can lead to critical unwanted side effects in regards to e-mail sending and IP reputation.

OK, point taken.

To make sure I understood you correctly here is what I took from the discussion so far:

  • Creating users for incoming mails from people on TO: and CC: is OK under GDPR if the Zammad customer/hoster informs the people in question about the data processing in some way (beforehand?).
  • The Zammad team is currently working/discussing on implementing tools so the Zammad customer/hoster has the necessary tools to cope with the GDPR law

Are these two points correct?

Best regards,
Nino

8

Exactly, these two are correct

9

Hi Hannes,

Thank you for confirmation.
Looking forward for your solution.

Best regards,
Nino

10

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