-
Notifications
You must be signed in to change notification settings - Fork 5
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. Organisations 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:
john!finance.acmecorp
Catchall is not possible anymore, as every address must be identified. (it's possible to have different mailservers for different users)
It might be possible to send email 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 a certain organizations are welcome) or whitelisted (only certain handle/organizations are welcome)
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!
?
Theoretically, nothing, so we should be able to make sure that we cannot do this. One way maybe could be to have a "postmaster@acmecorp" account on each organization. Since this is a special address, we can fetch information, like its public key, but also organization information.
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 on the mailserver:
/account/<hash:postmaster@acmecorp!>/organisation/enrol
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).
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?)
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?