Talk:Email

Security issues

Using OpenPGP would have been a reasonable choice in 1995, at this point though it is not the mainstream email security solution. Every major email package in widespread use supports S/MIME as an integrated function. OpenPGP is only supported as a plug in.

More fundamentaly though PGP and S/MIME have both failed to attract the level of use that they should. The proportion of email that is secured with either is negligible. Less than 1% of email users are aware that they exist, less than 1% of users are regular users.

I would strongly suggest that you look at domain level security solutions as the primary security scheme. End to end security would be nice but the current generation of user interfaces simply don't cut it. More email is authenticated using DKIM than S/MIME and PGP combined and more email is secured using SSL at the SMTP, POP3 and IMAP levels than both combined. Managing per-user keys is a lot of complexity for not very much return.

The primary objective should be for email to be sent secure by default without any user intervention. The first priority should be to encourage use of security. The perfect 'end to end' crypto system has proved to be much less useful and much less secure than the good domain based model.

The other advantage to this approach is that you are much more likely to get the laptops accepted by the more repressive governments with built in hop by hop security than with end-to-end. Remember that the objective here is to spread knowledge and learning, not cipherpunk style crypto-anarchy. An educated, informed population is much more of a threat to despotism than a few copies of PGP.

Although SSL for ecommerce requires a CA issued certificate there is no reason that a self signed certificate could not be used. If you need to further authenticate the certificate work from a trust anchor embedded in the DNS. --Hallambaker 23:10, 3 August 2006 (EDT)

It needs to be fully automatic, like ssh. By default, sign outgoing emails. Place the public key in the headers. As incoming emails arrive with public keys in the headers, store them for later. Incoming emails are considered good if a previously saved public key identifies the sender or if there is no previously saved public key. The other case, when there is a previously saved key and the email doesn't validate, causes the email's sender to get shown with a big question mark or similar. (according to locale; a question mark is correct for many Western languages) AlbertCahalan 23:06, 21 February 2007 (EST)

data format

This laptop is supposed to allow code hacking. That means being able to send correctly-formatted emails to the Debian bug tracking system and to the linux-kernel mailing list. Debian sometimes needs custom headers; this is a rather advanced function that needs to be slightly hidden by default. The linux-kernel mailing list needs pure MIME-free ASCII text with preservation of tabs, long lines, and trailing spaces; patches need to be included directly in the email body.

When originating a fresh new message, automatically choose between UTF-8 and ASCII. (pick ASCII if UTF-8 is not required)

Pay attention to the encoding of incoming messages. If it was neither UTF-8 nor ASCII, then that character set becomes a third choice. Favor it over UTF-8 if possible.

There are pretty much three ways that email can be formatted: plain text with hard line breaks (side scroll), plain text with soft line breaks supplied by the viewer, and full HTML. Be sure to reliably support all three. Be sure to always respond in kind by default, so that an HTML email gets an HTML response and the others likewise.

AlbertCahalan 23:28, 21 February 2007 (EST)

Re:

I hope you weren't thinking of breaking compatibility with the world. Note that "Re:" is effectively an icon. I'm probably living in the country that originated "Re:", and I sure don't know what word it might represent. It's just something that marks an email. You could hide it by default I suppose, but be sure to send it on the wire. It's effectively part of the protocol. Many clients have special handling for it. AlbertCahalan 23:28, 21 February 2007 (EST)

got a recursive name for you

Since you wanted one...

GUBOP underperforms because of Python

-)

Most email clients have enough trouble on modern hardware, even without the python to drag them down. SPAM is huge. Inboxes commonly grow into the thousands of emails. About the only nice thing to be said for Python is that it's a bit harder for a script to smash the stack.

To be on the safe side, verify that you can handle:

• 10000 emails sitting in the inbox
• 100 incoming SPAMs per day
• a few high-volume mailing lists like linux-kernel (300 to 400 emails per day)
• a dozen other emails per day, in long threads with responses
• emails with 15 MB attachments
• emails with dozens of 200 kB attachments
• a defective email, with a million 1-byte attachments

That all needs to work with threading, sorting, and full-text search.

BTW, maybe you should just make a pretty GUI wrapper for mutt. That you could do in Python, and the result would actually have battle-tested high-performance code under the pretty GUI.

AlbertCahalan 00:04, 22 February 2007 (EST)

SPAM

What are we using for spam filtering? - Aarjav 18:10, 17 July 2007 (EST)

Asynchronous sending

Obviously consideration needs to be given to the possibility of intermittent connections, both laptop-server and server-internet. Homunq 23:37, 28 July 2007 (EDT)

Is this project still on?

Email capabilities on the XO came up in an #olpc-content discussion about how to allow children to send/receive questions and answers from a Q&A system on appropriate technology that Vinay Gupta is hoping to implement. Curious as to what happened to this project and what its status is right now - any updates? Mchua 13:31, 11 August 2007 (EDT)