├── mailchain_tenets.md ├── CONTRIBUTING.md ├── mailchain_use_cases.md ├── mailchain_threat_model.md ├── README.md ├── mailchain_specification.md └── LICENSE /mailchain_tenets.md: -------------------------------------------------------------------------------- 1 | ## Mailchain Tenets 2 | Mailchain’s tenets guide its approach to design and decision-making. 3 | 4 | Unless you know better ones… 5 | 6 | 1. User experience: Users expect a good experience. There should be no compromise on delivering the best experience within the bounds of today’s available technology. 7 | 8 | 2. Enable Anonymity: Many blockchains offer a degree of (pseudo-)anonymity to public addresses or accounts. Mailchain enables the preservation of anonymity to the degree permitted by the underlying protocol. 9 | 10 | 3. Enable Decentralisation: Many blockchain protocols are designed to run applications and store data in a decentralised way. Wherever possible, Mailchain removes centralized dependencies respecting that users may wish to run the software in a decentralized configuration. 11 | 12 | 4. Standards-based: Mailchain seeks to follow and contribute to existing standards. If no standard exists, we will propose new, open, high quality standards that others can adopt. 13 | 14 | 5. Low Cost: Interacting with blockchains can have an associated cost (e.g. Gas, transactions fees, storage fees etc.). Mailchain seeks to optimize the costs of sending messages. -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contributing to Mailchain # 2 | 3 | Thanks for your help improving the project! 4 | 5 | ## Getting Help ## 6 | 1. Submit an [issue](https://github.com/mailchain/mailchain-specification/issues/new) describing your issue. 7 | 2. We will try to respond to your issue promptly. 8 | 9 | ### Submitting a Pull Request ### 10 | Do you have an improvement? 11 | 1. Submit an [issue](https://github.com/mailchain/mailchain-specification/issues/new) describing your proposed change. 12 | 2. We will try to respond to your issue promptly. 13 | 3. Fork this repo, develop and test your code changes. See the project’s [README](https://github.com/mailchain/mailchain-specification/blob/master/README.md) for further information about working in this repository. 14 | 4. Submit a pull request against this repo’s masterbranch. 15 | * Include instructions on how to test your changes. 16 | * If you are making a change to the user interface (UI), include a screenshot of the UI before and after your changes. 17 | 5. Your branch may be merged once all configured checks pass, including: 18 | * The branch has passed tests in CI. 19 | * Review by the mail chain team 20 | 21 | ## Committing ## 22 | 23 | We prefer squash or rebase commits so that all changes from a branch are 24 | committed to master as a single commit. All pull requests are squashed when 25 | merged, but rebasing prior to merge gives you better control over the commit 26 | message. -------------------------------------------------------------------------------- /mailchain_use_cases.md: -------------------------------------------------------------------------------- 1 | ## Example Use Cases 2 | 1. **Invoice** 3 | 4 | A vendor supplies an invoice to request payment to an address. 5 | 6 | 2. **Receipt** 7 | 8 | A vendor issues a receipt for payment sent to an address for services. 9 | 10 | 3. **Payment** 11 | 12 | A user wishes to send a payment in a cryptocurrency or tokens with a remittance note attached. 13 | 14 | 4. **Gift** 15 | 16 | A user wishes to send a cryptocurrency or tokens to a relative with a birthday message. 17 | 18 | 5. **Donation** 19 | 20 | A user wishes to send a donation in a cryptocurrency or tokens to a charity with a message. 21 | 22 | 6. **Trading digital assets & collectibles** 23 | 24 | A user loves that cryptokitty, decentralized DNS-equivalent name or other NFT, so sends a message to make an offer to trade. 25 | 26 | 7. **After-sales support** 27 | 28 | After purchasing a digital good or service, I need to contact the vendor for support. I wish to remain anonymous but the vendor needs to ensure that I made the purchase. 29 | 30 | 8. **Renewal notification** 31 | 32 | A service provider sends a message to notify a user to renew a service or take an action (e.g. complete an ENS domain auction). 33 | 34 | 9. **Update notifications** 35 | 36 | A DApp developer releases a new version of software and wishes to notify all previous users. 37 | 38 | 10. **Community bug discovery** 39 | 40 | A smart contract security service provider recognises a vulnerability in contract software. They need to notify the anonymous owner of the contract, but have no way to identify them. 41 | 42 | 11. **Airdrop Subscription** 43 | A project owner or token issuer planning to offer tokens via an airdrop can send a message to users with details on how to opt-in for an airdrop. This avoids the need to blanket drop tokens to addresses that may not use ever them. 44 | 45 | -------------------------------------------------------------------------------- /mailchain_threat_model.md: -------------------------------------------------------------------------------- 1 | # Threat Model 2 | Every application has some exposure to threats. In mailchain, possible threats include the following scenarios. Where possible, the application will work around or try to reduce the risks. Nonetheless, developers and users should be aware and understand known risks or limitations. 3 | 4 | * Exhaust a user’s wallet balance through GAS usage by sending many messages. 5 | 6 | *In order to maliciously spend a user's ETH, it could be possible to send many messages. Each message has a GAS price and eventually a user's balance would reach 0.* 7 | 8 | *Because spent GAS cannot be recovered (except by the miner of a transaction), the attacker would not be likely to benefit from the attack.* 9 | 10 | * Send Ether in a transaction without user authorisation [currently not possible because the tx amount is set to 0]. 11 | 12 | *In order to steal a victim's ETH, it could be possible to send a message to an attackers address with the value of the transaction set to be the victims entire balance. The transaction value is currently set to be 0.* 13 | 14 | * Tracking/ inferring the existence of conversations between different accounts. 15 | 16 | *Although encrypted, the message transaction is distinct. Monitoring the transaction history between two addresses may enable an adversary to infer that messages were exchanged in conversation.* 17 | 18 | * Forward secrecy is compromised if the private key for an address becomes known by an adversary. 19 | 20 | *If the private key is discovered and a user continues to receive messages, the attacker will be able to decrypt these messages.* 21 | 22 | *This is also true for any other protocols that uses the same encryption method.* 23 | 24 | *To work around this, a recipient may provide or rotate different public keys for encrypting messages* 25 | 26 | * Backward secrecy is compromised if the private key for an address becomes known by an adversary. 27 | 28 | *If the private key is discovered, the attacker will be able to decrypt all past messages.* 29 | 30 | *This is also true for any other protocols that uses the same encryption method.* 31 | 32 | *To work around this, a recipient may provide or rotate different public keys for encrypting messages* -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Mailchain Specification 2 | 3 | 4 | 5 | 6 | 7 | 8 | * [Mailchain Specification](#mailchain-specification) 9 | * [Introduction](#introduction) 10 | * [Mailchain Message Lifecycle](#mailchain-message-lifecycle) 11 | * [Anonymity, Privacy and Encryption](#anonymity-privacy-and-encryption) 12 | * [What's here?](#whats-here) 13 | * [Working in this repo](#working-in-this-repo) 14 | * [Compatibility](#compatibility) 15 | * [License](#license) 16 | 17 | 18 | 19 | 20 | ## Introduction 21 | Mailchain enables blockchain-based email-like messaging with plain or rich text and attachment capabilities. Using blockchain protocols and decentralized storage, Mailchain delivers a simple, secure, messaging experience. 22 | 23 | Account holders or owners of a public address often need to communicate in the context of the account or public address. Communication may relate to transactions, account actions or some type of notification. 24 | 25 | Examples of use cases for blockchain messaging include invoicing, receipts, contacting users of a service or application developers. 26 | 27 | The majority of blockchain protocols provide no standard way to handle messaging. Some account holders have sent messages as an encrypted or unencrypted string included in transaction data. Some applications work around the problem by asking users to link another method of contact (e.g. email address, phone number etc.) to an application. This compromises anonymity by asking users to link or reveal an identity. It also increases exposure to security risks, and relies on additional centralized services. 28 | 29 | This proposal outlines how Mailchain gives users the ability to send and receive rich-media HTML messages between public addresses through a simple, email-like interface. All message contents and attachments are encrypted so only the intended recipient of the message can decrypt and view messages. 30 | 31 | ## Mailchain Message Lifecycle 32 | Mailchain is a simple, secure and practical standard which can be implemented across different blockchains. It uses underlying native blockchain protocol capabilities including addressing, immutability, data transmission, and cryptography. 33 | 34 | The basic message flow is as follows: 35 | 36 | * A user sends a message. The message is encrypted and stored using the recipient’s public key so that only the recipient can locate and decrypt the message contents. The encrypted location of the message is sent by the sender to the recipient in the data field of a transaction. 37 | 38 | * To read a message, a recipient uses a corresponding private key to decrypt the location of the message from the data field of a transaction and decrypt the message contents. 39 | 40 | ## Anonymity, Privacy and Encryption 41 | Mailchain considers anonymity of senders and recipients a high priority. 42 | 43 | The Mailchain application handles encryption and decryption of data (see *Mailchain Message Lifecycle* for further details). All data is encrypted when transmitted or stored outside of the mailchain/mailchain-web application flow. 44 | 45 | Anyone with the recipient account’s private key can decrypt messages, so it is important to secure private keys. 46 | 47 | The underlying blockchain protocol (e.g. ethereum, bitcoin etc.) is responsible for dictating the sender & recipient privacy model. 48 | 49 | --- 50 | 51 | ## What's here? 52 | 53 | There are four important files in this repository: 54 | 55 | 1. [mailchain_specification](https://github.com/mailchain/mailchain-specification/blob/master/mailchain_specification.md) - This lays out the specification for mailchain. 56 | 57 | 1. [mailchain_tenets](https://github.com/mailchain/mailchain-specification/blob/master/mailchain_tenets.md) - This declares the approach to design and decision-making. 58 | 59 | 1. [mailchain_use_cases](https://github.com/mailchain/mailchain-specification/blob/master/mailchain_use_cases.md) - This outlines some potential use cases for mailchain (feel free to suggest more). 60 | 61 | 1. [mailchain_threat_model](https://github.com/mailchain/mailchain-specification/blob/master/mailchain_threat_model.md) - This details known threats and how they might be mitigated. 62 | 63 | ## Working in this repo 64 | 65 | We :heart: pull requests! See [`CONTRIBUTING.md`](CONTRIBUTING.md) for info on contributing changes. 66 | 67 | ## Compatibility 68 | Mailchain implements Semantic Versioning (see [https://semver.org](https://semver.org/) for more information). 69 | 70 | From version 1.0.0: 71 | * New versions should be backwards compatible 72 | * Software must be capable of reading old versions 73 | 74 | ## License 75 | 76 | By contributing to the Mailchain Specification repository, you agree that your contributions will be licensed under its [Apache 2.0 License](https://github.com/mailchain/mailchain-specification/blob/master/LICENSE). 77 | 78 | -------------------------------------------------------------------------------- /mailchain_specification.md: -------------------------------------------------------------------------------- 1 | # Mailchain Requirements 2 | The following requirements set out how Mailchain can be implemented on top of a blockchain (See [Ethereum Implementation](https://docs.mailchain.xyz/reference/ethereum) for a sample implementation). 3 | 4 | ## Requirements Notation 5 | This document occasionally uses terms that appear in capital letters. When the terms “MUST”, “SHOULD”, “RECOMMENDED”, “MUST NOT”, “SHOULD NOT”, and “MAY” appear capitalised, they are being used to indicate particular requirements of this specification. A discussion of the meanings of these terms appears in [RFC2119](https://tools.ietf.org/html/rfc2119). 6 | 7 | ### Definitions for the purpose of these requirements 8 | | Term | Definition (in the context of mailchain) | 9 | | - | - | 10 | Centralized resource: | A single entity or group of entities could be said to have control of the resource. Responsibility for the integrity or availability or the resource falls on entity or entities. 11 | Decentralized resource: | No single entity or group of entities could be said to have control of the resource. Responsibility for the integrity or availability or the resource falls on the participants in the decentralized system according to the set of rules that govern the system. 12 | 13 | ## Message Storage 14 | ### General 15 | Messages SHOULD be stored ‘off-chain’. This minimises the volume of data stored on the blockchain. 16 | 17 | ### Permissions 18 | The sender MUST have permissions to write the encrypted message. 19 | 20 | The recipient MUST have permissions to read the encrypted message. 21 | 22 | Access to the storage medium MAY be limited through access controls to particular public address or account. 23 | 24 | ### Availability 25 | A message SHOULD be available for a reasonable duration for the recipient to read, save, take action. 26 | 27 | The duration a message is stored MAY vary. A time-to-live (TTL) SHOULD be specified. 28 | 29 | ### Location 30 | A sender MAY choose the storage location for a message. This permits the sender to select the storage most suitable for the use case. 31 | 32 | A recipient MAY indicate a preference for a storage location of messages. For example a centralised object store that is under the control of the recipient or a trusted organization. 33 | 34 | ### Immutability 35 | It MUST NOT be possible for anyone to overwrite or change an encrypted message. 36 | 37 | It MAY be possible for a recipient to delete an encrypted message. 38 | 39 | It SHOULD NOT be possible for anyone except the recipient to delete an encrypted message. 40 | 41 | ### Encryption 42 | A message MUST be encrypted with a recipient public key when stored. 43 | 44 | A message MUST be encrypted with a recipient public key when transmitted. 45 | 46 | A message MUST specify the encryption method. 47 | 48 | ### Durability 49 | Messages SHOULD not be lost unintentionally. 50 | 51 | Messages SHOULD not be discarded until the TTL has expired. 52 | 53 | ### Naming 54 | A message filename MUST be (probabilistically) unique within the address space. This is to prevent filename collisions. 55 | 56 | A message filename MAY include a hash of the encrypted message. This can be used to check the integrity of the message. 57 | 58 | A message filename SHOULD include the message-id field from the message. 59 | 60 | ### Hashing 61 | The recipient SHOULD be able to check the integrity of the encrypted message before decrypting. This enables the recipient to ignore messages that have been tampered with. 62 | 63 | The recipient SHOULD be able to check the integrity of the decrypted message after decrypting. This enables a way to verify the contents of an original message, for example in the event a dispute arises. 64 | 65 | Integrity hashes SHOULD be encrypted when stored on-chain. This reduces the risk of inference of a message. 66 | 67 | ## Message Resource Locator (MRL) 68 | The MRL MUST follow the [RFC1738 URL scheme](https://tools.ietf.org/html/rfc1738). 69 | 70 | The MRL MUST be encrypted with a recipient public key when included in a transaction. 71 | 72 | The recipient MUST be able to decrypt the MRL using the recipient private key. 73 | 74 | The recipient MUST be able to retrieve messages using the MRL. 75 | 76 | The protocol used for accessing the storage SHOULD be indicated in the MRL. For example, `ipfs:` or `https:`. 77 | 78 | ## Mailchain Addressing Format 79 | Addressing SHOULD follow the standard mailchain format. 80 | 81 | For example: 82 | 83 | `recipient_public_address`@`network`.`protocol`, where: 84 | 85 | * `recipient_public_address` SHOULD be a public address for the recipient. 86 | * `@` MUST be the delimiter to separate address from protocol and network details. 87 | * `network`, an optional parameter MAY be included to specify the network the transaction is broadcast to, for example a testnet or a mainnet. 88 | * `protocol` SHOULD specify the blockchain protocol for the message, for example, bitcoin or ethereum. 89 | * `.` (dot) MUST be the delimiter to separate the protocol from network details. 90 | 91 | The recipient public address MUST follow the addressing specification for blockchain protocol that the message is intended. 92 | 93 | ## Private Keys 94 | Private keys MUST be protected by a passphrase when stored. 95 | 96 | Users MUST be able to add a private key (to be able decrypt messages). 97 | The application SHOULD determine public keys when provided a private key. 98 | 99 | To carry out arbitrary actions, a user MAY NOT need to enter their passphrase. An example of an arbitrary action is using GAS to send a message. 100 | 101 | To carry out significant actions, a user SHOULD enter their passphrase. An example of an significant action is sending Eth attached to a message. 102 | 103 | ## Message Fees 104 | The cost of sending a message SHOULD be paid by the sender of the message, but the cost of sending a message also MAY be paid by the recipient or another party. 105 | 106 | The cost of storing a message SHOULD be paid by the sender of the message, but the cost of storing a message also MAY be paid by the recipient or another party. Examples of this may be for longer term storage or a particular storage medium requested by the recipient. 107 | 108 | ## Message Format 109 | A message MUST contain the following fields: 110 | 111 | | Field | Description 112 | | - | - 113 | Headers: | The message headers 114 | 115 | A message SHOULD contain the following fields: 116 | 117 | | Field | Description 118 | | - | - 119 | Subject: | The message subject 120 | Body: | The message body 121 | 122 | A message MUST have the following header fields: 123 | 124 | | Field | Description 125 | | - | - 126 | To: | The recipient public address 127 | From: | The sender public address 128 | Message-id: | A unique message id 129 | Date: | The [RFC1123](https://tools.ietf.org/html/rfc1123) date format 130 | Content-Type: | As per [RFC6532](https://tools.ietf.org/html/rfc6532) content type for the contents of the message. 131 | Content-Transfer-Encoding: | How the message body SHOULD encoded 132 | 133 | A message SHOULD have the following header fields: 134 | 135 | | Field | Description 136 | | - | - 137 | Subject: | The message subject 138 | 139 | A message MAY contain the following header fields: 140 | 141 | | Field | Description 142 | | - | - 143 | Reply-To: | The public address responses should be sent to 144 | Reply-To-Public-Key: | The public key that should be used to encrypt a reply 145 | 146 | A message body MUST be included after the headers. 147 | 148 | A message body MUST follow the content-type specified in Content-Type header. 149 | 150 | A message body MUST be encoded with the content-transfer-encoding specified in Content-Transfer-Encoding header. 151 | 152 | A message body MAY be empty. 153 | 154 | ## Transmitting a message 155 | A message location SHOULD be transmitted in a transaction to a recipient address. 156 | 157 | The transaction value in a message transaction MAY contain a non-zero value. 158 | 159 | The transaction MUST be compatible with the specification of the blockchain that messages are being sent on. 160 | 161 | ## Receiving a message 162 | A recipient SHOULD be able to retrieve all message transactions from an address transaction history. 163 | 164 | A recipient MUST be able to verify the message was sent by the public address claiming to be the sender. 165 | 166 | Encrypted messages that do not match the encrypted or unencrypted message hash SHOULD be discarded. 167 | 168 | A recipient MUST be able to decrypt the message location. 169 | 170 | A recipient MUST be able to decrypt the message. 171 | 172 | A recipient MUST be able to verify the message has not changed since being sent. 173 | 174 | ## Network Support 175 | A blockchain protocol MUST have the ability to send data in a transaction. 176 | 177 | A network MUST provide the transaction history for the recipient address. 178 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Apache License 2 | Version 2.0, January 2004 3 | http://www.apache.org/licenses/ 4 | 5 | TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION 6 | 7 | 1. Definitions. 8 | 9 | "License" shall mean the terms and conditions for use, reproduction, 10 | and distribution as defined by Sections 1 through 9 of this document. 11 | 12 | "Licensor" shall mean the copyright owner or entity authorized by 13 | the copyright owner that is granting the License. 14 | 15 | "Legal Entity" shall mean the union of the acting entity and all 16 | other entities that control, are controlled by, or are under common 17 | control with that entity. For the purposes of this definition, 18 | "control" means (i) the power, direct or indirect, to cause the 19 | direction or management of such entity, whether by contract or 20 | otherwise, or (ii) ownership of fifty percent (50%) or more of the 21 | outstanding shares, or (iii) beneficial ownership of such entity. 22 | 23 | "You" (or "Your") shall mean an individual or Legal Entity 24 | exercising permissions granted by this License. 25 | 26 | "Source" form shall mean the preferred form for making modifications, 27 | including but not limited to software source code, documentation 28 | source, and configuration files. 29 | 30 | "Object" form shall mean any form resulting from mechanical 31 | transformation or translation of a Source form, including but 32 | not limited to compiled object code, generated documentation, 33 | and conversions to other media types. 34 | 35 | "Work" shall mean the work of authorship, whether in Source or 36 | Object form, made available under the License, as indicated by a 37 | copyright notice that is included in or attached to the work 38 | (an example is provided in the Appendix below). 39 | 40 | "Derivative Works" shall mean any work, whether in Source or Object 41 | form, that is based on (or derived from) the Work and for which the 42 | editorial revisions, annotations, elaborations, or other modifications 43 | represent, as a whole, an original work of authorship. For the purposes 44 | of this License, Derivative Works shall not include works that remain 45 | separable from, or merely link (or bind by name) to the interfaces of, 46 | the Work and Derivative Works thereof. 47 | 48 | "Contribution" shall mean any work of authorship, including 49 | the original version of the Work and any modifications or additions 50 | to that Work or Derivative Works thereof, that is intentionally 51 | submitted to Licensor for inclusion in the Work by the copyright owner 52 | or by an individual or Legal Entity authorized to submit on behalf of 53 | the copyright owner. For the purposes of this definition, "submitted" 54 | means any form of electronic, verbal, or written communication sent 55 | to the Licensor or its representatives, including but not limited to 56 | communication on electronic mailing lists, source code control systems, 57 | and issue tracking systems that are managed by, or on behalf of, the 58 | Licensor for the purpose of discussing and improving the Work, but 59 | excluding communication that is conspicuously marked or otherwise 60 | designated in writing by the copyright owner as "Not a Contribution." 61 | 62 | "Contributor" shall mean Licensor and any individual or Legal Entity 63 | on behalf of whom a Contribution has been received by Licensor and 64 | subsequently incorporated within the Work. 65 | 66 | 2. Grant of Copyright License. Subject to the terms and conditions of 67 | this License, each Contributor hereby grants to You a perpetual, 68 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 69 | copyright license to reproduce, prepare Derivative Works of, 70 | publicly display, publicly perform, sublicense, and distribute the 71 | Work and such Derivative Works in Source or Object form. 72 | 73 | 3. Grant of Patent License. Subject to the terms and conditions of 74 | this License, each Contributor hereby grants to You a perpetual, 75 | worldwide, non-exclusive, no-charge, royalty-free, irrevocable 76 | (except as stated in this section) patent license to make, have made, 77 | use, offer to sell, sell, import, and otherwise transfer the Work, 78 | where such license applies only to those patent claims licensable 79 | by such Contributor that are necessarily infringed by their 80 | Contribution(s) alone or by combination of their Contribution(s) 81 | with the Work to which such Contribution(s) was submitted. If You 82 | institute patent litigation against any entity (including a 83 | cross-claim or counterclaim in a lawsuit) alleging that the Work 84 | or a Contribution incorporated within the Work constitutes direct 85 | or contributory patent infringement, then any patent licenses 86 | granted to You under this License for that Work shall terminate 87 | as of the date such litigation is filed. 88 | 89 | 4. Redistribution. You may reproduce and distribute copies of the 90 | Work or Derivative Works thereof in any medium, with or without 91 | modifications, and in Source or Object form, provided that You 92 | meet the following conditions: 93 | 94 | (a) You must give any other recipients of the Work or 95 | Derivative Works a copy of this License; and 96 | 97 | (b) You must cause any modified files to carry prominent notices 98 | stating that You changed the files; and 99 | 100 | (c) You must retain, in the Source form of any Derivative Works 101 | that You distribute, all copyright, patent, trademark, and 102 | attribution notices from the Source form of the Work, 103 | excluding those notices that do not pertain to any part of 104 | the Derivative Works; and 105 | 106 | (d) If the Work includes a "NOTICE" text file as part of its 107 | distribution, then any Derivative Works that You distribute must 108 | include a readable copy of the attribution notices contained 109 | within such NOTICE file, excluding those notices that do not 110 | pertain to any part of the Derivative Works, in at least one 111 | of the following places: within a NOTICE text file distributed 112 | as part of the Derivative Works; within the Source form or 113 | documentation, if provided along with the Derivative Works; or, 114 | within a display generated by the Derivative Works, if and 115 | wherever such third-party notices normally appear. The contents 116 | of the NOTICE file are for informational purposes only and 117 | do not modify the License. You may add Your own attribution 118 | notices within Derivative Works that You distribute, alongside 119 | or as an addendum to the NOTICE text from the Work, provided 120 | that such additional attribution notices cannot be construed 121 | as modifying the License. 122 | 123 | You may add Your own copyright statement to Your modifications and 124 | may provide additional or different license terms and conditions 125 | for use, reproduction, or distribution of Your modifications, or 126 | for any such Derivative Works as a whole, provided Your use, 127 | reproduction, and distribution of the Work otherwise complies with 128 | the conditions stated in this License. 129 | 130 | 5. Submission of Contributions. Unless You explicitly state otherwise, 131 | any Contribution intentionally submitted for inclusion in the Work 132 | by You to the Licensor shall be under the terms and conditions of 133 | this License, without any additional terms or conditions. 134 | Notwithstanding the above, nothing herein shall supersede or modify 135 | the terms of any separate license agreement you may have executed 136 | with Licensor regarding such Contributions. 137 | 138 | 6. Trademarks. This License does not grant permission to use the trade 139 | names, trademarks, service marks, or product names of the Licensor, 140 | except as required for reasonable and customary use in describing the 141 | origin of the Work and reproducing the content of the NOTICE file. 142 | 143 | 7. Disclaimer of Warranty. Unless required by applicable law or 144 | agreed to in writing, Licensor provides the Work (and each 145 | Contributor provides its Contributions) on an "AS IS" BASIS, 146 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or 147 | implied, including, without limitation, any warranties or conditions 148 | of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A 149 | PARTICULAR PURPOSE. You are solely responsible for determining the 150 | appropriateness of using or redistributing the Work and assume any 151 | risks associated with Your exercise of permissions under this License. 152 | 153 | 8. Limitation of Liability. In no event and under no legal theory, 154 | whether in tort (including negligence), contract, or otherwise, 155 | unless required by applicable law (such as deliberate and grossly 156 | negligent acts) or agreed to in writing, shall any Contributor be 157 | liable to You for damages, including any direct, indirect, special, 158 | incidental, or consequential damages of any character arising as a 159 | result of this License or out of the use or inability to use the 160 | Work (including but not limited to damages for loss of goodwill, 161 | work stoppage, computer failure or malfunction, or any and all 162 | other commercial damages or losses), even if such Contributor 163 | has been advised of the possibility of such damages. 164 | 165 | 9. Accepting Warranty or Additional Liability. While redistributing 166 | the Work or Derivative Works thereof, You may choose to offer, 167 | and charge a fee for, acceptance of support, warranty, indemnity, 168 | or other liability obligations and/or rights consistent with this 169 | License. However, in accepting such obligations, You may act only 170 | on Your own behalf and on Your sole responsibility, not on behalf 171 | of any other Contributor, and only if You agree to indemnify, 172 | defend, and hold each Contributor harmless for any liability 173 | incurred by, or claims asserted against, such Contributor by reason 174 | of your accepting any such warranty or additional liability. 175 | 176 | END OF TERMS AND CONDITIONS 177 | 178 | APPENDIX: How to apply the Apache License to your work. 179 | 180 | To apply the Apache License to your work, attach the following 181 | boilerplate notice, with the fields enclosed by brackets "[]" 182 | replaced with your own identifying information. (Don't include 183 | the brackets!) The text should be enclosed in the appropriate 184 | comment syntax for the file format. We also recommend that a 185 | file or class name and description of purpose be included on the 186 | same "printed page" as the copyright notice for easier 187 | identification within third-party archives. 188 | 189 | Copyright 2022 Mailchain Ltd. 190 | 191 | Licensed under the Apache License, Version 2.0 (the "License"); 192 | you may not use this file except in compliance with the License. 193 | You may obtain a copy of the License at 194 | 195 | http://www.apache.org/licenses/LICENSE-2.0 196 | 197 | Unless required by applicable law or agreed to in writing, software 198 | distributed under the License is distributed on an "AS IS" BASIS, 199 | WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. 200 | See the License for the specific language governing permissions and 201 | limitations under the License. 202 | --------------------------------------------------------------------------------