Re: [mailop] GDPR and SMTP in general

[SM]

Hi Paul,
At 03:40 AM 25-05-2018, Paul Smith wrote:
I wish that was the case, but it's not what GDPR says, certainly for 
SMTP relay services


The organization running the service would be the "processor".  Did 
you ask the ICO whether there is any guidance for a SMTP service?


Regards,
-sm 



___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] GDPR and SMTP in general

[Large Hadron Collider]

I suspect in practice they are going to DTRT and only enforce against 
violations of the spirit.



On 05/25/2018 10:14, Rolf E. Sonneveld wrote:

Hi, Paul,

On 25-05-18 11:46, Paul Smith wrote:
I've been going through some GDPR stuff. Amongst other things, we 
provide SMTP relay services to some customers, so are a 'Data 
Processor' under GDPR. In itself, that's OK as our own operations are 
GDPR compliant.


But, how it interacts with email, it all seems to get very horrible. 
I suspect the *intention* is OK, but I'm struggling with the actual 
regulations.


If someone sends a message from the UK to someone in the USA, by 
definition, we must send that email outside of the EU. When we send 
the email, we are sending personal data (eg usually the name/email 
address of the sender never mind the content which could be anything 
(outside our control)). That causes issues for GDPR.


When we send the outgoing message to another mail server, that other 
server's operator is also a Data Processor. According to Article 28 
of GDPR, we have to get prior approval of the Data Controller before 
using them, and a responsibility to check that they are GDPR 
compliant. Obviously that isn't going to happen in any feasible way...


Then there's the question about whether Internet connectivity/Wifi 
hotspt providers are also Data Processors as they potentially have 
access to the message data (including personal data) and could be 
classed as 'processing' it.


Also, if a user is on holiday in the USA and downloads email to their 
phone or in an Internet cafe, we are 'sending it outside the EU', so 
again, GDPR has issues.



I thought it was all OK, but one of our customers asked us to sign a 
contract for GDPR which prevents us from sending data outside of the 
UK and from sending it to any other companies without prior written 
permission. I've pointed out the problems to them, but wondered if 
anyone else had come across this.


Yes, dealing with exactly the same kind of problem(s). One of my 
customers asks me to sign for the fact that mail is encrypted when 
handling it. However, using standard MTA software, messages that are 
in the queue waiting to get delivered, are unencrypted. Am I forced to 
use disk encryption?


/rolf


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop



___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] GDPR and SMTP in general

[Grant Taylor via mailop]

On 05/25/2018 04:49 AM, Paul Smith wrote:
If the software can decrypt its own encrypted data automatically, then 
the decryption key/method is on the PC, so not going to stop a 
determined attacker.


I don't know if this exists or not, but I could see how files 
(independently of disk encryption) on the server could be encrypted 
using a key that is brokered elsewhere in the infrastructure.


A hypothetical example would be Exchange retrieving the encryption key 
used from AD which housed on DCs, physically separate machines.


The key does not need to live on the machine that has encrypted data. 
The machine just needs to have access to it through a tightly controlled 
mechanism.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] GDPR and SMTP in general

[Grant Taylor via mailop]

On 05/25/2018 04:32 AM, Leo Gaspard via mailop wrote:
Just for the record, OpenSMTPD supports queue encryption with the `queue 
encryption` option.


Nice.

I'll have to look into that, particularly how it does things.  I'm 
assuming that it encrypts / decrypts individual files / message stores.



I guess (hope?) other MTAs do support it too.


I've not heard this of a feature for any traditional unix MTAs. 
(Sendmail, Postfix, Qmail, etc.)


I know that Lotus Domino can do it.  (I don't know if it's done by 
default or not.)


I suspect that Exchange can have an encrypted .edb file, but I don't 
know.  -  As I type this, I don't know that the mail queue is in the 
.edb file.  It may just be files on the NTFS file system.  So that may 
mean that you would need to leverage NTFS' encrypted file system and 
control access to the decryption key via group membership.


I have no idea if GroupWise supports encrypted queues or not.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] GDPR and SMTP in general

