Re-Thinking Electronic Mail
ideas.liw.fi
ideas.liw.fi
https://craphound.com/spamsolutions.txt
> Every email user has one or more identities, represented by cryptographic keys.
Administered by whom?
> No email is delivered unless it carries a digital stamp issued by the recipient
The central premise of e-mail is that you can contact anyone if you know their e-mail address, without any pre-arranged permission.
If a recipient has to issue something to me before I can contact them by e-mail, that is too broken to be usable.
An intelligently designed micropayment system doesn't require anything from the recipient. Simply knowing someone's endpoint address, you an create a payment without their knowledge or consent, and attach it to the message.
> In this approach, each email user can have as many email identities as they want [ ... ] This means misrepresenting the sender becomes much harder, reducing the possibility for scam.
I.e. people can create arbitrary cryptographic identities, as many as they want (spammers can create millions of of these identities), yet somehow misrepresentation is not possible. Right.
If you get a cryptographic message from Joe Blow offering you fake R0lex watches, you know that must be the real Joe Blow, because, like, it is cryptographic! Someone running a key generator would never lie about who they are.
The document is not obligatory, it is one of the most destructive ever published on the subject; it represents the worst of nerd-dom and should not be used.
The debate stops spontaneously, because the participants are too stumped to respond to the ways that the form managed to anticipate serious flaws in their ideas.
If you can't defend your ideas in the face of some piece of net humor written years earlier, what good are those ideas?
That piece is in fact the encoding of a requirements specification; it shuts down the debate because it intrudes into it with some real world requirements that e-mail has to satisfy, and continue to satisfy while it transitions to something new. (Some of it is plain wacky, too, but not all).
A lot of programmers are very good at pretending requirements don't exist; they think that design means inventing your own requirements and making everyone else follow them. But a world-wide electronic mail communication system isn't an editor, video game or toy compiler.
This would be reasonably intuitive just as long as we were willing to give things sane names (e.g. Identity vs public key) and mail clients show clear statuses. We get encryption and identity reputation for free and can use it against spam as desired.
Those that do not know PGP are doomed to reinvent it...
Quoting ‘The PGP Problem’[0]:
> PGP begs users to keep a practically-forever root key tied to their identity. It does this by making keys annoying to generate and exchange, by encouraging “key signing parties”, and by creating a “web of trust” where keys depend on other keys.
> Long term keys are almost never what you want. If you keep using a key, it eventually gets exposed. You want the blast radius of a compromise to be as small as possible, and, just as importantly, you don’t want users to hesitate even for a moment at the thought of rolling a new key if there’s any concern at all about the safety of their current key.
> The PGP cheering section will immediately reply “that’s why you keep keys on a Yubikey”. To a decent first approximation, nobody in the whole world uses the expensive Yubikeys that do this, and you can’t imagine a future in which that changes (we can barely get U2F rolled out, and those keys are disposable). We can’t accept bad cryptosystems just to make Unix nerds feel better about their toys.
[0]: https://latacora.micro.blog/2019/07/16/the-pgp-problem.html
The rant you are quoting does not add too much to that point IMHO (age, what the author suggest does not solve many problems)
So what do you use for signing and encryption today when setting up a heterogeneous system like email or git?
I don't. For Email, quoting the aforementioned post[0]...
> Encrypting Email
> Don’t.
> Email is insecure. Even with PGP, it’s default-plaintext, which means that even if you do everything right, some totally reasonable person you mail, doing totally reasonable things, will invariably CC the quoted plaintext of your encrypted message to someone else (we don’t know a PGP email user who hasn’t seen this happen). PGP email is forward-insecure. Email metadata, including the subject (which is literally message content), are always plaintext.
> This isn’t going to get fixed. To make actually-secure email, you’d have to tunnel another protocol over email (you’d still be conceding traffic analysis attacks). At that point, why bother pretending?
> Encrypting email is asking for a calamity. Recommending email encryption to at-risk users is malpractice. Anyone who tells you it’s secure to communicate over PGP-encrypted email is putting their weird preferences ahead of your safety.
For signing commits in git, I'll quote Filippo[1]'s 'Sigining git commits considered harmful'[2] rant on Twitter.
> One of my issues with it is that it's marketed for a problem it does not solve (git metadata authentication and identity) and it's way suboptimal for the problem it solves (signed releases).
> I don't believe it works for that. You need at least a rebase (and key rotation, and identity) story for that.
> Pushes can be just as important as contents (imagine force pushing an old signed vulnerable tree to master) and are completely unprotected by this model.
> In the security space I struggle to see the line between "doesn't do the job" and "harmful", but sure, I am willing to downgrade "considered harmful" to "doesn't make sense".
If you still want to encrypt something plain text though, I would recommend age[3], which is:
> A simple, modern and secure encryption tool with small explicit keys, no config options, and UNIX-style composability.
[0]: https://latacora.micro.blog/2019/07/16/the-pgp-problem.html#...
[1]: https://filippo.io
[2]: https://twitter.com/filosottile/status/1248110291751231488
I don't talk to whistle blowers that much. And sure there are still attack vectors.
However I want to protect my email that may contain personal information from being leaked. Both SMIME and PGP do a reasonably good job. Until something usable and widespread appears.
Also digital signing seems to be better to me than sending scans with signatures . This is the reality.
People would call me nuts for sending them age signed content. I see really no benefit in using different keys . It seems also not formally verified . To much evangelism for me.
PGP provides essentially no additional protection beyond SMIME, and provides a false sense of security. PGP is a bad standard that should die.
Age doesn't have much to be formally verified. It uses well understood crypto primitives from the go standard library. What formal verification do you want? That the arguments are passed to the underlying libraries correctly?
Regarding proofs, i was just trying to comment on all the go/rust praises. Why would i need type safety if its such a thin layer. I am using openssl with bash for trivial encryption tasks. Not much can go wrong either. An Ada spark re-implementation of gpg would be still prefered by me if you just complain about too much nonauditable code.
Welcome to the 90s. Does anyone actually ever do this sort of thing? Now you just aim your phone at a QR code on another phones screen. Times have changed...
> Long term keys are almost never what you want.
Long term keys represent long term identities. So, yes, you do want that. PGP has subkeys that you can revoke whenever you want thus preserving your identity. I can't think of of any other system that supports this in such a straightforward way. Your phone gets owned and you basically lose everything. If you keep your master PGP key on a more secure device you are still in business...
The idea of a root of trust can be applied here as well.
> Spam is a result of the desirable feature that anyone can email anyone, combined with the fact that sending an email costs approximately nothing, even if you send millions of emails, and aggravated by the fact that spamming has de facto no real financial or legal repercussions.
Good that we can discuss this.
> 2.2 Overview of solution
Has some ideas in the right direciton of imposing the cost on the sender, as well as some ideas which have nothing to do with it.
The author jumps straight into implementing things, giving little attention to formulating how we want the cost function to look like.
> 2.6 Digital stamps
Good for some use cases, but not for others.
Imagine your relative wants to write you another email about how they are doing, or that but you haven't read their previous one, or forgot to issue them the new token. So they may as well create a new identity in order to email to you again?
> Alternatively, the email server could require the person sending the email to solve a CAPTCHA-like puzzle.
Blind and otherwise impaired people would get out of jobs at cusotmer contacts.
> Email servers could also sell stamps for real money.
As the measure of the last resort, the author turns to the ultimate medium of value exchange.
If the sender communicates to you, they expect to derive some (not necessarily immediately monetary) value from it, otherwise why are they motivated for it?
If the sender communicates to you so that you benefit, then you should have either paid them in advance, or they should reasonably expect you to pay them back.
I think it's time we recognize the economic side in everything we do, and stop shying away from "commercialization" of aspects of our life, i think. Otherwise we won't get out of the nonsense like "free software provides so much value, but nobody wants to pay for it" - valuable things are meant to be valued, that is, exchanged for other valuable things.
We use "free" as in zero (immediate) cost, and also use the same word to mean liberty.
In source code, I would expect that kind of conflation to be a source of subtle and vexing bugs for the application.
Can someone smarter than me produce a TED talk that introduces an improvement on this F-word?
Email really isn't one of those. Worse, there are a lot of almost-email areas which are (Slack, Facetime, etc), which makes it nearly impossible for non-commercial entities to produce a viable alternative. You're fighting network effects and deep pockets.
There are a lot of areas of computing that we take for granted today which were only created because they didn't need a corporation to find a way to be profitable. When big companies get together and try to produce the OS of the future, we get Multics and Taligent and OS/360. When individuals scavenge old cheap hardware to play around with for their own personal use, we get Unix and Linux and the Apple II.
Yes. It's a huge win for Google to read everyone's email.
Also, companies like the idea of programs needing "security updates", which allows pushing other unwanted things as well. Microsoft was one of the first in that area. If they couldn't have pushed Windows 10 as a semi-forced update, it never would have sold. Now pushing unwanted features is so pervasive that Mozilla does it.
In general the idea (from both the linked article and the research project) is to make it computationally expensive to send messages, in a way that is cheap for the recipient to verify. That reduces both the desire and the capability for scammers to widely distribute their messages.
[1] - https://en.wikipedia.org/wiki/Penny_Black_(research_project)
Then the e-mail readers receiving e-mails could easily filter all e-mails based on the absence/presence of that stamp.
At that cost 1000 emails would cost about $1.00 which would be a years worth of e-mails for a typical user.
For a million a day e-mail spammer that cost would quickly run them out of business.
> Every email user has one or more identities, represented by cryptographic keys.
> All email is digitally signed using the cryptographic keys.
> No email is delivered unless it carries a digital stamp issued by the recipient, or someone authorised to issue one on behalf of the recipient.
Ahhh, yes... yet another Final Ultimate Solution to the Spam Problem (FUSSP) [0]:
> The FUSSP depends on spammers or mail recipients changing their behavior without any immediate gain.
> The FUSSP requires that anyone wanting to send mail obtain a certificate that will be checked by all SMTP servers.
> The FUSSP involves certificates, but there is no barrier to spammers buying many independent certificates.
> The FUSSP assumes that your attention is so important that strangers will pay money to send you mail.
---
When you send an email, you attach a micropayment (say 1 cent's worth). When the recipient opens the email, you get your 1 cent back.
This would make mass spam unfeasible while still allowing companies with legit bulk email needs keep sending email, since they would get most of their money back.
It would even create an industry for people to be the payment middleman where they front you the cash for your bulk emailing and then assume the risk and keep the difference as profit.
The microprocessor would have an incentive to create anti-fraud systems. Perhaps you can't send email until 30 days after you pay or something like that.
It would be a place of innovation.
It could even start with the big players, like Gmail and Hotmail, allowing big senders to put down deposits.
In a dystopian world, it would be implemented by Gmail/Hotmail/etc. and they would allow free emails amongst themselves and then charge other senders. That's honestly how it would probably go down in the real world.
That brings us to what I assume you had in mind, which is blockchain, the solution in search of a problem.
Unfortunately proof of stake systems can be gamed by using stolen credit cards to buy stake, which defeats your proposed system. On the other hand, proof of work is an unmitigated environmental disaster, one of the most egregiously wasteful technological endeavors of the last twenty years, and would be rightfully shunned if not for its enthusiastic users who are too enamored to see the second-order effects of their easy access to illegal drugs and speculative investing while they hope for the next Bitcoin bubble so they can cash out for more fiat currency to retire on.
Heck, the big players, like Gmail, could just let you put say $5 down and then send 5,000 emails at a time (since you'd get it back when they were opened).
You have revealed your real email using the gmail plus sign feature. It's not that difficult for the people selling the emails or the spammers to remove a plus sign and some characters after years of knowing this.
Since I started receiving spam on my email address (around 2002) I’ve always use an alias for every new website I subscribed.
I didn’t know it _wasn’t_ possible to not have alias ?
Edit : I found reference of aliases on the rfc2142 from 1997
But yeah, if you had your own domain, then aliases had been a normal part of e-mail/web hosting plans for example, for a very long time.
I normally sign up for services with an email that attests to the account's original intent, e.g. I buy cat food using chewy.com@<username>.<domain>.
I'd suggest to use a different term for "identity", because this gets confusing. Perhaps use "appearance" or "presence".
I hardly think the gmail interface is the problem. All the things in the article can be completely transparent I think?
- Spam: What I do is use different email addresses for each correspondent and service. I can then edit my /etc/aliases file to get rid of addresses which are receiving spam. And as mentioned, some other services also support aliases too, so if you have aliases, then you can do the same kind of things too, perhaps.
- HTML email: Just avoid HTML email; plain text is much better. I use email software that doesn't even support HTML email (it will display the plain text part if it is a multipart message, but if not, then the HTML code will be displayed without attempting to render it).
- No real privacy, even if you self-host: Well, there is encryption if needed, if you know the recipient's key. However, of course some things will need to be unencrypted in order to transfer the message, such as the recipient's mailbox (although with SMTP over TLS, you can encrypt the username too, even though the target server will still be known).
- Attachments fill disks: You could use compression. You can also delete messages you no longer need. You can also program the server to reject messages longer than a certain length.
- There is no good support for group discussions: Use NNTP instead. NNTP is a superior alternative to mailing lists and web forums.
Wouldn't it be easier to just set up a whitelist for emails in your inbox, that only allows senders you specify through?
So basically, a better filtering system and a domain whitelist.
And also some emailcoins to send them (PoW).
(This is very old copypasta, maybe 20 or so years. As is the failed idea of email stamps.)
https://en.m.wikipedia.org/wiki/Zooko%27s_triangle
Zooko's triangle can be satisfied by a petname system:
https://en.m.wikipedia.org/wiki/Petname
This provides the security, decentralisation and human readable names needed for something like email. You just need the right system for managing the crypto for the secure global names, and a good user-focused process for secure introduction, key revocation/upgrade, etc.
What we need is a standard identity token that works with everything. Everything could still do their own identity stuff natively but could be automatically verified using the standard identity token.
I have recently spent some time looking at how PGP does this sort of thing in the form of key fingerprints and how the public key stuff works. There is a lot of wisdom in there that could be used as an example for a universal identity scheme...
https://en.wikipedia.org/wiki/Internet_Mail_2000
TL;DR: Each sender has or subscribes to a reliable mail server. The mail server does not deliver mail to recipients; it sends a tiny notification (restricted set of headers + UUID) to each recipient's reliable mail server. The recipient requests (or doesn't) the whole piece of mail via HTTPS or similar. The basic anti-spam tactic is to reject a whole server because it has sent you spam in the past.
Note that I don't use nor am a fan of systems like spamhaus, it just sounds very similar.
* http://jdebp.uk./Proposals/IM2000/anti-ubm.html
You are using a pull-style electronic communication system right now.
Works fine with Instagram, where you get a notification that someone wants to write you a message.
http://www.wisdom.weizmann.ac.il/~naor/PAPERS/pvp_abs.html
An implementation of this is Hashcash which was used on UseNet very successfully: https://en.wikipedia.org/wiki/Hashcash
- All mailing addresses are linked to a persona and are impossible to guess.
- Personas pay per address issued.
- Senders pay per message sent with a per volume of data fee too.
- Shut down all communication entirely.
(That is not entirely true, i have few emails I use hidden from users just to collect spam and feed it to bayes. But that is another story.)
It is 2020, stop using spyware sites like gmail and start using INTERNET.
Provider could have UI to generate unique alias, the alias address being account.uid.hash@provider.com. The uid is unique per alias, and the hash is h(account|uid|salt). The salt is of course stored by the provider. This way the provider can easily verify the alias is not forged, and it is easily blocked if leaked.
Mails going straight to the account (not an alias) could then be strictly whitelisted.
Or did I miss something?
Then you can add on things later like increased reputation of senders, and that can be on an individual basis instead of web-of-trust- IE; I have 10 users and those 10 users get 10 emails from princeofnigeria.com and github.com; but github.com has increased reputation due to previous email or following graylisting guidelines or whatever.
Sender pays would do a lot. Not popular.
> Ubiquitous. Approximately everyone on the Internet has email, or can get it.
However, some companies sending spam^wnewsletters would be willing to pay. I think this crap needs to stop, too, so this would be a partial solution at best.
First, there are some important use cases it would destroy (especially mailing lists).
Second, it's impossible to implement gradually. Protocols and infrastructure would have to change drastically, everywhere at once. Not feasible.
And I don't think it would lead to gradual adoption; as long as people still have to pay attention to the other bucket, there is little incentive to start paying at all.
Both produce high-volume, templatey mail.
So how do we make sure that "Vi@gr@ Pilules from C@nada" pays 15 cents per message, without bankrupting the legitimate invoices, tracking updates, mailing lists, and legitimately requested advertising flyers?
I'm not waiting to see Hey.com, the new project from the basecamp folks which sounds very promising to bring email to a new level.
Both of these are paid solutions, but I guess thats fine because free brought us here....
Specifically:
Spam: I used to get a lot more spam, today I get some, but with client side-filtering, it's something like a message every one or two days. And my address is very visible online, and I get dozens of legit messages per day; a good number even excluding mailing lists.
centralisation: This _is_ a problem for me - my provider is being swallowed by MS Outlook365. But that's not driven by spam detection IMHO. (PS - spam did not go down significantly when this happened.) Actually, whatever standard you use - it's extremely likely that if it's free and anybody can ran an "email-plus" server, then Google and Yandex and GMX etc. will run those, and web services to access them, giving you centralization again.
Scam: I feel I have this under control personally, but I recognize that some people might fall prey to that.
Standards for digitally signed email ... not great: I dunno, seems to work fine for me. I mean, sure, mail clients could use better integration of encryption and signing, but other than that no serious complaints about email as such.
a future where hosting email yourself makes you suspicious. Now _that_ is a problem. In fact, it's a problem _right now_.
difficult to hide who is sending email to whom. So, me and the author may believe this is a general problem, but many/most people don't care about this. Unfortunately.
HTML email is not well standardised, and is a security and privacy risk. It's a menace! For me, this is a serious problem. People write crap HTML and send it to me.
HTML emails can embed ... from the Internet: Easily disabled entirely with reasonable mail clients. The problem is in the client, not the protocol. After all, with any messaging protocol, you could send markdown or HTML as though it was plain text, and a client could choose to interpret it as it sees fit.
Attachments fill disks: I'm annoyed by this to no end, many people are perfectly fine with it since for them it's just webmail, so not their disk. Also, it's unlikely you can have your protocol prevent transferring files. At worst it would go back to the days of binaries-over-IRC.
The technologies and standards for email are getting ridiculously complicated. This is at most a problem for programmers. Also, it's a problem from the 1980s and early 1990s... MIME is quite complicated, and in fact, I challenge anyone here to point to any mail client properly support complex MIME structures, with hierarchies including multipart, alternative and so on. But most users are none the wiser.
The email tech stack is getting so hard to understand that it’s difficult to even use: If you're a power-user/administrator - maybe. If your' an end-user of webmail or a mail client - not really IMHO.
never mind implement correctly. Never mind that the complexity results in more effort to operate and keep the servers secure.
I don't even have that big of a problem. I almost never see e-mails that make it past the spam filter (like one every six months or so) and that includes one e-mail that dates back to the 90s that I used on usenet (aka, use your real e-mail address here and get added to every spam list). Even the volume of what gets caught in the spam filter is relatively low. The spam scammers have largely moved on from e-mail.
What failures do you see most often in this area? Alternatively, what popular software gets this wrong?
I'm not disputing your statement. It's just that one of my back burner hobby projects includes a new MIME parser, and identifying common pitfalls might help me feel confident that I get it right. Finding useful test data turns out to be harder than I expected. It's doing quite well with the messages I've thrown at it so far.
They don't even try in order to fail. They drop the alternatives and flatten consecutive parts - and that's that. You can't see the part tree, you can't fold different parts, there's no distinct rendering for "report", there's no representation of the "related" type, etc.
Consequently, there is no support for changing rendering settings or otherwise manipulating different parts, nor for removal or addition of parts .
http://www.forteinc.com/agent/
https://en.wikipedia.org/wiki/Fort%C3%A9_Agent
How have I done with respect to your challenge? :)
I wish more mailers were so good at just presenting the data, rather than mutating it to fit some designer's limited imagination or some programmer's limited patience.
It doesn't use email but paymail which is a protocol for email-like payment addresses.
- messages include some Bitcoin SV
- inbox sorted by value
- conditional notifications based on value threshold
- encrypted messaging