Difference between revisions of "How to send emails"

From Wikibase Personal data
Jump to navigation Jump to search
(Created page with "= Problem Description = The SAR service/feature aims to aid the user in spontaneous initiation of Subject Access Reports towards a data controller. To minimize required effo...")
 
m
Line 19: Line 19:
 
* Showing a preview of the email to be drafted on the website so that it is easily copy-pasteable by the user in case of misbehaviour
 
* Showing a preview of the email to be drafted on the website so that it is easily copy-pasteable by the user in case of misbehaviour
  
* Sending emails on behalf of the users from server side, not using their credentials. (This raises how does a data controller react when he gets a Subject Access Request from a third party address. Could it happen that the Data Controller replies to the SAR originator address instead of the contact info in the email? Unlikely, as the Data Controller is responsible not to give out private information to third parties.)  
+
* Sending emails on behalf of the users from server side, not using their credentials. (This raises how does a data controller react when he gets a Subject Access Request from a third party address. Could it happen that the Data Controller replies to the SAR originator address instead of the contact info in the email? Unlikely, as the Data Controller is responsible not to give out private information to third parties.) _The main problem with this approach is that the server (ours) sending the emails would very quickly become blacklisted on smtp blacklists as this would allow any anonymous third party to create invalid or maleficient mails being sent out from it_
  
 
* Sending emails using client side JS using SMTPjs or homebrewing an smtp client on our server that can be used by the user with his own credentials.
 
* Sending emails using client side JS using SMTPjs or homebrewing an smtp client on our server that can be used by the user with his own credentials.

Revision as of 17:47, 23 April 2019

Problem Description

The SAR service/feature aims to aid the user in spontaneous initiation of Subject Access Reports towards a data controller. To minimize required effort for this, the feature dynamically creates emails ready to be sent with subject and body texts.

  • The mailto functionality currently used for this provided by different browsers starts misbehaving on Windows 10 / Chrome 73 once the mailto url character count reaches 2048.
  • This is probably a Chrome-Windows interfacing problem, as Firefox can handle mailto urls of much higher length on Windows, and Chrome can as well on iOS for example.

[ https://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url-in-different-browsers ]

  • The mailto functionality discards body text from Microsoft Edge
  • Using window.location.href = "mailto:" to trigger drafting the email does not affect behaviour

Solution

The problem is solved if the user sets Windows Default App for Emails to Chrome, and sets Chrome email handler to gmail according to [1]

Alternative approaches

  • Showing a preview of the email to be drafted on the website so that it is easily copy-pasteable by the user in case of misbehaviour
  • Sending emails on behalf of the users from server side, not using their credentials. (This raises how does a data controller react when he gets a Subject Access Request from a third party address. Could it happen that the Data Controller replies to the SAR originator address instead of the contact info in the email? Unlikely, as the Data Controller is responsible not to give out private information to third parties.) _The main problem with this approach is that the server (ours) sending the emails would very quickly become blacklisted on smtp blacklists as this would allow any anonymous third party to create invalid or maleficient mails being sent out from it_
  • Sending emails using client side JS using SMTPjs or homebrewing an smtp client on our server that can be used by the user with his own credentials.

This option would involve having to use the user credentials, a very bad idea in general, because it would involve either our server even temporarily storing user credentials as a responsibility, or providing a third party server with the user credentials, an uncontrollable risk.