[Brandon Long via mailop]

Encryption of data stored on disk that is resistant to these types of
attacks is not impossible, assuming that the keys are stored somewhere else.

The pieces are mostly available, from trusted boot through software
attestation and more.

I won't say what we do is impossible to break, but it's significantly
harder than gaining access to a single server.

I have no idea if GDPR requires that level of protection, especially if
you're only dealing with data in transit, but I'd be surprised if major
customers were happy without it for stored data.

Brandon

On Fri, May 25, 2018, 4:05 AM Paul Smith  wrote:

> On 25/05/2018 11:14, Rolf E. Sonneveld wrote:
> >
> > Yes, dealing with exactly the same kind of problem(s). One of my
> > customers asks me to sign for the fact that mail is encrypted when
> > handling it. However, using standard MTA software, messages that are
> > in the queue waiting to get delivered, are unencrypted. Am I forced to
> > use disk encryption?
>
> For that, I've just told people that the mail is held unencrypted
> locally, and if they want them to be encrypted, then I've told them to
> use end-to-end encryption (eg PGP, password-protected ZIP/DOC file etc)
>
> I've explained that even if the mail is encrypted here, we have no way
> to make sure it's encrypted anywhere else, unless they use end-to-end
> encryption.
>
> To be honest, there's little point using disk encryption for this, but
> it's hard to explain that to people. If someone can hack into the
> server, the disk encryption achieves nothing. If the server can restart
> automatically and "enter it's own" decryption key, then disk encryption
> achieves nothing. If it needs the key to be manually entered at reboot,
> then that's a disaster waiting to happen. If the software can decrypt
> its own encrypted data automatically, then the decryption key/method is
> on the PC, so not going to stop a determined attacker.
>
> Disk encryption is great on a laptop. Not sure it is anywhere else.
>
>
> --
>
>
> Paul Smith Computer Services
> Tel: 01484 855800
> Vat No: GB 685 6987 53
>
> Sign up for news & updates at http://www.pscs.co.uk/go/subscribe
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] GDPR and SMTP in general

[Anne P. Mitchell Esq.]

> On May 25, 2018, at 4:40 AM, Paul Smith  wrote:
> 
>>> But, how it interacts with email, it all seems to get very horrible. I 
>>> suspect the *intention* is OK, but I'm struggling with the actual 
>>> regulations.
>>> 
>> Whilst this specific article (written by Andrew Cormack of Jisc UK) pertains 
>> to packet-pushing, it's conceptually identical to the SMTP "issue" you raise:
>> 
>> 
>> https://community.jisc.ac.uk/blogs/regulatory-developments/article/are-networks-data-processors
>> 
>> 
>> In your context, the processor is the sender (or sending organisation). It's 
>> not you. They're the ones making the decision to shift data from A to B, you 
>> are only the conduit (or one of many).
>> 
> 
> I wish that was the case, but it's not what GDPR says, certainly for SMTP 
> relay services
> 
> Article 28: (1) "Where processing is to be carried out on behalf of a 
> controller, the controller shall use only processors providing sufficient 
> guarantees to implement appropriate technical and organisational measures in 
> such a manner that processing will meet the requirements of this Regulation 
> and ensure the protection of the rights of the data subject."
> 
> Article 4: (2) "Processing means any operation or set of operations which is 
> performed on personal data or on sets of personal data, whether or not by 
> automated means, such as collection, recording, organisation, structuring, 
> storage, adaptation or alteration, retrieval, consultation, use, disclosure 
> by transmission, dissemination or otherwise making available, alignment or 
> combination, restriction, erasure or destruction;"
> 
> SMTP relay services do the highlighted operations on personal data. Thus they 
> are Data Processors. Whether a pure network operator is is more debatable, 
> but 'any operation' is a broad brush.

Right..and GDPR specifically admits of the potential for many 
processors/co-processors in a chain.  Moreover, the controller  is required to 
have an executed contract with the processor to whom they are handing off the 
data which explicitly states that the processor is GDPR compliant...and that 
holds true for contracts between processors and additional processors.

