You're right, but it doesn't have to be for all emails, just have the option to send certain emails encrypted using "the standard" for sending encrypted email.

But again, yes, there is a big incentive to not have this feature.

I'm talking about making it something that the average person would use, not the person that is going to be managing public keys manually.

It could even just be an option to "send this email encrypted" for only one-off emails, and most receivers that deal with sensitive information (banks, brokerages, insurance, etc.) would be able to receive encrypted email this way. It would be the standard way of sending encrypted messages.

Currently, the way I need to do this now with my broker is to either log in to their website and send a message through it, or use a special web-based encrypted message service. It's not a nice way of doing things.

If I send an email to a non existent address today, don't I get an email back saying it doesn't exist? Or is that not a thing anymore?

I suppose spam/phish protection would have to move to the client (javascript on web-based email systems), which I suppose could overwhelm the browser if you get too many spam messages.

An alternative may be to have a whitelist of addresses that are allowed to send you an encrypted email. If the email server receives an encrypted email from an address not on the whitelist, then just discard it. Use something like SPF to prevent email address spoofing. This whitelist could be a global list as well as a personal list.

But I can understand why people might not want to attempt to implement something like this, there may be many potential ways to circumvent it, and people just don't want that kind of liability.

Why is that? If you are sending an email to a specific email address, and you encrypt the message using an incorrect public key, that address just gets sent an encrypted message that they cannot decrypt.

I suppose if their email is already compromised, that could be a problem, but this would require both the Key directory and the email account to be compromised.

If only the key server is compromised, I would think the best you could do is a denial of service.

Maybe because no popular web based email services support it (or if they do, do not advertise it)?

Gmail, for instance, could easily allow you to enter your public key and then advertise it on a public repository, then have you enter your private key and store it locally (not transmit it to the server). I guess you'd have to trust Google with that though.

But then whenever you press send to send an email, it would check the repository and if that email has a public key, if so, encrypt the message and send it (otherwise just send it in the clear). For incoming messages, just automatically detect if it is encrypted, and then use your private key to decrypt it and display it. It would be pretty much transparent once you supplied Gmail with your private and public keys.

Is there any such service where you can query a "DNS-like" server with an email address and it will give you back that email addresses' public key. Then you could encrypt a message using the public key and send it to the email address. Something like this should be easily implementable in all email clients, both web based and others.

Seems like a relatively simple thing to do. I guess that hardest part is getting people to make sure they save a secure copy of their private key/seeds, as if they lose those, they will be unable to read any of the encrypted emails sent to them and there would be no way to recover them.

I believe it is because so many people don't turn their headlights on at all.

This is due to them going on automatically once it gets dark enough.

If it is raining during the day and it is not dark enough to trigger the headlights, then they don't go on.

And because people are used to never having to turn them on, they don't think to turn them on when it's raining.

Multiple license plates and transponders can be associated with a single account. So all transponders associated with the account are associated with all vehicles associated with the account (at least for vehicles/transponders that have the same vehicle type code).

Perhaps you meant that you can not put the same vehicle on multiple E-Zpass accounts?

He wasn't liked on "Stand By Me"?