[Freedombox-discuss] Introductions + failsafe e-mail

[paxcoder]

On 09/02/2010 05:44 PM, ian at churchkey.org wrote:
> Maybe the way to do email in a social network uses something like
> distributed storage /instead/ of SMTP.
>    
The internal e-mail is not a problem, the problem is bringing in the 
rest of the world on this.
> If we setup the mail server to prefer delivering to the TahoeLAFS
> maildir folder for all recipients that are in your social network, we
> might be able to get external "email" and internal "distributed+secure
> message" delivery done rather simply.
>    
Not sure if TahoeLAFS is added to the wiki at FreedomBox/Examples. 
Anyway, we're trying to avoid any additional servers, we're trying to 
host our own. The internal part is easy, but for "external" e-mail, I 
really don't know how to do it without any central servers at all. To be 
honest, I don't know if we can solve this, other than abandoning SMTP 
:-( And keep in mind this old timer has survived delayed IM messages, 
and the likes of Google Wave.
__________

On 09/02/2010 11:21 PM, Bjarni Rúnar Einarsson wrote:
> I wrote:
>
>     P.S. Nobody replied yet on the possibility of alternative SMTP
>     servers at friends'. Does this mean it can't be done?
>
>
> Of course it can,
How, who's keeping DNS record after you go off-line? Or am I missing 
something?
> but every additional thing which has to be configured and understood 
> by the owners of the Boxes makes them less useful to the average 
> person. Making this happen automagically would be possible, but might 
> actually be a terrible idea:
>
> I personally think I might *prefer* that a complete stranger relayed 
> my clear-text, unencrypted e-mail, than someone I know.

See, I never thought about this e-mail *not* being encrypted. 
Unencrypted private mail is a bad idea anyway, but they didn't have PGP 
when they thought of a POP server. Yes, we would of course make it 
automagical (eg. add friend's e-mail address to the list of alternate 
mailboxes, the stack would contact your firend's box and take care of 
the rest after a confirmation), but for the aforementioned reason, it'd 
still be an opt-in thing in the beginning, rather than opt-out. Later 
on, when there are more Freedom Boxes around, we can just assume 
everyone is going to make their newcomer friends configure encryption, 
while old friends will already be using it. Then we can make it opt-out.

> The people I know might be interested in spying on me or tampering 
> with my e-mail - they might be sleeping with my wife or suspect I'm 
> sleeping with theirs, or they might just be bored and looking for 
> gossip.  Complete strangers wouldn't care, and I probably wouldn't 
> care much if they *did* take a peek.

I guess that makes some sense in pre-omniencrypted mail period if we can 
guarantee delivery via signed confirmation (otherwise, your non-friend 
can discard your e-mail). But even if SMTP can somehow make that 
happen(don't think so, remember - it must be signed), for the reason of 
there being those who will still use clients that do not bother 
requiring confirmation (eg newcomer friends from above example), friends 
are a better choice, since unencrypted e-mails should only come from new 
contacts. Two or three trusted ones would suffice - I mean how long is 
your personal server off-line? Reliability with just a few alternative 
mailboxes grows exponentially. To give you an illustration, if systems 
were only be reliable 3 out of 4 times on average (that's really bad and 
your friends still only get 1/4 of all your e-mail - encrypted or not), 
with only 2 redundant mailboxes (two close friends), the mailbox 
availability would rise to 98%.

Still, things do not look good for distributed e-mail.

--Luka Marčetić (aka the parentheses man)
P.S. I don't know why, I keep imagining a guy sitting on a train holding 
his Freedom Box in his lap. Where is he going with it? Out of China?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20100904/b4219d11/attachment.htm>