And because liability can pass back up the chain in the even to of a breach, to 
the tune of even the *full* amount of fines, we have been recommending that 
orgs be sure to insist on an indemnification clause with all of their 
third-party processors with which they do business. It would even be smart to 
include a clause about the processor warranting that they will ensure that any 
additional processors to whom they pass on data are also GDPR compliant.

http://www.gettingemaildelivered.com/what-your-contracts-must-contain-to-be-gdpr-compliant-and-gdpr-proof

Anne P. Mitchell, 
Attorney at Law
CEO/President, 
SuretyMail Email Reputation Certification and Inbox Delivery Assistance
GDPR Compliance Consultant
GDPR Compliance Certification
http://www.SuretyMail.com/
http://www.SuretyMail.eu/

Attorney at Law / Legislative Consultant
Author: Section 6 of the CAN-SPAM Act of 2003 (the Federal anti-spam law)
Author: The Email Deliverability Handbook
Legal Counsel: The CyberGreen Institute
Legal Counsel: The Earth Law Center
Member, California Bar Cyberspace Law Committee
Member, Colorado Cybersecurity Consortium
Member, Board of Directors, Asilomar Microcomputer Workshop
Member, Advisory Board, Cause for Awareness
Member, Elevations Credit Union Member Council
Former Chair, Asilomar Microcomputer Workshop
Ret. Professor of Law, Lincoln Law School of San Jose

Available for consultations by special arrangement.
amitch...@isipp.com | @AnnePMitchell
Facebook/AnnePMitchell  | LinkedIn/in/annemitchell





___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] GDPR and SMTP in general

[David Hofstee]

Hi,

There is a difference between being a "processor" and "telecommunications".
The telecommunications laws are different, more strict sometimes. I know
what the difference was in Dutch law, not sure in the EU area.

Yours,


David

On 25 May 2018 at 15:51, Renaud Allard via mailop  wrote:

>
>
> On 05/25/2018 12:14 PM, Rolf E. Sonneveld wrote:
>
>>
>> Yes, dealing with exactly the same kind of problem(s). One of my
>> customers asks me to sign for the fact that mail is encrypted when handling
>> it. However, using standard MTA software, messages that are in the queue
>> waiting to get delivered, are unencrypted. Am I forced to use disk
>> encryption?
>>
>>
> In the same vein, isn't encryption also required on the transmission
> channel? Should we now require for every mail TLS SMTP?
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
>
>


-- 
--
My opinion is mine.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] GDPR and SMTP in general

[Renaud Allard via mailop]

On 05/25/2018 12:14 PM, Rolf E. Sonneveld wrote:


Yes, dealing with exactly the same kind of problem(s). One of my 
customers asks me to sign for the fact that mail is encrypted when 
handling it. However, using standard MTA software, messages that are in 
the queue waiting to get delivered, are unencrypted. Am I forced to use 
disk encryption?




In the same vein, isn't encryption also required on the transmission 
channel? Should we now require for every mail TLS SMTP?




smime.p7s
Description: S/MIME Cryptographic Signature
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] GDPR and SMTP in general

[Ray Van Dolson]

On Fri, May 25, 2018 at 12:13:15PM +0100, Jeremy Harris wrote:
> On 25/05/18 11:49, Paul Smith wrote:
> > Disk encryption is great on a laptop. Not sure it is anywhere else.
> 
> It does mean you don't have to secure-destroy that sour disk you
> swapped out from the raid set.

This is the main benefit, and a pretty helpful one at scale.

Also for thwarting those pesky data center ninjas sneaking in at night
and escaping with random drives!

Ray

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] GDPR and SMTP in general

[Jeremy Harris]

On 25/05/18 11:49, Paul Smith wrote:
> Disk encryption is great on a laptop. Not sure it is anywhere else.

It does mean you don't have to secure-destroy that sour disk you
swapped out from the raid set.
-- 
Jeremy

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] GDPR and SMTP in general

[Paul Smith]

On 25/05/2018 11:22, Stefano Bagnara wrote:

