Server-Side Send Later

Feature Suggestions
,
#1

Right now, Send Later requires that Mailspring be running.

Here’s @bengotow’s statement on it:

Right now, features like snooze and send later rely on Mailspring being open because the app doesn’t send your email credentials to the cloud. We’ve got the infrastructure to support running the “send later” from Mailspring’s servers, but when it was a feature in Nylas Mail there was a lot of feedback from users that they didn’t want their email passwords being stored in the cloud to power those features, so it was removed for Mailspring 1.0. Definitely hoping to bring it back as an opt-in soon so you can choose the behavior you want!

Some users want the ability to send later without Mailspring running. Looking forward, if we implement Sync templates, signatures, accounts etc accross multiple devices, then this feature will be even more expected.

The sticking point is privacy, as stated above. We’d have to see how many users upvote this.

#2

I think all these concerns about privacy and password on the cloud etc are very exaggerated.

Everything is on the cloud nowadays one way or another. Even the actual email service is on the cloud!!

So we should accept this fact, protect our most sensitive data by simply not sending to anyone, but also use all the benefits of the cloud and get things done the way they should be done.

We are all on the move now, with two or three or 10 different devices to use.

We are not stuck to a 30kg pc in our living room

#3

Privacy on the cloud isn’t exaggerated at all. It isn’t just how the company will handle the data they have access to, but also how it is secured, how it’s retained, and what the risk of data theft would be in case of a breach. Breaches happen to everyone! We have to assume it could happen to us in how we design things.

Passwords are a little different than most data besides. Proper security standards for email services on the cloud are not to store the password, but rather a hash of the password - a unique number or string that is generated from the password, but which cannot be reversed to find the password. When you enter your password on a properly secured website, the password field is hashed, and then the hash is compared to the hash that was stored. If they match, then you entered the same password. At no point should the email server store the password itself. (Some do, despite security best practices, but that’s another topic.)

Meanwhile, cloud-based password managers use encryption to store data. The encryption password is something only you know, and without it, the data cannot be unencrypted. Once again, the cloud never stores the password(s) in plain text.

The trouble here is that for Mailspring to offer server-side send later, we would have to store the password itself on the server in plain text. We cannot use hashes, because Mailspring has to be able to send the password, and we cannot use the password-based encryption described above, because the whole purpose of the feature is to send the email without the user’s intervention (e.g. entering an encryption password). Some piece of the puzzle to access the password has to be stored in plaintext, meaning a data breach (which can happen to anyone) could expose email passwords. This is what we want to avoid.

The most secure technique would be to encourage use of app passwords when using Server-Side Send Later, as those are easier to rescind in case of a data breach. However, not all email services support app passwords, and it’s not really possible to know whether one is in use or not.

Long story short, this is why this isn’t an obvious feature. We have to consider the security implications, and ensure that there are enough users willing to accept the significantly higher risk of email data breach, just to offer this.

#4

My point is that when you allow someone to manage your emails - and all these related to them - you already accept a certain point of risk.

You also accept by default that this company - such as mailspring for example - will do its best to secure the data of the clients.

We are not all familiar with the procedures or the steps required by a cloud service in order to ensure the highest possible level of security because it’s simply not our job :slight_smile:

#5

The difference is non-trivial, however. There’s a difference between inviting a relative stranger over to your house for supper, and giving him your house key. That’s the difference here. Accepting some risks doesn’t mean accepting all risks. Wisdom dictates we choose our risks carefully.

We are not all familiar with the procedures or the steps required by a cloud service in order to ensure the highest possible level of security because it’s simply not our job.

Actually, it is your job to understand how cloud services store, retain, and use your data. That’s why privacy policies exist. Just because some choose not to be informed doesn’t mean they didn’t have the responsibility.

Anyhow, there are many users of Mailspring who care a lot more about these privacy concerns. We certainly care. So, we need to leave room for the conversation.

If you want to see this feature, please vote for it, but I need you to allow others to freely discuss the privacy and security factors here. Don’t discount it as irrelevant for all because you treat it as irrelevant to you; disregarding those risks is a personal decision that must not be expanded to others.

1 Like
#6

It looks like we arguing but we are not… My whole point is that there has to be a balance between security-usability- and of course feasibility of each requested feature.

If this specific feature is more prone to security issues and cannot be implemented as reliably as it should, that’s fine with me - at least for now. We move on and be optimistic that in the future it will be more feasible.

I don’t have the knowledge to argue about technical issues. So i take the developer’s word for it.

PS: I do not intent to disregard any opinion nor disallow anyone else to take part in the conversation. I wonder why you say that. I just mentioned my own opinion from the user;s perpective.

#7

PS: I do not intent to disregard any opinion nor disallow anyone else to take part in the conversation. I wonder why you say that. I just mentioned my own opinion from the user;s perpective.

See…

I think all these concerns about privacy and password on the cloud etc are very exaggerated.

Everything is on the cloud nowadays one way or another. Even the actual email service is on the cloud!!

So we should accept this fact, protect our most sensitive data by simply not sending to anyone, but also use all the benefits of the cloud and get things done the way they should be done.

(emphasis added)

Also…

We are not all familiar…because it’s simply not our job

I don’t believe you meant to discourse conversation, but the phrasing you chose above would read to some “I don’t care and neither should you. Stop exaggerating.” That will make some hesitant to respond, as they don’t want to be accused of exaggerating.

#8

Ok then…

By no means this was what i intended or meant…

If it looks like that then i am sorry

We move on… :slight_smile:

1 Like
#9

Well said CodeMouse92.

Privacy and security of your data cannot be underestimated, especially in these days.
The user needs to know how their credentials and data will be used, and then needs to decide if it’s worth using the service or software. The less links in the the chain the better.