[Freedombox-discuss] email recommendations?

[Matt Willsher]

On 25 February 2011 03:49, Thomas Lord <lord at emf.net> wrote:
> I have a narrow topic question ... not the usual
> "big picture" stuff.  Anyone want to help
> brainstorm about:

> Let's assume that in Freedombox 1.0 - ready
> in maybe 6 months? - we have an initial solution
> for email service.  So the box serves SMTP
> and, I guess, it serves POP and/or IMAP and,
> over HTTP, some email client.
>
> Let's not immediately assume encryption stuff
> has to be working (unless it's really easy)
> but let's assume it has to get working ASAP.
> We can release without it but it shouldn't be far
> behind, so to speak.
>
> It has to be freakin' easy to administer.
> (Right?)

Yes. We should make good decisions for the user so they have little to change.


> The MUA has to be appealing but we might
> bicker about exactly what that means.
>
> Spam protection, blah blah.
>
> Let's assume for now ordinary DNS based
> mail addresses.  We can get fancier
> after the basics are up.
>
> THE QUESTION(S):
>
> What's the right stack for that part?

Postfix or Exim, Spam assassin, ClamAV, Dovecot  is a pretty standard
and well proven stack.

 The size, and language of the components needs to be looked at. With
only have 512MB space in a standard plug, I believe at the moment.
Spam assassin is Perl, for instance, and it has been raised elsewhere
that maybe interpreted languages are too intensive (size wise mainly)
for smaller devices. So some of this depends on lower level
architecture decisions which, I guess, will come from the Foundation.

Encryption via SSL requires a CA to avoid problems for end users.
That's going to be an interesting challenge.

Web MUA is, as you say, somewhat open to argument. I personally like
roundcube.

> How do we pick?

Established, proven software that's well understood and has a good
security track record. Should be part of the Debian ecosystem and
under the security teams remit.

> What does administration of it look like?

Simple! What can be automated should be automated. Giving it a quick
though, most if not all of the configuration data should be sourced
from the box's general configuration. Ideally it should just work, but
for standard decentralised mail MX records need changing and
domains/subdomains are needed. If the FB is to be a DNS server then it
can server that.

On the backend, I think something like cfengine, puppet, chef-solo
would help us integrate quickly and safely.

Zentyal I think is in the right direction for admin UI, but it's
really heavy on the back end.

Secondaries will, however, ideally be needed, that will queue the mail
for quite some time.

Thinking this through, this does raise questions about decentralised
DNS. Can it even be done? Is it required?

> What is the user experience like?

Setup once and just use it. Zeroconf if possible, otherwise windows
naming (netbios? I'm no Windows person) could be used for local
naming. The box itself should give the user set up instructions for
common MUAs, or if certain clients support automated set up, try to
leverage that (maybe some clients support SRV records for
IMAP/POP3/SMTP servers? ). Once set up it should just work all the
time. Ideally when the plug is moved to another network it should also
just work.

Other questions like, how is data backed up, how is it restored, and
the low level comms really need to be looked at.

> How does the stack evolve over time?

Hook into other message protocols as need be transparently maybe?
Email has been pretty stable and workable now for quite a long time. I
don't know how much evolution it will need, especially give the
current trend of people using Facebook for their messaging. If this
changes we should follow with solid and stable upgrades.

>
> I don't expect perfect and final answers to
> these questions -- I'm just trying to understand
> how the group approaches questions like this.
> I don't expect to establish any group
> consensus at this point -- I'm just trying to
> get a sense of how we're all thinking about
> questions like that.  (I have my own half-baked
> answers to the questions but I don't think they
> are interesting.)

These are my half baked answers. I'll be interesting to see, as you
say, how to group approaches this problem.

> Regards, all,
> -t