I  messed up the "encryption" part in my last mail so here are some thoughts and how we could do things.<div><br></div><div>Supporting encryption is a hard problem from a UX point of view but I really want to make it happen. This is a little braindump.</div>
<div><br></div><div>We have some Problems: </div><div><br></div><div># It breaks webmail</div><div><br></div><div>nothing we can do about that</div><div><br></div><div># it breaks other clients unless they have the same private key</div>
<div><br></div><div>this is especially relevant for kmail-mobile because it is not meant to be the single email client but a (mobile) addition. So we need to make it really simple / semi automated to exchange/copy keys between kmail and kmail-mobile</div>
<div><br></div><div># it is an overhead to the communication that can't be fully automated.</div><div><br></div><div>we need to make it as seamless as possible. this means making it the default configuration. so you "need" to do a key setup during the account creation. mails will be sent encrypted and signed  whenever possible unless the user explicitly tells us not to. Whenever you receive someones public key you get a dialog that asks you if you want to  add that to your keys and so on. Maybe even include a little tutorial that teaches the user about encrypting emails.</div>
<div><br></div><div><div># It requires both parties</div><div><br></div><div>There is not much we can do about that but a little footer that we could enable by default that tells the receiver what the strange public key attachment (that we also send by default) is.</div>
</div><div><br></div><div><br></div><div>This is out of scope for my GSoC project but we need to keep that in mind when designing the basis.</div><div><br></div><div>Cheers Mike</div><div><br></div><div><br></div><div><br>
</div><div><br></div>