Verified DOI-Email

The current state of prototype implementation has revealed the possibility that one can request DOI email permissions for "TO anyone and FROM anyone".

Example: malicious Carl could request and potentially hold a DOI Email permission that Alice can email Bob.

This doesn't really make sense tho, but leads to a lot of questions. Carl could send this email permission later to Alice. Since the first SOI signature was signed by Carl, this doesn't really make sense or would work in the end right now, but it would be possible to do so.

On the other hand if malicious Carl sends out email DOI permissions in behalf of Alice (which didn't even know about it) to Bob. Bob could later send Email spam to Bob with the sender address of Alice in order to trick the Doichain spam filter. If theres a DKIM and SPF involved this wouldn't be possible, but in general this whole question brings up a lot of uncertainty and questions.

So the idea is to prevent this kind of behavior with a "Registered Doichain Sender" or "Verified DOI-Email" functionality. Before one can request DOI-permissions for a certain FROM, one must proof that he's the "owner" (=has access to the inbox) of this email address. In this way the FROM address must be sent in the same manner as DOI requests are handled right now. First to some Doichain Node and then to the/a responsible validator (could be the/a fallback). Then this validator sends an email to the sender (FROM) in order to confirm the "ownership" of the email. The validator then signs the email address and stores the signature inside the blockchain. The idea is to abuse the NamId name field to hold the signature. e.g. es/ (for email signature es/+signature. Anyone can now request the public key of the validator from the dns to proof that a validator was confirming this email as "valid".

Further on, we can then make the validator require only valid FROM addresses to request DOI-permissions.

Todo:

• Add call JSON-RPC-API "/email/verify" (verifySenderEmail) (takes an email address) internally it calls meteor-doichain-api function verifySenderEmail, which uses this email-address and signs the email with the privateKey of the currentWallet and stores it as nameId on Doichain. It does so be sending the Verified-DOI-Email transaction to the responsible validator. The validator (Bob) sends out an email to party which wants to request DOIs with this email address (Alice). Alice confirms the email over Bobs dApp and Bob sends the transaction back to Alice (2 x 0,01 DOI storage fee - necessary)
• If Alice wants to aquire DOIs for multiple senders emails, each single sender email must confirm
• When receiving a DOI-request on Alice (DOI-Requester) and on Bob (Validator) it must be checked if the requesting party (sender-email) is verified on Doichain.