On Fri, 25 May 2018 at 11:55, Paul Smith  wrote:

[...]
If someone sends a message from the UK to someone in the USA, by
definition, we must send that email outside of the EU. When we send the
email, we are sending personal data (eg usually the name/email address
of the sender never mind the content which could be anything (outside
our control)). That causes issues for GDPR.

NO, you are not transferring them as processor.

Why not? We are 'processing' personal data on behalf of the controller.

"Processor means a natural or legal person, public authority, agency or 
other body which processes personal data on behalf of the controller."


"Processing means*any operation* or set of operations which is performed 
on personal data or on sets of personal data", including such basic 
things as storage and erasure of data. If simply storing data on 
someone's behalf is 'processing', then distributing an email certainly 
is (at the very least, the data is temporarily stored, and then erased, 
both of which are explicitly listed as 'processing')





It's not YOU, it's the sender that is sending and in "control" of this
operation and perfectly aware that the email moves informations around the
world to be sent to a specific target, IMHO.


Yes, they're 'in control', so they're the Data Controller. Under GDPR a 
'Processor' is defined as pretty much anyone who touches that data on 
behalf of the Controller (and doesn't make decisions about it) - which 
is any SMTP server (and possibly network) which the messages passes through.


(I'm fairly sure this isn't the intention, but it's what the GDPR words 
say, and trying to explain to a worried customer that the words don't 
mean what they say isn't going to get very far)



When (outside the domestic use case) you use Gmail or Hotmail (just to name
2) to host your job emails/contact lists, you are using Google or Microsoft
as processor of your contact list data (for which you are the controller).
You would need a DPA from Microsoft or Google about that, but they don't
give this for free inboxes. You'll need Office365 or GSuite for your
business even if you are a personal business.
Oh, I agree with that totally. But people like gmail, and it's free so 
they won't even think about that.





--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] GDPR and SMTP in general

[Paul Smith]

On 25/05/2018 11:14, Rolf E. Sonneveld wrote:


Yes, dealing with exactly the same kind of problem(s). One of my 
customers asks me to sign for the fact that mail is encrypted when 
handling it. However, using standard MTA software, messages that are 
in the queue waiting to get delivered, are unencrypted. Am I forced to 
use disk encryption? 


For that, I've just told people that the mail is held unencrypted 
locally, and if they want them to be encrypted, then I've told them to 
use end-to-end encryption (eg PGP, password-protected ZIP/DOC file etc)


I've explained that even if the mail is encrypted here, we have no way 
to make sure it's encrypted anywhere else, unless they use end-to-end 
encryption.


To be honest, there's little point using disk encryption for this, but 
it's hard to explain that to people. If someone can hack into the 
server, the disk encryption achieves nothing. If the server can restart 
automatically and "enter it's own" decryption key, then disk encryption 
achieves nothing. If it needs the key to be manually entered at reboot, 
then that's a disaster waiting to happen. If the software can decrypt 
its own encrypted data automatically, then the decryption key/method is 
on the PC, so not going to stop a determined attacker.


Disk encryption is great on a laptop. Not sure it is anywhere else.


--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] GDPR and SMTP in general

[Paul Smith]

On 25/05/2018 11:33, Graeme Fowler wrote:

On 25 May 2018, at 10:46, Paul Smith  wrote:

But, how it interacts with email, it all seems to get very horrible. I suspect 
the *intention* is OK, but I'm struggling with the actual regulations.

Whilst this specific article (written by Andrew Cormack of Jisc UK) pertains to 
packet-pushing, it's conceptually identical to the SMTP "issue" you raise:

https://community.jisc.ac.uk/blogs/regulatory-developments/article/are-networks-data-processors

In your context, the processor is the sender (or sending organisation). It's 
not you. They're the ones making the decision to shift data from A to B, you 
are only the conduit (or one of many).


I wish that was the case, but it's not what GDPR says, certainly for 
SMTP relay services


