We had multiple corridor discussions about email at the Stockholm meeting. This stems mostly from requests from the network team to setup an email server accepting SMTP submissions (#30608) but other concerns about our email infrastructure have been expressed before, namely the difficulty for non-technical users to get a mailbox or lack of clarity as to where they should get their email services anyways.

Before the Stockholm meeting, the Vegas team had discussed the issue. Anarcat provided a cost evaluation for a full email hosting solution, either external or internal, but neither were acceptable in the short term given budgetary constraints. The discussion was therefore postponed to the meeting.

We had planned a full session on the discussion, but due to a scheduling conflict, it ended up at the same time as the SysadminTeamRoadmapping session. We still talked about it among the sysadmin team during that session. It was then rescheduled to the InternalTooling session, but we ran out of time there as well because people couldn't stop talking about awesome and insecure Nextcloud and GitLab were, so we could only to a summary of the problems the sysadmin team had identified. Finally, we rescheduled it *again* during the sysadmin Q&A session, but then the Network team had a scheduling conflict, so they couldn't attend. In the end, we just arranged for dgoulet, ahf, weasel and anarcat to meet in the fresh nice Stockholm weather and try to find a solution, after the last session.

This is what we agreed on during that last informal session.


  • hosting a full email service (with mailboxes, not just forwards and submissions) ourselves or externally is too costly at this stage (around 5k to 15k$USD per year)
  • status quo is also problematic: a lot of people have trouble delivering email and this is hurting various parts of our community, from software development to grant writing and followup
  • adding SPF records pointing to everyone's mail server is impractical: there is a very long tail of email providers in our forwards. out of ~150 accounts,
  • providing stmp services (mailout) for everyone (including non-LDAP account) is also impractical: it would require another source for passwords, and to have efficient password resets, we would need an email control panel, which would be expensive to develop and/or deploy (see "full email service" above)
  • fixing the "UD-LDAP" implementation to make it more user-friendly is also a huge, multi-year undertaking that would immediately resolve this problem
  • circumstantial evidence shows that delivering email through infrastructure works more reliably than outside. It has at least allowed Mike Perry to resolve his problem (see comment in #30608).
  • this is a stop-gap measure, the first part of a longer effort to fix the email problem more broadly


  • we shall accept email delivery (mailout) for LDAP users, using their "service password", currently known as the "webRTC password" and (ab)used for authentication in the jabber server
  • this implies the Jabber service will have to be first shutdown
  • we are considering setting this up on a new email server so that we avoid damaging too much the reputation of people *not* using this infrastructure to send email (by adding another source in the pool). this is only an implementation detail and doesn't change the rest of the proposal (ie. it will use the same alias database and LDAP accounts)


  • users not using the new service (including users without an LDAP account but also users not willing or capable of switching) might have more difficulty getting their email accepted (or not marked as spam) by recipient servers. the assumption in this case is they are already having those problems and we would make the situation only marginally worse for them. fixing that problem requires budget expansion, which can still be considered
  • users with an LDAP account should have better chances of getting their email accepted, but there is no certainty on this.
  • this might imply an increase support load on the sysadmin team as routing problems will become our problem. the rationale here is that at least we'll be able to do something about it. this work will likely have to be done by TPI staff as volunteers are unlikely to be interested in working on email infrastructure
Last modified 15 months ago Last modified on Jul 18, 2019, 11:22:52 AM