feature-request: make received-header on submission optional or at least drop the ip in it
hi.
we're just trying to re-structure a system and want to use dovcots submission-ability. because the github-repository have no entry for any issues at all, we're sending this feature-fequest to this ML.
unfortunately there doesn't seem to be any option to drop the received-header at all or at least hide the IP of the user.
because the client-ip is covered by GDPR as personal data and so it should never shown to others without a certain reason, we want to hide it, but there's no "submission_add_received_header"-option like for lmtp and it doesn't seem to be any other option to hide this information.
maybe this is possible to implement in near future?
thanks a lot.
best regards
d.
On 2022-01-01 11:04 a.m., dc-ml@dvl.werbittewas.de wrote:
because the client-ip is covered by GDPR as personal data and so it should never shown to others without a certain reason, we want to hide it, but there's no "submission_add_received_header"-option like for lmtp and it doesn't seem to be any other option to hide this information.
Using your email system IS the reason, simply make sure that you inform customers why this is presented. The world will thank you ;)
Sorry, but while an IP has been described as personal data in various privacy legislation, just like to stop the spreading of misinformation that you 'cannot' include that information.
You can include personal information, as long as the person is aware (SLA, Terms and Conditions etc) and it has a valid use, eg for security purposes.
Oh, but no flames please, this is almost getting off topic as it is.
Am 03.01.22 um 15:47 schrieb Michael Peddemors:
Using your email system IS the reason, simply make sure that you inform
no, it's not.
and:
(SLA, Terms and Conditions etc) and it has a valid use, eg for security purposes.
for security_reasons it's completly ok, to store this information *locally* on the server for some time, but not to push this information together with date+time towards the world.
sorry, if you don't have an idea of privacy-needs, you should not post about this topic and then say something about "no flames please"...
Oh, but no flames please, this is almost getting off topic as it is.
well, then let's come back to the origin topic.
There's an need for it (as I noticed meanwhile at least back to 2019: https://dovecot.org/pipermail/dovecot/2019-August/116865.html ) and until it breaks no existing thing (which is expected due to *optional* settings ), there's no reason to discuss about that need itself.
( You won't be forced to enable it for Your mail-server )
@others: due to the importance of it for us, I'm currently trying to implement it, but because that's my first deeper view in dovecots code, maybe I'll need some help.
d.
@others: due to the importance of it for us, I'm currently trying to implement it, but because that's my first deeper view in dovecots code, maybe I'll need some help.
okay, perhaps I've a solution for this.
because we're using standard-distribution-pkgs, we're checked it with that version (devuan chimaera/debian bullseye) and it works as expected.
The port to the currently available version 2.3.17.1 was simple, because only the Macro "DEF(SET_BOOL, ..." has changed to "DEF(BOOL, ..." between that versions, but we only have tested the compilation of this version.
because until now I've never really worked with git, I've no possibility to follow that way for integration. Independently from this maybe you won't like the changes and won't integrate them at all.
======================================================================
- added an corresponding option to "lmtp_add_received_header" named
"submission_add_received_header"
added options "lmtp_add_rcvd_from" and "submission_add_rcvd_from"
added another arg to smtp_server_transaction_write_trace_record() to
handle the "*rcvd_from"-flags
- beautified the header-construction within
smtp_server_transaction_write_trace_record() a little bit
- added the options to default-config. (unset default is always keeping
old behaviour)
the patch for 2.3.17.1 is attached.
please let me know, if you're integrating it, because then I'll send the patch for the old version to the devuan/debian-maintainers for integration, so that we can update normally again.
regards
d.
Hi,
Am 03.01.2022 um 20:08 schrieb dc-ml@dvl.werbittewas.de:
@others: due to the importance of it for us, I'm currently trying to implement it, but because that's my first deeper view in dovecots code, maybe I'll need some help.
the patch for 2.3.17.1 is attached.
please let me know, if you're integrating it, because then I'll send the patch for the old version to the devuan/debian-maintainers for integration, so that we can update normally again.
Thanks for implementing a patch to be more privacy-aware!
In Postfix many privacy-friendly submission servers do the following:
======================================= header_checks = pcre:/etc/postfix/header_checks ======================================= /^Received: from .*? ([\w-.]* [.*?])(.*)/ REPLACE Received: from [127.0.0.1] (localhost [127.0.0.1])$1 /^User-Agent:/ IGNORE /^X-Enigmail:/ IGNORE /^X-Mailer:/ IGNORE /^X-Originating-IP:/ IGNORE /^X-PHP-Originating-Script:/ IGNORE =======================================
The Received-Header is still there, so you can see the receiving server and the date+time of the server, but the IP address has been anonymized by replacing it with 127.0.0.1, so the format of the Received:-line is still valid for parsers.
And some fingerprintable headers have been removed, because an "X-Mailer" or "User-Agent" could tell the recipients if you are at work or at home for example, or they could learn that you use an outdated vulnerable MUA... It would be cool if the Dovecot-submission-server would also be able to remove headers like the ones above (or for example "X-Authenticated" which sometimes contains IP addresses or auth-usernames...).
Michael
Am 05.01.22 um 17:23 schrieb Michael Kliewe:
In Postfix many privacy-friendly submission servers do the following:
[...]
nice feature, unfortunately we're currently not using postfix, because none here has enough experience with it. maybe later...
but:
The Received-Header is still there, so you can see the receiving server
for this the patch offers the option to simply drop the "by X.X.X.X" but not the whole header itself. Because for lmtp there already was an option to remove the complete header, this was also implemented for submission.
(we know that information about the accepting system/software might be useful for debugging problems)
d.
MUA/browser based things are not considered be in scope for GDPR unless they are truly unique. So you do NOT need to hide user-agent/MUA for privacy reasons.
Received lines is only applicable (in scope for GDPR) if they identify the end user. A good solution to this would be to just scrap every received-line EXCEPT for the received line *immediately* before receiving the mail (which will be the remote server connecting). This will guaranteed protect against mail providers that DO insert their end user IP or client IP as a Received line.
Example:
If 123.222.123.222 connects to us and sends an email, and you have the following received lines:
Received: from 127.0.0.1 (localfw-mailscanner) bablabla Received: from 23.34.56.33 (spamscanner.someservice.com) blablabla Received: from 123.222.123.222 (remote.mailserver.com) blablabla Received: from 99.99.99.99 (somecustomer.someisp.com) blabla Received: from 192.168.1.100 (somerouter.atsomecustomer.local) blabla
Then you scrap the 2 earliest, so you are left with:
Received: from 127.0.0.1 (localfw-mailscanner) bablabla Received: from 23.34.56.33 (spamscanner.someservice.com) blablabla Received: from 123.222.123.222 (remote.mailserver.com) blablabla
For X-PHP-Originating-Script I don't think you need to hide that unless it contains the IP of the web user submitting the form. Same applies here, if someone sets up a server, they have automatically consented to the processing of personal details, since they publish things.
-----Ursprungligt meddelande----- Från: dovecot-bounces@dovecot.org dovecot-bounces@dovecot.org För Michael Kliewe Skickat: den 5 januari 2022 17:25 Till: dovecot@dovecot.org Ämne: Re: patch: make received-header on submission optional or optionally drop the from-part in it
Hi,
Am 03.01.2022 um 20:08 schrieb dc-ml@dvl.werbittewas.de:
@others: due to the importance of it for us, I'm currently trying to implement it, but because that's my first deeper view in dovecots code, maybe I'll need some help.
the patch for 2.3.17.1 is attached.
please let me know, if you're integrating it, because then I'll send the patch for the old version to the devuan/debian-maintainers for integration, so that we can update normally again.
Thanks for implementing a patch to be more privacy-aware!
In Postfix many privacy-friendly submission servers do the following:
======================================= header_checks = pcre:/etc/postfix/header_checks ======================================= /^Received: from .*? ([\w-.]* [.*?])(.*)/ REPLACE Received: from [127.0.0.1] (localhost [127.0.0.1])$1 /^User-Agent:/ IGNORE /^X-Enigmail:/ IGNORE /^X-Mailer:/ IGNORE /^X-Originating-IP:/ IGNORE /^X-PHP-Originating-Script:/ IGNORE =======================================
The Received-Header is still there, so you can see the receiving server and the date+time of the server, but the IP address has been anonymized by replacing it with 127.0.0.1, so the format of the Received:-line is still valid for parsers.
And some fingerprintable headers have been removed, because an "X-Mailer" or "User-Agent" could tell the recipients if you are at work or at home for example, or they could learn that you use an outdated vulnerable MUA... It would be cool if the Dovecot-submission-server would also be able to remove headers like the ones above (or for example "X-Authenticated" which sometimes contains IP addresses or auth-usernames...).
Michael
Bad recommendation, it WILL affect delivery if you start removing trace fields.. (and not going to talk GDPR on list further ;)
On 2022-01-05 10:27 a.m., Sebastian Nielsen wrote:
MUA/browser based things are not considered be in scope for GDPR unless they are truly unique. So you do NOT need to hide user-agent/MUA for privacy reasons.
Received lines is only applicable (in scope for GDPR) if they identify the end user. A good solution to this would be to just scrap every received-line EXCEPT for the received line *immediately* before receiving the mail (which will be the remote server connecting). This will guaranteed protect against mail providers that DO insert their end user IP or client IP as a Received line.
Example:
If 123.222.123.222 connects to us and sends an email, and you have the following received lines:
Received: from 127.0.0.1 (localfw-mailscanner) bablabla Received: from 23.34.56.33 (spamscanner.someservice.com) blablabla Received: from 123.222.123.222 (remote.mailserver.com) blablabla Received: from 99.99.99.99 (somecustomer.someisp.com) blabla Received: from 192.168.1.100 (somerouter.atsomecustomer.local) blabla
Then you scrap the 2 earliest, so you are left with:
Received: from 127.0.0.1 (localfw-mailscanner) bablabla Received: from 23.34.56.33 (spamscanner.someservice.com) blablabla Received: from 123.222.123.222 (remote.mailserver.com) blablabla
For X-PHP-Originating-Script I don't think you need to hide that unless it contains the IP of the web user submitting the form. Same applies here, if someone sets up a server, they have automatically consented to the processing of personal details, since they publish things.
-----Ursprungligt meddelande----- Från: dovecot-bounces@dovecot.org dovecot-bounces@dovecot.org För Michael Kliewe Skickat: den 5 januari 2022 17:25 Till: dovecot@dovecot.org Ämne: Re: patch: make received-header on submission optional or optionally drop the from-part in it
Hi,
Am 03.01.2022 um 20:08 schrieb dc-ml@dvl.werbittewas.de:
@others: due to the importance of it for us, I'm currently trying to implement it, but because that's my first deeper view in dovecots code, maybe I'll need some help.
the patch for 2.3.17.1 is attached.
please let me know, if you're integrating it, because then I'll send the patch for the old version to the devuan/debian-maintainers for integration, so that we can update normally again.
Thanks for implementing a patch to be more privacy-aware!
In Postfix many privacy-friendly submission servers do the following:
======================================= header_checks = pcre:/etc/postfix/header_checks ======================================= /^Received: from .*? ([\w-.]* [.*?])(.*)/ REPLACE Received: from [127.0.0.1] (localhost [127.0.0.1])$1 /^User-Agent:/ IGNORE /^X-Enigmail:/ IGNORE /^X-Mailer:/ IGNORE /^X-Originating-IP:/ IGNORE /^X-PHP-Originating-Script:/ IGNORE =======================================
The Received-Header is still there, so you can see the receiving server and the date+time of the server, but the IP address has been anonymized by replacing it with 127.0.0.1, so the format of the Received:-line is still valid for parsers.
And some fingerprintable headers have been removed, because an "X-Mailer" or "User-Agent" could tell the recipients if you are at work or at home for example, or they could learn that you use an outdated vulnerable MUA... It would be cool if the Dovecot-submission-server would also be able to remove headers like the ones above (or for example "X-Authenticated" which sometimes contains IP addresses or auth-usernames...).
Michael
On 03/01/2022 17:15 dc-ml@dvl.werbittewas.de wrote:
Am 03.01.22 um 15:47 schrieb Michael Peddemors:
Using your email system IS the reason, simply make sure that you inform
no, it's not.
and:
(SLA, Terms and Conditions etc) and it has a valid use, eg for security purposes.
for security_reasons it's completly ok, to store this information *locally* on the server for some time, but not to push this information together with date+time towards the world.
sorry, if you don't have an idea of privacy-needs, you should not post about this topic and then say something about "no flames please"...
Oh, but no flames please, this is almost getting off topic as it is.
well, then let's come back to the origin topic.
There's an need for it (as I noticed meanwhile at least back to 2019: https://dovecot.org/pipermail/dovecot/2019-August/116865.html ) and until it breaks no existing thing (which is expected due to *optional* settings ), there's no reason to discuss about that need itself.
( You won't be forced to enable it for Your mail-server )
@others: due to the importance of it for us, I'm currently trying to implement it, but because that's my first deeper view in dovecots code, maybe I'll need some help.
d.
Hi!
We'll take a look at your patch. Can you please point out to some legal information about the Received header's GDPR incompliance, I would be interested to see it.
Aki
Am 04.01.22 um 08:39 schrieb Aki Tuomi:
We'll take a look at your patch. Can you please point out to some legal information about the Received header's GDPR incompliance, I would be interested to see it.
thanks for doing so.
the GDPR says about personal data:
- that only really needed data has to be stored
- that this data has to be used only for that declared needs
- that any other usage has to be prevented, especially by third-parties
the EuGH has judged in 2016 (Patrick Breyer vs. Germany, C-582/14), that an IP-addresses can be personal data, because the person may be identified via this IP, so they have to be handled as such.
http://curia.europa.eu/juris/documents.jsf?num=C-582/14
therefore the possibility, that others may for example see when a person was at a place (connected to an IP) has to be prevented at least in europe.
if such information is published for people with high email-activity, then it would be possible for everyone, who has access to this email (which might be really everyone on earth for example in archived mailing-lists) to track these people over the whole time.
for security-reasons we're logging any submission-request together with the origin-IP in our logs for at least seven days. so any mis-use of our service may be prosecuted even without storing this information in every email. In germany some courts judged, that if the police asks us for the IP, we've to store the log-entry at least as long, as a court needs to judge, that we have to give it to the police. (I think this is a reasonable balance between protection of personal data and legitimate public interest)
if there are further questions to this topic I'll try to reply, but you should know, that my english isn't that good, especially to explain juridicial things...
regards
d.
On 05/01/2022 14:41, dc-ml@dvl.werbittewas.de wrote:
Am 04.01.22 um 08:39 schrieb Aki Tuomi:
We'll take a look at your patch. Can you please point out to some legal information about the Received header's GDPR incompliance, I would be interested to see it.
thanks for doing so.
the GDPR says about personal data:
- that only really needed data has to be stored
- that this data has to be used only for that declared needs
- that any other usage has to be prevented, especially by third-parties
the EuGH has judged in 2016 (Patrick Breyer vs. Germany, C-582/14), that an IP-addresses can be personal data, because the person may be identified via this IP, so they have to be handled as such.
http://curia.europa.eu/juris/documents.jsf?num=C-582/14
therefore the possibility, that others may for example see when a person was at a place (connected to an IP) has to be prevented at least in europe.
if such information is published for people with high email-activity, then it would be possible for everyone, who has access to this email (which might be really everyone on earth for example in archived mailing-lists) to track these people over the whole time.
for security-reasons we're logging any submission-request together with the origin-IP in our logs for at least seven days. so any mis-use of our service may be prosecuted even without storing this information in every email. In germany some courts judged, that if the police asks us for the IP, we've to store the log-entry at least as long, as a court needs to judge, that we have to give it to the police. (I think this is a reasonable balance between protection of personal data and legitimate public interest)
if there are further questions to this topic I'll try to reply, but you should know, that my english isn't that good, especially to explain juridicial things...
regards
d.
Hi
the safest non technical approach is to request that your users consent to the processing of the data. The dynamic ip address is however personal data in a very limited sense ( i.e. where the service provider can link the dynamic ip address to other information that then identifies the individual). Where people are sending email to public mailing lists, there is no presumption of privacy.
John
Where people are sending email to public mailing lists, there is no presumption of privacy.
I think the legislation is like this: the privacy is legislation is always applicable, there are no conditions under which there is 'no presumption of privacy'
On 05/01/2022 17:44, Marc wrote:
Where people are sending email to public mailing lists, there is no presumption of privacy.
I think the legislation is like this: the privacy is legislation is always applicable, there are no conditions under which there is 'no presumption of privacy'
Marc
my understanding of the GDPR legislation is that it defines what is considered lawful processing. One of those items that makes the processing lawful is consent. If I send an email to a public mailing list I think it's fair to say that I am providing consent. I was not suggesting that the legislation does not apply.
John
Am 05.01.22 um 18:00 schrieb John Fawcett:
my understanding of the GDPR legislation is that it defines what is considered lawful processing. One of those items that makes the processing lawful is consent. If I send an email to a public mailing list I think it's fair to say that I am providing consent. I was not
sorry, you're wrong.
have a look at the given link to the EUGH-judgement.
it's irrelevant if someone acts in private or public area.
peoples privacy rights always exists and may only violated, if there's really no other possibility to fulfil higher rights
and:
think about whistleblowers or dissidents in autotcratic regimes: maybe they send mails from the same place, where they do their important work for society. Even if they change their IP between, their location may be traced in detail.
and don't forget: no one here will force you, to change your handling with your users privacy-data. but some of us want to have the possibility to change it. So why you're aguing here, what's your aim?
if there are technical issues with the patch - ok if it brings more complexity in the further development (which I don't think due its simplicity) - ok
but I think that interpretation of the GDPR is neither on-topic here, nor may lead to any kind of consensus, since even in Europe there're still enough people, who think, that's not useful.
d.
On 05/01/2022 18:27, dc-ml@dvl.werbittewas.de wrote:
Am 05.01.22 um 18:00 schrieb John Fawcett:
my understanding of the GDPR legislation is that it defines what is considered lawful processing. One of those items that makes the processing lawful is consent. If I send an email to a public mailing list I think it's fair to say that I am providing consent. I was not
sorry, you're wrong.
have a look at the given link to the EUGH-judgement.
it's irrelevant if someone acts in private or public area.
peoples privacy rights always exists and may only violated, if there's really no other possibility to fulfil higher rights
I did look at it and my answer was based partly on what I read there. This is more of a technical mailing list so I'll avoid commenting here further, other than to say that I think you're reading things into the judgement and the GDPR legislation that go beyond what the legislation requires.
and:
think about whistleblowers or dissidents in autotcratic regimes: maybe they send mails from the same place, where they do their important work for society. Even if they change their IP between, their location may be traced in detail.
I think this is getting way off topic for this list. I would sincerely hope that people in these circumstances would trust to more robust privacy mechanisms than the one in discussion.
and don't forget: no one here will force you, to change your handling with your users privacy-data. but some of us want to have the possibility to change it. So why you're aguing here, what's your aim?
I have nothing against the proposed patch. I was just suggesting other ways that the GDPR legislation requirements may be met.
if there are technical issues with the patch - ok if it brings more complexity in the further development (which I don't think due its simplicity) - ok
but I think that interpretation of the GDPR is neither on-topic here, nor may lead to any kind of consensus,
I can only agree!
since even in Europe there're still enough people, who think, that's not useful.
If this phrase is related to my posts, you're reading things I didn't say, mean, mean to imply or even think.
d.
John
On Wed, Jan 05, 2022 at 06:00:31PM +0100, John Fawcett wrote:
my understanding of the GDPR legislation is that it defines what is considered lawful processing. One of those items that makes the processing lawful is consent.
Not necessarily.
An action that would not be lawful without consent is not automatically made lawful with consent, including under GDPR.
If I send an email to a public mailing list I think it's fair to say that I am providing consent.
Again, not necessarily.
First of all, consent cannot necessarily be assumed.
Secondly, a person sending an email to a mailing list might very well consent for the mailing list's recipients to receive the content, subject, and reply address of that email - but *not* the IP address from which it was sent.
Sam
On 05/01/2022 18:36, Sam Kuper wrote:
On Wed, Jan 05, 2022 at 06:00:31PM +0100, John Fawcett wrote:
my understanding of the GDPR legislation is that it defines what is considered lawful processing. One of those items that makes the processing lawful is consent.
Not necessarily.
An action that would not be lawful without consent is not automatically made lawful with consent, including under GDPR.
Correct there could be other reasons that make processing unlawful. However, GDPR will allow processing if the data subject consents and I think taht is what we are talking about in this thread.
If I send an email to a public mailing list I think it's fair to say that I am providing consent.
Again, not necessarily.
First of all, consent cannot necessarily be assumed.
Correct that it cannot necessarily be assumed. But in this case I think it would be fair to assume it when someone sends an email to a public mailing list that consent has been given. I cannot see how having sent an email to a public mailing list I can then object to people processing it. Although it's not a question about GDPR, if I DID then change my mind, I cannot see a technical way to enforce it.
Secondly, a person sending an email to a mailing list might very well consent for the mailing list's recipients to receive the content, subject, and reply address of that email - but *not* the IP address from which it was sent.
Correct. That is why I mentioned as an alternative "request that your users consent to the processing of the data".
Sam
On Wed, Jan 05, 2022 at 07:00:19PM +0100, John Fawcett wrote:
On 05/01/2022 18:36, Sam Kuper wrote:
On Wed, Jan 05, 2022 at 06:00:31PM +0100, John Fawcett wrote:
my understanding of the GDPR legislation is that it defines what is considered lawful processing. One of those items that makes the processing lawful is consent.
Not necessarily.
An action that would not be lawful without consent is not automatically made lawful with consent, including under GDPR.
Correct there could be other reasons that make processing unlawful.
Indeed.
However, GDPR will allow processing if the data subject consents [..]
Not necessarily. The consent must meet four tests before it is valid for GDPR purposes. It must be:
freely given,
specific,
informed, and
unambiguous.
See https://gdpr.eu/gdpr-consent-requirements/
If I send an email to a public mailing list I think it's fair to say that I am providing consent.
Again, not necessarily.
First of all, consent cannot necessarily be assumed.
Correct that it cannot necessarily be assumed. But in this case I think it would be fair to assume it when someone sends an email to a public mailing list that consent has been given. I cannot see how having sent an email to a public mailing list I can then object to people processing it. [..]
You say you cannot see it, but I gave an example below, in my previous email:
Secondly, a person sending an email to a mailing list might very well consent for the mailing list's recipients to receive the content, subject, and reply address of that email - but *not* the IP address from which it was sent.
Correct. That is why I mentioned as an alternative "request that your users consent to the processing of the data".
The IP address is a different kind of datum to the content, subject, and reply address.
For instance:
The IP address is likely to allow the user's location (city or region) to be inferred, in a manner typically outside the user's control. As such, disseminating the IP address unnecessarily would reduce the user's privacy.
The sender of an email is likely to be aware of the content, subject, and sender address of an email that they send, because MUA UIs typically make this clear. But many (most?) email users don't know what IP addresses are or what can be inferred from them, and so *cannot* (without being provided with a clear explanation) give informed consent about divulging their IP addresses unnecessarily.
So, unless a service provider obtains user consents meeting the four tests above, in respect of *each kind* of datum they intend to process, then the service provider would on the face of it be in breach of the GDPR in respect of that kind of datum.
In particular, the "freely given" consent means that provision of a service, etc, should not be contingent upon consent. I.e. if it is not *necessary* (which it isn't, by definition) for some kind of datum (e.g. users' IP addresses) to be disseminated more widely than necessary, then a service provider cannot validly under the GDPR require a user to consent to such dissemination in order to receive the service. Such contingency would render the consent not freely given.
Sam
On 07/01/2022 14:01, Sam Kuper wrote:
You say you cannot see it, but I gave an example below, in my previous email:
Secondly, a person sending an email to a mailing list might very well consent for the mailing list's recipients to receive the content, subject, and reply address of that email - but *not* the IP address from which it was sent.
Your example was clear. I was replying about "assumed consent". In the case that I send an email to a public mailing list I don't think you would need to get explicit consent (for processing the email contents). That you're not necessarily consenting to the diffusion of the ip address by sending the email is clear.
The IP address is a different kind of datum to the content, subject, and reply address.
For instance:
The IP address is likely to allow the user's location (city or region) to be inferred, in a manner typically outside the user's control. As such, disseminating the IP address unnecessarily would reduce the user's privacy.
The sender of an email is likely to be aware of the content, subject, and sender address of an email that they send, because MUA UIs typically make this clear. But many (most?) email users don't know what IP addresses are or what can be inferred from them, and so *cannot* (without being provided with a clear explanation) give informed consent about divulging their IP addresses unnecessarily.
So, unless a service provider obtains user consents meeting the four tests above, in respect of *each kind* of datum they intend to process, then the service provider would on the face of it be in breach of the GDPR in respect of that kind of datum.
In particular, the "freely given" consent means that provision of a service, etc, should not be contingent upon consent. I.e. if it is not *necessary* (which it isn't, by definition) for some kind of datum (e.g. users' IP addresses) to be disseminated more widely than necessary, then a service provider cannot validly under the GDPR require a user to consent to such dissemination in order to receive the service. Such contingency would render the consent not freely given.
Sam
Yes, I stand corrected. Consent would not be a solution. You'd still need a way of NOT sending the ip if consent was not given and if that way did not exist, consent would not be freely given, even for those that give it.
So only lawful processing category that potentially could remain feasible I think is legitimate interest (i.e. email headers can generally be expected to contain ip info, potentially useful for spam prevention) but given that the info is available in log files, it would be hard to argue that the inclusion in the email header is legitimate when compared to rights of data subject.
So indeed the safest thing is to remove originating ips from headers, so as not to be on wrong side of GDPR legislation.
John
participants (8)
-
Aki Tuomi
-
dc-ml＠dvl.werbittewas.de
-
John Fawcett
-
Marc
-
Michael Kliewe
-
Michael Peddemors
-
Sam Kuper
-
Sebastian Nielsen