Ideas
Instead of email addresses, we should use a more generic address. This could be something like a handle like
`user@organization!`
or even without an organization:
`user!`
Like domain-names, it's possible to have organizations to which users belong. This way we can differentiate between John at organization 1 and john at organization 2.
Users and organization names should be [a-z0-9\-\.], case insensitive. Users have a minimum of 3 chars. Organizations have a minimum of 2 chars.
All chars are ASCII-7 encoded (only one byte per char is used). This means that we do not accept non-ASCII chars (like emoticons, umlauts, accents, etc) (Why not? Would this make things easier for users? How does email do this?)
Current regular expression to validate mailv2 addresses:
(^[a-z0-9][a-z0-9\.\-]{2,63})(?:@([a-z0-9][a-z0-9\.\-]{1,63}))?!$
Good:
Joshua!
jthijssen!
joshua.thijssen!
jay!
joshua-thijssen!
jay@my-organisation!
Bad:
fo!
fo_bar!
!kadfs
[{]]1}}
for instance:
The catchall is not possible anymore, as every address must be identified. (it's possible to have different message servers for different users)
It might be possible to send a message to a generic address:
@acmecorp!
This would receive on a dedicated mailbox. This means that the user part may be empty when using a (sub) organization. NOTE: this would make it a special address. Do we want this?
When creating an email, it's possible to do this offline. Since these emails cannot be sent anyway, they remain in the users' outbox until a connection is available to the sender's account.
Since finding public keys is difficult to do decentralized (can we leverage DHT for this?), we use a centralized server for now. This server is running at https://resolve.mailv2.nl
A mail server can accept the registration of accounts. This can be done for everybody (any handle/organization is welcome), or strict (only users in certain organizations are welcome) or whitelisted (only certain handle/organizations are welcome)
We can create invitations for accounts that expire after a certain number of days. Each invitation is a token. Users are allowed to register that specific account on the server with that token.
What happens if two people try to register the same address. We need some kind of system that allows us to decide race-conditions for instance. For instance, you can register your twitter handle, but as soon as this is registered, nobody else can. Since this system is intended to be decentralized, we need a decentralized way of figuring out if an account exists of not.
(I can hear already things like blockchain and such. How would that even work? What if the chain consists of a gazillion records? Do we need a separate system to manage this?)
Somehow, it seems inevitable to have a centralized system somewhere. Either a central resolve-server where we can add addresses and as soon as an address is added, nobody else can add that same address (do we need a large proof-of-work in order to create addresses this way in order to combat address hijackers?) Do we need to signup somehow with a (re)captcha?
It might be ok that multiple users "use" the same address. I can setup a "facebook.com" mailserver and add my own facebook email accounts. It's the fact that OTHER mailservers will not use my mailserver to send mail, but rather the one configured in the DNS record of facebook.com.
In our case, multiple users could use the same address, but only the one registered to the resolve-system will be able to resolve. (standing on the shoulder of giants: seems we are redesigning DNS, and badly?)
Users are not validated and are as-is. As soon as a user registers on a mailserver, it can create a verified account by signing the account with its private key (TODO: is this not an open-proxy kind of system, where hostiles scan mailservers, create accounts and send (illegal) data to others?)
Let's assume we're AcmeCorp and have the following handle:
info@acmecorp!
what stops me from setting up my own mailserver and create the account not-a-pishing-email-account@acmecorp!?
We could let `postmaster@acmecorp!` SIGN any accounts from `@acmecorp` domain. If not signed, it cannot be used for sending and receiving.~~~
TODO: how would signing work? Is this just another call to the mailserver:
/organisation/<hash:@acmecorp!>/enrol/<user>/<token>
Only users that are explicitly invited with a token are allowed to create this account.
hostile mail-servers: how do we know the organisation did this? Maybe the organisation signs each account with their private key, so we can use the organisation's public key to validate if it's a legal user.
What happens when an email account is deleted or retraced (person fired or moved to another company?)
# How can we start organizations?
Organizations should have very high proof-of-work. It should take hours before an organization is created just to make sure we don't flood the network with organizations (TODO: what happens if it does? Does it matter?).
# Trust your organization
Organizations should be able to be verified. For instance, how do we know that acme corp organization is indeed acme corp?
One way would be through signing with the X509 certificate of the domain.
The message client could then display the certificate name found in the cert(and maybe even domain name, but that should not really interesting)
This will leverage the certificate network of x509 certificates (could we even automatically generate certificates through AcmeProvider?)
Another way would be to use domain key system. By adding additional information in an organization, we can provide more info about
/organisation/<hash>
{
"address": "@Example!"
"name": "My Organisation inc."
"url": "www.example.org"
"twitter": "@example"
"contact": "hello@example!"
"validated_by": {
"domain_key": {
"record": "example.mailv2.example.org"
"data": "Foobarbaz"
}
}
}
This way, an organisation can be pinged/fingered for information including verification information. In the example above, this would mean it is validated through a domain_key DNS record that contains a private key encrypted hash of the given data (`Foobarbaz`).
By using a "validated_by" system, we can add multiple ways to validate an organisation (through x509 certs, domain_key, others etc)
# How to deal with double/fake accounts?
Creating an account requires CPU effort. For every account that is available to the outside world, a proof-of-work should be completed. Mail servers can define how many bits of work are needed before an address is accepted.
Accounts should be signed: we should always know for sure that the sender is actually the sender.
TODO: Could an account be created called `not-a-spam@my-corporate-bank!` and send you phishing mails?
# Setting up webhooks
It should be fairly easy to setup webhooks based on events on your account. For instance, when a message is received.
