Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Key Generation during login is a feature not a bug. #23

Open
CANAWEN opened this issue Jan 11, 2022 · 3 comments
Open

Key Generation during login is a feature not a bug. #23

CANAWEN opened this issue Jan 11, 2022 · 3 comments

Comments

@CANAWEN
Copy link

CANAWEN commented Jan 11, 2022

From the FAQ:

For logins this would be simple. Just generate key on first login, encrypt it with password and store it on ETHMail server in encrypted form (much like how ProtonMail does it). That’s ok and probably the best for initial implementation, but what about email coming to your mailbox even before you logged in for the first time?

Email coming into your mailbox before account creation should be treated like original email treats messages sent to accounts that aren’t created yet, it trips an error and the sender gets a message saying “no address exists / is invalid”.

I see nothing wrong with this. In fact, imagine the spam waiting for if you senders could send emails to any email account before you create it, it’d be madness.

@gkapkowski
Copy link
Contributor

That's actually against ETHMail most important principle. There is no account creation. All Ethereum addresses have associated mailbox and anyone can send an email to any address even before the owner of the account has any knowledge of ETHMail.

The spam problem is a different one. It's a matte of filtering and marking messages appropriately.

@iceguru
Copy link

iceguru commented Jan 27, 2022

The downside ofc is that these emails still follow the 45 day term to my knowledge. So I'll never know if I had emails I missed.

@gkapkowski
Copy link
Contributor

Yes, I might actually change that, I would probably be able to change the 45 days into deleting largest messages (keeping some grace period before actual removal) when the inbox space reaches above 5-10MB for free accounts. This should be plenty of space for normal communication to sit and wait for the recipient while not costing me too much. What do you think?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants