> 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.
I remember how often it was posted on /. back in the day, and how it effectively shut down any discussion about fixing the real issues with email in any kind of open source fashion. The problem was eventually solved, but it was solved by Google and Yahoo and Microsoft in monopolizing email, because they were focused on the user and us nerds were focused on shutting down (im)-perfect open source solutions instead of working to improve them.
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.
There is no debate-silencing coercion involved in posting a link to a humor piece.
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.
You can do almost all of this within existing standards. The PGP identity token (AKA public key fingerprint) would be used as the primary email identifier. The embedded email address would then just be considered a technical routing detail. If you physically meet someone and want to "know" them in an email sense you just scan the QR code of their identity token (there is a standard for this too). When you decide not to know them anymore you just remove their identity. Knowing someone who knows you is a standardized process and technically is just an attachment of a PGP identity (public key). Knowing someone from their internet presence is also a standardized process.
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...
> 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.
>... by encouraging “key signing parties”, and by creating a “web of trust” where keys depend on other keys.
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...
Exactly, the best practices with PGP is to generate a main key for long term use and kept in cold storage, and generate subkeys that will be used on specific devices and revoked whenever necessary.
The idea of a root of trust can be applied here as well.
> 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.
I think the people you are quoting live in a different world than me.
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.
> 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.
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?
Why would pgp need to add sth over smime cryptowise? To me the difference is trust allowing sth. like autocrypt to be implemented . For me both work when build into a client:
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.
The gist of one of the most important problem: zero cost of mass unsolicited mail.
> 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.
I worry big companies like the failure of free email. They want you to stick in their giant corporate silo. Gmail to Gmail works. WhatsApp works. The death of the smaller participant by sheer impracticality suits them. Isp's are giving up on even providing SMTP servers. I'm beginning to think I will have to stop using my private domain name and just use a Gmail address. Then they will have won, locked me in and probably start charging me...
Indeed. The elephant in the room that this post missed is that email was created by researchers, not corporations. Today, a huge swath of computer science progress is created by corporations. We're making great strides in areas which can easily be monetized.
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.
I worry big companies like the failure of free email.
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.
Since the article relates to email and mentions digital stamps, it seems worth mentioning Microsoft's Penny Black[1] anti-spam research project which had/has some similar goals.
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.
I don't understand why we don't have a system whereby all e-mail clients automatically attach a $0.001 stamp to each and every email they send (obviously a sign in feature).
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.
Emails from a stamped individual could be "whitelisted" so as to no longer require a stamp to show up in your inbox. For instance, the first time you get an email from Amazon Prime (which they pay $0.001 cent to send), a box shows up saying "add this email to a whitelist so they don't have to spend money emailing you?"
The obvious solution to spam/scams are micropayments.
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.
One cent is less than the cost of a credit card transaction, which makes that infeasible.
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.
You don't need blockchain. You just need a few big players willing to set up a payment system with tiny transaction fees specifically for email.
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).
Do you? I get unsolicited postal mail, but it's at least well targeted and often relevant to me. Sure I toss the credit card offers, but if I were in the market for a credit card, the ones that I'm getting offered are probably the ones I'd consider.
Yes but nowhere near 1 cent per email, a sum that is still very little for legitimate users (especially considering the high likelihood of getting it back), but much higher than what current spammers pay.
Bad guys will buy cheap stolen credit cards (and there will be intermediaries for more legit ones). One credit card bought for 2$ - one hundred thousands emails sent. On the other hand payment processors will drown in transactions which cost more than amount sent. And before someone says "blockchain" - highly unlikely that it could work, but lets say maybe, for some specific token system. But eventually it will be plagued with exact same issue - easily and cheaply stolen funds will empower millions of emails and system will struggle under millions of useless transactions, problem won't be solved.
You wouldn't use traditional credit cards for micropayments. You'd need a dedicated micropayment processor just for emails that is significantly cheaper (like .01 cents per transaction).
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.
Just another processor won't solve the problem existing today - fund need to get into this system and they will get there from regular CC or regular people, which are stolen and sold cheaply today. It will be a battle between fraud and checks. The way they will battle this is "the dystopian" way, you are correct there - more and more closed systems, proprietary protocol additions, ban of 3rd party clients, eventually it will work only internally in google, microsoft and apple. It already starts to happen with dynamic emails, blocking imap etc.
I think one of the problems with email is that you have one global email tied to one inbox. Fastmail has the option to create multiple emails tied to one inbox so you could potentially have a unique email per sender, then if you start to receive spam it's easy to know who leaked it and disable the affected address
Exactly. My own domain is on Fastmail. I have an alias for every sites I have account in (Amazon, eBay, Pocket, ...). If I got spammed using an address I know exactly where it came from, advise the sir and create another alias.
This feature is supported by GMail as well FWIW. If your email is john@gmail.com all john+X@gmail.com addresses are aliases for your primary inbox. So you can have john+ebay@gmail.com, john+that_scammy_site@gmail.com and so on to easily track down spam.
It's not the same though. Fastmail allows a@fastmail.com and b@fastmail.com going to the same inbox. It's also easy to create these aliases.
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.
I've been using this for years. IIRC it's called "chaining". Unfortunately I've come across many sites that don't recognize, or allow, the + character in their input field. For those sites i can still crates either a group email from my Gmail, or just add another alias.
- 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.
So technically this is DKIM, except pushing the verification down from the domain level to the individual user level. And instead of publishing the public key in the DNS record, you manually give individual senders one/many time keys to send emails to you.
Wouldn't it be easier to just set up a whitelist for emails in your inbox, that only allows senders you specify through?
I'm not sure about your conclusion since that would violate the number one feature of email, but yes, the author's proposals do seem very unwieldy and ignore existing solutions.
It can't be that hard for an email client, on setup, to invisibly authenticate that you can recieve email from the address you are using to send from. Then it could organise all the key stuff for you automatically. Though admittedly getting the world to do it may be impossible. Nobody wants to invest in a dying technology. Sigh.
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.
The idea of doing email in terms of identities is a good one. That is because doing any communication in terms of identities is a good one. That simplifies, email, IM, video/voice and, yes, even video conferences.
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...
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.
How is that different from spamhaus and similar services that tell you which servers allegedly sent spam in the past? Except that it sounds like every person has to reinvent the wheel by blocking servers themselves instead of using an existing list.
Note that I don't use nor am a fan of systems like spamhaus, it just sounds very similar.
Let me propose another solution, much simpler, the one that internet was made for but looks like no one cares about. Host your own mail server. Each and every site I register to gots its own mail address. Not only that I know when address was sold, site was hacked,.. I also know which site. The only thing that is left is vi /etc/mail/aliases and one '#'. No spam at all.
(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.
Its a wonderful idea, but I fear there are too many blocks in place at the moment to achieve this, technical literacy being the main one. The reason that people go to GMail, Outlook.com (formerly Hotmail) and other services is For the convenience - mainly the simplicity. It’s easy. Running a mail server is hard (tm), well in relative terms. There is a lot that needs fixing, especially on the ISP front. Until we can all agree to use IPv6, or another solution that isn’t constrained in the same manner as IPv4, it’s a non starter. I hate to be one of those that doesn’t proffer an alternative solution...
Wouldn't require hosting your own server as far as I see. Gmail or Fastmail could do something similar.
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.
Wouldn't we get most of those gains by simply implementing proof-of-work for senders? (with an exponential backoff).
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.
To me, “proof-of-work” is toxic to the environment and is just an abstraction of “sender pays” — it also doesn’t address the carelessness of people sharing mailing addresses, which is at the root of the problem.
Because it's no better an idea than it was 25 years ago when Spam first became a thing and there was another genius throwing this idea around every other day.
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.
Gradual implementation wouldn't have to be hard. Gmail already sorts your inbox into several buckets. If you have one bucket for "paid/whitelisted" and another for others. You can leave the rest to the user.
So basically "pay to bypass the spam filter", is that really what we want?
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.
The sender doesn't have to pay a lot to make it effective. Remember that the spammer is sending email to a hundred thousand addresses per day, for free. If you charged even $0.01 per email, that'd stop a lot of spam right in its tracks.
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.
I don't think it's necessarily about the amount you charge but that for charging it you need access to a bank account / credit card or other banking infrastructure. That's not the case for everyone taking part in the internet.
Or proof-of-work, so long as it can be done without invoking The Blockchain (proof of work can be done without a blockchain, but you need to invest in armed guards to shoot anyone who mentions it).
I've never seen a good system to differentiate between legitimate transactional email and spam.
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?
Author makes the implicit assumption that the problem he experiences are the experience of everyone. They aren't.
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.
>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.
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.
> 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.
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.
> What failures do you see most often in this area? Alternatively, what popular software gets this wrong?
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 .
Back when I used Windows, I had a mailer (and usenet news reader) called Forté Agent. I liked the fact that it didn't hide things from me. When a content type was unknown or unsupported, it would still be represented (usually as an icon) in the displayed message. The MIME structure could be examined in a pop-up window, hierarchy intact, and individual parts could be scrolled into view or saved as files. Even preambles and epilogues were visible in the raw display mode.
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.
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.