Article 28: (1) "Where processing is to be carried out on behalf of a 
controller, the controller shall use only processors providing 
sufficient guarantees to implement appropriate technical and 
organisational measures in such a manner that processing will meet the 
requirements of this Regulation and ensure the protection of the rights 
of the data subject."


Article 4: (2) "Processing means *a**ny operation* or set of operations 
which is performed on personal data or on sets of personal data, whether 
or not by automated means, such as collection, recording, organisation, 
structuring, *storage*, adaptation or alteration, retrieval, 
consultation, use, *disclosure by transmission*, *dissemination* or 
*otherwise making available*, alignment or combination, restriction, 
*erasure* or destruction;"


SMTP relay services do the highlighted operations on personal data. Thus 
they are Data Processors. Whether a pure network operator is is more 
debatable, but 'any operation' is a broad brush.





--


Paul Smith Computer Services
Tel: 01484 855800
Vat No: GB 685 6987 53

Sign up for news & updates at http://www.pscs.co.uk/go/subscribe___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] GDPR and SMTP in general

[Graeme Fowler]

On 25 May 2018, at 10:46, Paul Smith  wrote:
> But, how it interacts with email, it all seems to get very horrible. I 
> suspect the *intention* is OK, but I'm struggling with the actual regulations.

Whilst this specific article (written by Andrew Cormack of Jisc UK) pertains to 
packet-pushing, it's conceptually identical to the SMTP "issue" you raise:

https://community.jisc.ac.uk/blogs/regulatory-developments/article/are-networks-data-processors

In your context, the processor is the sender (or sending organisation). It's 
not you. They're the ones making the decision to shift data from A to B, you 
are only the conduit (or one of many).

Regards

Graeme
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] GDPR and SMTP in general

[Leo Gaspard via mailop]

On 05/25/2018 12:14 PM, Rolf E. Sonneveld wrote:
> Yes, dealing with exactly the same kind of problem(s). One of my
> customers asks me to sign for the fact that mail is encrypted when
> handling it. However, using standard MTA software, messages that are in
> the queue waiting to get delivered, are unencrypted. Am I forced to use
> disk encryption?

Just for the record, OpenSMTPD supports queue encryption with the `queue
encryption` option. I guess (hope?) other MTAs do support it too.

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] GDPR and SMTP in general

[Rolf E. Sonneveld]

Hi, Paul,

On 25-05-18 11:46, Paul Smith wrote:
I've been going through some GDPR stuff. Amongst other things, we 
provide SMTP relay services to some customers, so are a 'Data 
Processor' under GDPR. In itself, that's OK as our own operations are 
GDPR compliant.


But, how it interacts with email, it all seems to get very horrible. I 
suspect the *intention* is OK, but I'm struggling with the actual 
regulations.


If someone sends a message from the UK to someone in the USA, by 
definition, we must send that email outside of the EU. When we send 
the email, we are sending personal data (eg usually the name/email 
address of the sender never mind the content which could be anything 
(outside our control)). That causes issues for GDPR.


When we send the outgoing message to another mail server, that other 
server's operator is also a Data Processor. According to Article 28 of 
GDPR, we have to get prior approval of the Data Controller before 
using them, and a responsibility to check that they are GDPR 
compliant. Obviously that isn't going to happen in any feasible way...


Then there's the question about whether Internet connectivity/Wifi 
hotspt providers are also Data Processors as they potentially have 
access to the message data (including personal data) and could be 
classed as 'processing' it.


Also, if a user is on holiday in the USA and downloads email to their 
phone or in an Internet cafe, we are 'sending it outside the EU', so 
again, GDPR has issues.



I thought it was all OK, but one of our customers asked us to sign a 
contract for GDPR which prevents us from sending data outside of the 
UK and from sending it to any other companies without prior written 
permission. I've pointed out the problems to them, but wondered if 
anyone else had come across this.


Yes, dealing with exactly the same kind of problem(s). One of my 
customers asks me to sign for the fact that mail is encrypted when 
handling it. However, using standard MTA software, messages that are in 
the queue waiting to get delivered, are unencrypted. Am I forced to use 
disk encryption?


/rolf


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop