How to send emails - Revision history

192.168.0.1 at 01:27, 24 April 2019

2019-04-24T01:27:10Z

192.168.0.1 at 01:25, 24 April 2019

2019-04-24T01:25:29Z

192.168.0.1 at 01:24, 24 April 2019

2019-04-24T01:24:20Z

192.168.0.1 at 01:23, 24 April 2019

2019-04-24T01:23:51Z

192.168.0.1 at 01:21, 24 April 2019

2019-04-24T01:21:33Z

192.168.0.1 at 01:14, 24 April 2019

2019-04-24T01:14:23Z

192.168.0.1: /* Alternative approaches */

2019-04-23T18:55:32Z

Alternative approaches

192.168.0.1: /* Problem Description */

2019-04-23T18:49:26Z

Problem Description

Abel at 17:49, 23 April 2019

2019-04-23T17:49:42Z

Abel at 17:47, 23 April 2019

2019-04-23T17:47:51Z

@@ Line 25: / Line 25: @@
 * Using email provider APIs like [https://developers.google.com/gmail/api/quickstart/js Gmail API]. This is a viable alternative, as it involves Oauth, which solves the user credentials problem, but with the disadvantage of tying the user to a specific
-= Generating Body Text From Locally Stored User Data =
 To create ease of use for the generating the mail bodys, the site can store persistent reusable user data on the client machine using some feature enabling this.

← Older revision		Revision as of 01:25, 24 April 2019
Line 55:		Line 55:

	* Except for SOLID, there seems to be no easy way to transfer locally saved content from one browser or computer to another. This means it would be useful to give the user the option to convert anonymous client data into server backed registration data, or rather, just use SOLID.		* Except for SOLID, there seems to be no easy way to transfer locally saved content from one browser or computer to another. This means it would be useful to give the user the option to convert anonymous client data into server backed registration data, or rather, just use SOLID.
−	* As our predicted volume of used data fields will probably stay in double digits, asynch or synch requests should not make a big difference in performance, however, in general it is good practice not accessing any local data until it is to be read or wrote. Also good practice to read local data into RAM/some js object once it is necessary, and use it from there then on, ~~and~~ only touching the local copy of data when writing into it.	+	* As our predicted volume of used data fields will probably stay in double digits, asynch or synch requests should not make a big difference in performance, however, in general it is good practice not accessing any local data until it is to be read or wrote. Also good practice to read local data into RAM/some js object once it is necessary, and use it from there then on, only touching the local copy of data when writing into it.

@@ Line 53: / Line 53: @@
 = Data access considerations =
 * Except for SOLID, there seems to be no easy way to transfer locally saved content from one browser or computer to another.
-This means it would be useful to give the user the option to convert anonymous client data into server backed registration data, or rather, just use SOLID.
+* Except for SOLID, there seems to be no easy way to transfer locally saved content from one browser or computer to another. This means it would be useful to give the user the option to convert anonymous client data into server backed registration data, or rather, just use SOLID.
 * As our predicted volume of used data fields will probably stay in double digits, asynch or synch requests should not make a big difference in performance, however, in general it is good practice not accessing any local data until it is to be read or wrote. Also good practice to read local data into RAM/some js object once it is necessary, and use it from there then on, and only touching the local copy of data when writing into it.

@@ Line 52: / Line 52: @@
 * Only Con: very new, we are all rookies.
-Data access considerations
+= Data access considerations =
-Except for SOLID, there seems to be no easy way to transfer locally saved content from one browser or computer to another.
+* Except for SOLID, there seems to be no easy way to transfer locally saved content from one browser or computer to another.
 This means it would be useful to give the user the option to convert anonymous client data into server backed registration data, or rather, just use SOLID.
-As our predicted volume of used data fields will probably stay in double digits, asynch or synch requests should not make a big difference in performance, however, in general it is good practice not accessing any local data until it is to be read or wrote. Also good practice to read local data into RAM/some js object once it is necessary, and use it from there then on, and only touching the local copy of data when writing into it.
+* As our predicted volume of used data fields will probably stay in double digits, asynch or synch requests should not make a big difference in performance, however, in general it is good practice not accessing any local data until it is to be read or wrote. Also good practice to read local data into RAM/some js object once it is necessary, and use it from there then on, and only touching the local copy of data when writing into it.

@@ Line 5: / Line 5: @@
 * 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. See [ https://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url-in-different-browsers here].
+* 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. See [https://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url-in-different-browsers here].
 * The mailto functionality discards body text from Microsoft Edge
 * Using window.location.href = "mailto:" to trigger drafting the email does not affect behaviour
@@ Line 12: / Line 12: @@
 The problem is solved if the user sets Windows Default App for Emails to Chrome, and sets Chrome email handler to gmail according to
-[https://support.google.com/chrome/forum/AAAAP1KN0B0QzJMJ1TSYa8/?hl=en&gpf=%23!msg%2Fchrome%2FQzJMJ1TSYa8%2F3yPzJkgaCgAJ&msgid=3yPzJkgaCgAJ]
+[https://support.google.com/chrome/forum/AAAAP1KN0B0QzJMJ1TSYa8/?hl=en&gpf=%23!msg%2Fchrome%2FQzJMJ1TSYa8%2F3yPzJkgaCgAJ&msgid=3yPzJkgaCgAJ google support]
 = Alternative Approaches =
@@ Line 18: / Line 18: @@
 * 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, or a third party site like MailChimp or PostMark, not using the users 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.''' ( Which is probably also true for third party sites as the PD.io users could anonymously trigger aforementioned request, possibly resulting in suspension of service from the provider in case of a series of incidents. This is merely a guess based on that these services are usually provided to businesses reaching out to their consenting users, but this process usually does not involve giving third parties the option to use the system to reach fourth parties. This approach would require filtering for maleficious or more exactly floodülike behaviour on the PD.io side in any case)
+* Sending emails on behalf of the users from server side, or a third party site like MailChimp or PostMark, not using the users 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.''' ( Which is probably also true for third party sites as the PD.io users could anonymously trigger aforementioned request, possibly resulting in suspension of service from the provider in case of a series of incidents. This is merely a guess based on that these services are usually provided to businesses reaching out to their consenting users, but this process usually does not involve giving third parties the option to use the system to reach fourth parties. This approach would require filtering for maleficious or more exactly flood-like behaviour on the PD.io side in any case)
 * 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.
-* Using email provider APIs like Gmail API [ https://developers.google.com/gmail/api/quickstart/js ] This is a viable alternative, as it involves Oauth, which solves the user credentials problem, but with the disadvantage of tying the user to a specific
+* Using email provider APIs like [https://developers.google.com/gmail/api/quickstart/js Gmail API]. This is a viable alternative, as it involves Oauth, which solves the user credentials problem, but with the disadvantage of tying the user to a specific
 = Generating Body Text From Locally Stored User Data =
@@ Line 35: / Line 35: @@
 * only synchronous-blocking requests (see Data Access Considerations below)
 * Partially [https://stackoverflow.com/questions/17280390/can-local-storage-ever-be-considered-secure defendable]
-* There is separation of access between different domains even if it is a subdomain. This means scripts running on pd.io can not access wiki.pd.io localstorage (that is a good point in terms of security, however, IFRAMEs can be used to circumvent this in [ https://jcubic.wordpress.com/2014/06/20/cross-domain-localstorage/ some ] setups )
+* There is separation of access between different domains even if it is a subdomain. This means scripts running on pd.io can not access wiki.pd.io localstorage (that is a good point in terms of security, however, IFRAMEs can be used to circumvent this in [https://jcubic.wordpress.com/2014/06/20/cross-domain-localstorage/ some] setups )
 Indexed:DB
@@ Line 46: / Line 46: @@
 SOLID
-* [ https://solid.inrupt.com/docs/intro-to-solid-spec Solid ] implementation
+* [https://solid.inrupt.com/docs/intro-to-solid-spec Solid] implementation
 * Good source of future word puns to keep up morale for the developers
 * Can be done at [https://solid.inrupt.com/docs/app-on-your-lunch-break lunchbreak], increasing efficiency
@@ Line 55: / Line 55: @@
 Except for SOLID, there seems to be no easy way to transfer locally saved content from one browser or computer to another.
 This means it would be useful to give the user the option to convert anonymous client data into server backed registration data, or rather, just use SOLID.
-As our predicted volume of used data fields will probably stay in double digits, asynch or synch requests should not make a big difference in performance, however, in general it is good practice not accessing any local data until it is to be read or wrote. Also good practice to read local data into RAM once it is necessary, and use it from there then on, and only touch the local data when writing into it.
+As our predicted volume of used data fields will probably stay in double digits, asynch or synch requests should not make a big difference in performance, however, in general it is good practice not accessing any local data until it is to be read or wrote. Also good practice to read local data into RAM/some js object once it is necessary, and use it from there then on, and only touching the local copy of data when writing into it.

← Older revision		Revision as of 18:55, 23 April 2019
Line 23:		Line 23:
	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.		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.

−	* Using email provider APIs like Gmail API [ https://developers.google.com/gmail/api/quickstart/js ]	+	* Using email provider APIs like Gmail API [ https://developers.google.com/gmail/api/quickstart/js ], or free tiers of something like MailChimp or PostMark.

@@ 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
-* 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.