From 616f2d8c1a8bae4e7073a6a2d370f6afb71b16dc Mon Sep 17 00:00:00 2001 From: Teemu Hukkanen Date: Mon, 24 Feb 2020 18:38:10 +0100 Subject: Fix typos --- email2.md | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/email2.md b/email2.md index 942f980..3b5fc53 100644 --- a/email2.md +++ b/email2.md @@ -67,18 +67,18 @@ Problems with the existing email system not widely used, and tend to also leave metadata (headers) unencrypted. -* HTML email is not well standardised, and a security and privacy +* HTML email is not well standardised, and is a security and privacy risk. Different email clients implement HTML in different ways, and the web standards are not followed very closely. - Worse, there's an assumption that HTML emails can embed images from the Internet, which results in more security problems (images are complicated data provided by a potential attacker, and just - viewing them is a security risk), and privacy issued (the image + viewing them is a security risk), and privacy issues (the image hoster will be notified when you view the email, see tracking pixels). - There's moves to restrict this, but the problems have been known + There are moves to restrict this, but the problems have been known since soon after HTML email was introduced, and at least some of the problems still exist. @@ -116,14 +116,14 @@ above. Overview ----------------------------------------------------------------------------- -The shape of possible solution might be something like this: +The shape of a possible solution might be something like this: * everyone has any number of "email identities", which are roughly like email addresses; it's easy to create new identities, and to optionally link them together; each identity has cryptographic keys - encryption and digial signatures + for encryption and digital signatures -* all email is encrypted to the recipient's, and signed by the sending +* all email is encrypted to the recipient(s), and signed by the sending identity @@ -138,16 +138,16 @@ The reason current email has a spam problem is three-fold: * anyone can send email to anyone * sending any amount of email is basically free -* there is no real consequences from sending unwanted email, except +* there are no real consequences from sending unwanted email, except for the sender's reputation What we want from the solution: * anyone can send email to anyone who wants to receive it -* sending email should be basically free, if the receipient wants it +* sending email should be basically free, if the recipient wants it * sending email without prior arrangement does not need to be free -A possible solution might be a kind of digtial stamps. +A possible solution might be a kind of digital stamps. * Alice can give Bob a stamp to allow Bob to send email to Alice * Alice can give her friends permission to give out stamps on her @@ -177,7 +177,7 @@ versatile: * might not allow sending an email, but instead might delegate the power to issue stamps to someone else; the delegation might constrain the kind of stamps the delegate can issue -* might be cancelled by it's issuer at any time +* might be cancelled by its issuer at any time Stamps can be created manually via the mail user interface, automatically when sending email, or when joining a mailing list or @@ -200,7 +200,7 @@ requesting a stamp. collaborating server; possibly a group based on the social graph of the issuer -* the requestor might need to do some work to raise the cost of +* the requester might need to do some work to raise the cost of stamps: solve a cryptographic puzzle, or do some similar task; this would be easy enough that it's not expensive enough if it happens occasionally, but enough that it stops spammers from doing it en @@ -218,7 +218,7 @@ This is abused often by the less scrupulous operators. With the stamp model, the recipient would create a stamp (possibly single-use, or limited to a time period) and provide it to the -operator to be added to the mailing list. The receipient can get off +operator to be added to the mailing list. The recipient can get off the mailing list by cancelling the stamp. The mailing list doesn't need to even have an unsubscription feature. Without a valid stamp, the newsletter doesn't reach the recipient. Rejecting a stampless @@ -284,7 +284,7 @@ Message format ---------------------------------------------------------------------------- FIXME: this needs to be sketched. For now, assume something that's -rougly on par with RFC2822, but with simplicity. Possibly JSON. +roughly on par with RFC2822, but with simplicity. Possibly JSON. Group discussions, mailing lists, signing up for services @@ -329,7 +329,7 @@ Specifications, conformance All aspects of protocols and messages should be specified in sufficient detail and clarity to allow independent, inter-operable implementations. There should probably be a common test suite for -conformance, and some dedicated interoperatibility testing. +conformance, and some dedicated interoperability testing. -- cgit v1.2.1