On 27 February 2011 20:37, Thomas Lord <[email protected]> wrote: > Matt Willsher, thanks for such a helpful message. > > I have questions about web-based MUAs. > > Background: > > You wrote: > >> Postfix or Exim, Spam assassin, ClamAV, Dovecot is a pretty standard >> and well proven stack. > > [...] > > >> Web MUA is, as you say, somewhat open to argument. I personally like >> roundcube. > > > >From what I see from the docs so far, Dovecot looks > like a win to me. I'm envisioning one form of the box > in which users *don't* run their own SMTP server but > do keep their own mailbox. Incrementally migrating > an Imap mailbox from "elsewhere" is easy enough. > Dovecot looks solid, flexible, and easy to admin. > I'm tentatively sold although we'll see what happens > when I try to build on it :-)
I don't see that the user would 'run' the SMTP server themselves as such. Once configured it should just work. There is no voodoo about an SMTP server over any other protocol server and SMTP is well established (interaction with the wider world) and can be secured from inspection. Postfix and exim also have excellent security records. I don't personally see why SMTP couldn't be used between FB nodes as the mail transport even if you want to exclude the rest of the world. > Web MUA Questions: > > Are there (that you know of) any Web MUAs that, by design, > more "API-centric"? In other words, any where the > design of the client-side code is not tightly coupled to > the server-side? Where the main thing that the server > offers is an (aims to be) stable API against which > 1,000 client-side applications might bloom (so to speak)? > (Roundcube doesn't look so, to me.) The decoupling happens at the protocol layer in mail even today. I'm not aware of a client that offers API services as you are describing. I would thought it would be pretty easy to throw together a JSON/XMLRPC -> some languages mail module program? (If you choose to do this past POC stage I would wait until there is more of an idea of what languages will be on the box as I would think there maybe only 1 or 2 interpreted language due to resource usage) > Also, any sense of which (viable) web-based MUAs have > very low amounts of server-side software dependencies > and resource needs? I think that (for reading) just a > literal imap <-> http proxy on the server is probably > too simple (too much burden on the javascript code) - but > how close does it come? Squirrel mail maybe?. It's old in it's design and its visage is ugly by modern standards but has pretty low over head. On the whole, though, they are all pretty heavy weight. As this project as gone forward it does strike me that it is perhaps going to have to implement its own user interfaces perhaps all the way back to the protocol layers in the case of mail. www.freshmeat.net may show more. The reason MUA exist is to parse the mail and display it to the user as by default they contain a lot of unnecessary information. Given privacy and security are likely to be two of the pillars of the project you'll probably need S/MIME as well. Sorry I can't offer any solid answers. Kind regards, Matt _______________________________________________ Freedombox-discuss mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/freedombox-discuss
