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