Modify REST-API call "verify" - provide interface for postfix smtp-filter

[NiKrause]

As described in #101 , the verify call needs to be extended and should check if the local dApp has verifiable local data which have a valid permission (correct signatures) inside the blockchain.

In case the local database doesn't hold nameId and or public_key of Alice, we must either purely rely on the local data or find a way to gather or save public_key of Alice in order to decrypt the signatures inside Doichain. Please lets further discuss this issue here!

Please see https://bounties.doichain.org/ how to apply for Doichain bounties.

[NiKrause]

As I found out today, Alice did never send any sender email address to Bob yet. Which is good.
So Bob (and any fallback server) didn't really know about which email addresses in detail he his giving the permission. He just signs it. That was a pretty good (and necessary) practice so far.

In case Bob (validator dApp) is the authorized or delegated (Public-Key in DNS-TXT value) send-dApp of Peter (Recipient) it is acceptable that Alice sends the sender email address to Bob (which he can also store in the local dApp).

In case Bob is a fallback server. We don't change the behavior here. Fallback server should not know anything about who receives the permission in order to prevent data leaks.

[NiKrause]

Please write Test, which proves that fallback servers do not store any hashes / alice doesn't give any hashes to fallback nodes.

[NiKrause]

It is also in dispute if Alice (Send - dApp) should generate a "temporary" Private and PublicKey pair for each recipient which probably just get lost in future. https://github.com/Doichain/meteor-api/blob/master/imports/modules/server/recipients/add.js#L19

It is demonstrated inside the doiContact wallet https://github.com/inspiraluna/doiContacts/blob/master/doi_react_app/src/components/ContactForm.js#L135
that we just could use the PrivateKey of Alice (the requester) directly. This has also the advantage, the publicKey doesn't need to be stored somewhere in a database since its anyways visible in the blockchain transaction!

Further on, we recommend now it could be useful, to
use a different NameId for storing the soi permission on the blockchain e/....
So far we were always generating and abusing a PrivateKey which would never sign or encrypt anything: https://github.com/Doichain/js-doichain/blob/master/lib/createDoichainEntry.js#L20

here we'd like to make it more intuitive and encrypt a string containing recipientEmail+senderEmail (as we created the SOI signature here https://github.com/Doichain/js-doichain/blob/master/lib/createDoichainEntry.js#L22) and use this encrypted string as nameId! See: https://github.com/inspiraluna/doiContacts/issues/98