On Thu, 10 Oct 2013 14:44:45 +0200 Bjoern Hoehrmann <[email protected]> wrote:
> Back in the day it did not seem unusual for people to know about things > like anonymous remailers or how trivial it is to manually deliver mails > by typing SMTP commands into a console, including spoofing various bits > of header data, so that did not seem that big an issue to me. Oh, I don't think this is _quite_ to the level of telnetting to the MTA! How about this: There are two new standard buttons on the MUA: FRIEND UNFRIEND Everything possible is set up by the MUA when it is first run - keys, made, if they do not exist, questions asked and answered about keyservers, pass phrases, various preferences etc. Same as it SHOULD be now. "Coolmail has a new feature! You can 'Friend' people, and if they also friend you, you will be communicating privately from then on. Better yet, you will see no spam in this mode (unless you friend a spammer). It's easy to use! When someone you wish to communicate with privately emails you, just hit the friend button. This will handle everything automatically. They will be sent a plain text message with your special key. And if they also friend you, their special key will be sent to you, if you do not already have it. (all automatic). You can also set up this feature to automatically check the keyserver of your choice in preferences/friending" blah blah blah..." Something like that. Does not seem hard to me. Probably a bit less hard than learning how to add an attachment to an email, most everyone learns to do that. You just have to hit one button, all else is handled automatically. > There are a couple of problems with your approach above. One is knowing > whether and when you have been added to someone's `allow` list. Works just like now: If you are on the whitelist, your mail just goes through. If not, you get a bounce. As it works now: My mail goes through, unless someone has me blocked, in which case I get a bounce. People are quite familiar with bounces. > Another > is that people can include the encrypted message in their request to be > put on the `allow` list if they can somehow obtain the recipient's key, > rendering the request redundant. But it won't be decoded, because it is not marked as encrypted email. If you are trying to spam me this way, I will not see it, so what is the point? Optionally I could just drop all such messages, as part of the normal spam filtering. A friend request with an encrypted section is invalid. This is just ordinary non encrypted email far as the MTA system knows, and normal antispam measures will be applied. The best way to get me to add someone to my allow list would be a plain email asking for that (perhaps with a reason so I can judge whether they are a spammer or not) but then don't worry about keys, just hit the friend button and let the system handle the key exchanges. >Spammers can ask to be put on the list > just like anybody else. They can, but why would I add them? This is intended to be private email - friends, family, work, special people. The plain text mail system will still work just as now, for other purposes. It is also very likely that message from a spammer will be dropped by a blocklist long before I could see it. Most spam is either sent from (pretty quickly) known spam netblocks, or from hacked user machines, which are generally in ISP spaces labeled as such and mostly blocked (if you have any reasonable anti-spam system in place). Another factor is that spammers just won't, for the most part, be willing to go through such a two step process. For one thing, most will be -technically- unable to do so, because they are using hacked systems and this setup requires a reply from the actual sender to work. That simply cannot happen for most spam, because it is using forged addresses in the from lines, most often to completely different systems. -Friending is not complete until both sides have done the exchange.- This is a bit like confirmed email lists. Spammers could get on my lists if they really tried, but what I actually see is that they do not go past the first step - they just try to send some spam, if that does not work, they just move on. Too much work for them. OK, so...just checking the steps... I get plain email requesting friend status. I hit friend button, friend request is sent to original user, I am in half-completed friend state. Remote user gets request, half friend status, hits friend button, sends friend request, marks as completed. I get friend request, hit friend button, mark as completed. I think that should work. An active friend button hit is required from both sides to complete. There had to be valid return addresses on both sides for this to work. > >In the case of someone with no previous contact, if they tried to send > >you encrypted email, they would get an immediate bounce with an error > >message something like: > That would be a bad default policy: can be abused to verify addresses, No different than how email works right now. How is a bounce from this any different from a bounce for any other reason? If you are a spammer you are sending out millions of emails. To verify an address is in my 'inner circle', you would have to try, what, 200 million or so guesses, of which about 1,999,990 would be negative. Not likely to happen. > disclose encrypted email policy, The policy is default deny. Pefectly public. Why not? Right now the default policy for -all- mail is default accept, and everyone knows this. That is all they can learn from this. The exact same bounce for every single email they try. Millions to get one good one. Defeats the cost basis of spamming. > recover parts of the white list if the > mail system allows address spoofing, Again, millions to test. No spammer will do this. Most MTAs have limits on the number of addresses that can be tried, this is because spammers try to do that now with the existing mail system - this is no different and the same defenses apply. Now, if they happen to KNOW the address of one of my 'friends', they could send me spam IF my key was in a public keyserver or they got it from an email sent from me, AND they forged the sending address. A defense against that situation would be to have two sets of keys, one for initial contact that might be given out in an email, and once a secure setup was established, change to a second very private 'public' key, with the key exchange going through the already encrypted emails. This is kind of like how ssh works, I create 'public' keys for servers, but do NOT want those in a public keyserver or in emails. They are sort of private, public keys. > doesn't work when the receiving > system is down for maintenance for an hour or two, No, perhaps you do not understand that this is blocking done by the MTA, not the MUA. If the MTA goes down, exactly the same thing happens that happens now: The mail is requeued by the sending MTA and sent later when the receiving MTA is back up. No difference from now. > mails might get lost > when the sender switches addresses or uses a wrong one by accident, ... Same as the existng system. User will get a bounce. They just need to 'friend' the new address. Or correct their error. Just like when you make a typo in an email address. Nothing will be lost. -This is not filtering.- It is mail bounces, done at the MTA, specifically because that insures against such things. The feedback is very fast to the user. The changes to the mail system are extremely minor. The mailserver has a new way to handle the metadata that an email is encrypted - this is the only new feature change in the MTA. It is set to default deny for encrypted emails, using the existing system (same as used for anti-spam now) and to whitelist certain encrypted emails from that - again using the existing system. Everything else is unchanged, there is no more risk of losing emails or any other mail problem than there is now. For many different reasons, an email may bounce now - we have just added one new reason; a bounce is still a bounce and is handled exactly the same way. The purpose here is to give the average user a reason to use encryption (anti-spam, some privacy where you especially want it). And to make it so easy to use that many people will. It helps by at least providing some privacy for the user, and helps us all by the fact that if many people are using encryption, it changes the situation where if you are using encryption, that alone is cause for suspicion. It does nothing to help the metadata problems of email, and no doubt NSA etc could MITM it pretty easily. But it's work to do that. And if it is encrypted, they cannot do trivial searches on plain text to accuse me of being a terrorist because I happened to need a new seal for my pressure cooker. They at least have to get my keys somehow and decode it, or MITM me. If they want me that bad, I figure I am toast anyway. All the 'perfect' encryption in the world is useless if no one uses it, the way it is now. Get everyone on board, and I am sure things can be improved in time. -Mike _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
