summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorTeemu Hukkanen <tjhukkan@iki.fi>2020-02-24 18:38:10 +0100
committerLars Wirzenius <liw@liw.fi>2020-02-29 09:37:16 +0200
commit616f2d8c1a8bae4e7073a6a2d370f6afb71b16dc (patch)
tree3d3053a4d0588c4497b56c7fb5bc0a6c35cabb7d
parent190a6fd9a9b06c42b5059ec599bb4f33e4115fd2 (diff)
downloadideas-616f2d8c1a8bae4e7073a6a2d370f6afb71b16dc.tar.gz
Fix typos
-rw-r--r--email2.md28
1 files 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.