[onionmx] Meeting?

Tue Feb 27 20:42:24 CET 2018

>>> Based on the five participants, let's meet on Tuesday, February 27, 2018
>>> 6:00 to 8:00 PM UTC.

This happened! Here are the notes. We would like to meet again in
significantly less than a year. Some of us took action items below but
we had more ideas than people :)

State of the OnionMX
=====================

* Some work happened in the Git repo

* OnionRouter implementation, ".onion discovery via SRV DNS lookups
  for use with Postfix"
  - URL: https://github.com/ehloonion/onionrouter
  - handles routing != pure OnionMX implementation (decoupled from onionmx)
  - less tightly coupled with OnionMX
  - project frozen ATM, a couple open issues, but there aren't more
    features really needed as it works
  - not sure how many users there are => hard to assess how well it
    works for how many people, espiv has been running for over 1yr, so
    its working well
  - existing packages: Debian packages but not in Debian, pypi
  - next steps:
    - find the Debian source package
    - Micah can help have the package in Debian
    - maybe open a pypi account to not be under a personal account
    - poll to learn how many people use which implementation

* Go implementation:
  - no change since 1y
  - URL: https://git.autistici.org/ale/postfix-onion-transport

* Right now most people are using static maps, except for espiv and a/i. 

* Todo:

  - ask on the list what other people are using

  - find the debian OnionRouter package and upload it into debian

  - micah and intri could work on the systemd dependency problems in
    Rome (see below)

RFC
===

Blocker for publicizing OnionMX? Some of us seem to have changed their mind
in favour of not blocking on the RFC.

Write at least $something, even if not a proper RFC.

Lets try harder on this and ping each other to try and get this going.

Misc report backs & plans
=========================

People from last Tor meeting were interested in the idea. Micah may propose
a session about it at the next Tor meeting in Rome:
https://trac.torproject.org/projects/tor/wiki/org/meetings/2018Rome/AgendaIdeas

Technical problems
==================

We're under attack
------------------

The Tor network is under DoS since December or so => harms
OnionMX reliability.

Boot dependency ordering
------------------------

If Postfix tries to deliver email before Tor is ready to build
circuits, at least for some of us Postfix flags the OnionMX domains as
unreachable, keeps email in queue and bounces them 5 days ago.
We don't understand what's going on exactly.

One option is to use systemd unit files to have a better dependency on
tor actually functioning (bootstrapped, ready to build circuits).
Tails had to fix this problem already, Micah and intrigeri will try
to look into this together.

This could also be solved by using onionrouter because it would retry
the lookups.

SPF failures
------------

This might be specific to Riseup's setup. Or not.

Riseup sends an email over the Onion to the immerda mailing list
server, the ML server tries to deliver email to list subscribers over
the Onion too, Riseup's spam filtering sees the message coming this
way it does some SPF thing and flags the message as spam. A few good
people tried to solve this and failed so far.

Corresponding RISEUP_SPF_TRUE SpamAssassin rule:

     # if the header from says it is from riseup.net, but spf fails, then score +5
      header __RISEUP_FROM From =~ /\briseup\.net\b/i
      meta RISEUP_SPF_TRUE (__RISEUP_FROM && (SPF_SOFTFAIL || SPF_FAIL))
      describe RISEUP_SPF_TRUE  Claims to be from riseup, but is not
      score RISEUP_SPF_TRUE 5.0

It might be caused by mismatch between From header, SPF record,
EHLO etc.

Some ML software now rewrite From to avoid such issues with DMARC.
Message came from Mailman 2.1.15 (according to headers), maybe immerda
should update to 2.1.18 where DMARC is available
(https://wiki.list.org/DEV/DMARC mailman DMARC support)

Bypassing spam checks for email coming from 127.0.0.1 over Tor
might be OK currently but it won't scale once OnionMX succeeds.

Reliability
-----------

i.e. not noticing that onionmx delivery isn't happening because tor is
down or similar, until things start bouncing, kwadro had this problem.

David also had this problem where the onionmx email sending couldn't
talk to riseup because of tor DoS. Was thinking of various fall-back
possibilities on the clearnet or another onion or whatever.

espiv was also having issues with tor client reliability, couldn't
connect to riseup or local tor client couldn't connect. Usually this
was resolved by restarting tor client on our side, and if it doesn't
work restart on the other side

Tor isn't that reliable (even when not DoS'ed) because relay churn,
but tor stability causes onion addresses to not be reachable, even
when the client was up and running. connections stop opening over
hidden service. lots of things in tor can go bad. onion services are
still pretty young in age.

The Tor project is looking for more funding for large scale onion
usage (including emails) this allows for putting more people to devote
to stabilizing hidden services.

singlehop more stable? can be....

What if we made a different daemon (decoupled from onionMX) that
checked the health status of services over onion services, such as
learning some information via the tor control port about the state of
tor and then decide what to do with it:

 - check tor has bootstrapped
 - the Python stem library could provide something to check if
   a hidden service is alive or not and return
 - can check if you can receive a descriptor or not
 - check if rendezvous with service is possible
 - understand timings/delays etc.

SRV DNS lookup support by tor
-----------------------------

Short answer: nobody is doing it and there are no plans to do it right now
Requires to change a couple thigns about how DNS lookups are done internally in tor
are the changes needed in libevent, or tor?
an overhaul of libevent in general is desired

there is a proposal/design for a naming plugin system: some people have worked on it, but its not very far
could map onion addresses to any naming system you want (gnunet, namecoin, etc.)
nobody working on it actively right now but might be coming soon

Promotion
=========

See "RFC" section above.

Some people planned to do a talk at Congress about OnionMX (but the talk was rejected).
Maybe could have a talk at HOPE.

Maybe "Tor"MX domain name maybe should not be used because tor project
is maybe not interested in this being used (+ the general Tor
trademark issue).

Monitoring / alerting
=====================

If any collective has an icinga that access can be provided to others,
we could setup some onionmx checks to see if things are working... it
would be handy to see if your onion was the only one with problems, or
you cannot see any service which would tell you your client isn't
working

Ale's check (https://git.autistici.org/ale/hsprober) seems opiniated
towards exporting metrics to Prometheus.

We could make a VM somewhere, but we need to come up with *how* we
would do these checks (if with stem, or just making the existing
nagios/icinga tests be more... forgiving, or something else?)