[Freedombox-discuss] Idea for cross freedombox email system not leaking metadata

[Petter Reinholdtsen]

[Jonathan Wilkes]
> As it is currently described, SMTorP is not compatible with Cables.

What is needed for those to be compatible?  Can the protocols change
to become compatible and able to send email between solutions?

> Also, Cables has a pseudonymous author, and I have no idea who it
> is.  Is that an issue?

Probably not, but it will make it harder to get a trust relationship
with upstream if we decide to use Cables.

> Also, I've only heard of a single developer who's ever claimed to
> have used Cables. No one has audited it.  I'm not sure if someone
> has audited Mailpile.  Should software in Freedombox-- or at least
> software installed by default in Freedombox-- need an audit?

Yes, I believe all the software in FreedomBox need an audit, and it
also need an active Debian maintainer and an active upstream
development group. And the the binary software packages should be
reproducable[1] allowing anyone with the source code to verify that
the deb installed was build from the source in the source package.

 [1] https://wiki.debian.org/ReproducibleBuilds

Anyway, I wrapped up a blog post[2] about using Exim4 and Tor for SMTP
via Tor using my draft package.  Check it out and please test if it
work for you. :)

 [2] http://people.skolelinux.org/pere/blog/A_Debian_package_for_SMTP_via_Tor__aka_SMTorP__using_exim4.html

> There needs to be a more rigorous-- or at least explicit-- set of
> guidelines for what software may get included in Freedombox.
> Currently all I've read is that the project should glue together
> pre-existing pieces of software, rather than designing or developing
> software specifically for the project.  (Or at least minimizing the
> amount of software specific to Freedombox.)

Why is this needed at this point of time in the project?  At the
moment there is a very small group of people active, Nick Daly, Sunil
Mohan Adapa, James Valleroy and myself, according the the latest git
log messages, and I am not aware of any of us feeling such need.  I
see many needs for the project at the moment, among them is a set of
useful features (like SMTorP) we can test and make ready for end
users.  More burocracy and rules is not among them, and thus I wonder
which need you see will be adressed by a set of guidelines.

-- 
Happy hacking
Petter Reinholdtsen