Changes

* 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.) _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 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.