Migrate to new bug triaging setup
Based on the discussion we had on tails/tails#19719, @boyska and @intrigeri designed the following plan.
- Things we want
- Split 2 problems?
- Step 1: Convert tails-support-private@ into a "normal" mailbox
- Step 2: move WhisperBack reports to this shared mailbox
- Optional follow-up steps
Things we want
Security
boyska considers IMAP equivalent to a ticketing webapplication in terms of security (very quick analysis)
- assuming WhisperBack reports are stored in cleartext server-side in both cases?
- I'm assuming that breaking Thunderbird security is easier than breaking even a simple basicauth on a webserver. (if you expose a web application directly, than it might be a different story, but screening it is usually simple, effective, and not too geeky)
Spam filtering
As painless as possible. Automatic spam filtering is great.
Manual spam filtering (maybe to complement the automatic one) is better done only once.
Track conversation
Knowing the answer of this question:
- "Has someone already handled this?"
- "How many bug reports have not been processed by anyone last month?"
- Has someone made it clear to UX (or segfault or whoever) that they'd better look at this?
Categorization
We might want to signify that a message is "hardware issue" / tps / TorConnection / etc.
Efficiency
We have a large volume of incoming messaging, that include large logs. Some of us developed their own tricks/tooling for doing that better. In finding new solutions, we should consider how feasible it is for them to quickly scan messages.
Split 2 problems?
- Email sent by humans or robot spammers to tails-support-private@ aka. tails-bugs@
- Lots of spam
- Efficiency challenges don't apply
- No need for any semi-open relay setup
- Email sent by the WhisperBack app from Tails
- No spam
- Efficiency challenges apply
- Need some sort of semi-open relay setup
Step 1: Convert tails-support-private@ into a "normal" mailbox
Migration process
We need to:
- ask A/I to turn the existing tails-support-priv... (#20221 - closed)
- distribute credentials to access this mailbox (#20222 - closed)
- share the tails-support-private@boum.org privat... (#20223 - closed)
- document the workflows somewhere else than on t... (#20224 - closed)
- point all relevant people to the new workflow doc (#20225 - closed)
Goals of this first iteration
This should solve the "spam filtering" problem.
This allows us to start experimenting with shared mailbox IMAP-based workflows for "track conversation" and "categorization".
This forces intrigeri to use some IMAP-enabled email client more, which can be a good preparation for the future (when we want to migrate the WhisperBack reports to this setup).
This doesn't allow much experimenting with the "efficiency" problem: the volume of emails on tails-support-private@ is small compared to tails-bugs@; and there's not much point in "grepping" or other form of advanced searching in human-written emails.
Email client support requirements
We want this to work with the most common clients around us:
- Thunderbird is a must
- bonus points if it plays nicely with offlineimap+notmuch
- Roundcube webmail is NOT a must (XXX: but would our workflow work, with the current rules?)
Principles
The shared mailbox is a database, not a discussion list
- if you want to reply to an individual human being or a team, put them in "To" or "Cc".
- If you want to add metadata to the machine, reply to the support mailbox + place the sent copy in INBOX.
- Optionally we can set up a SIEVE filter that moves to trash the email sent by this mailbox to itself so we don't have a 2nd copy of this message.
- If you want to reply to the Bug Reporter, do so.
No broad categorization expected by default
E.g. "Persistent Storage", "Tor Connection", "hardware failure", etc.
Is it worth the effort to label every incoming report with 1 of these categories?
It might be if we could automate this server-side when receiving reports, but this won't work for WhisperBack messages, which are the ones where the benefit would be the biggest (they're in bigger number, and they contain log strings which are easier to match): they're encrypted so the server cannot parse them.
Let's not do that manually.
Fine-grained categorization
The way we categorize reports, e.g. to annotate them with GitLab issue IDs, is primarily optimized for the efficiency of triaging: they should not spend time doing busywork that'll never be useful to anyone else.
This means that different triagers might add metadata differently, based on what they prefer: copying subjects on a pad, putting whisperback IDs on the issue, replying...
But categorization should be made accessible to non-triagers when they need it to do their job. E.g. if a developer commits to working on issue #XYZ, they should have a way to see reports that were identified, while triaging, as instances of #XYZ.
It's OK if this requires an extra step at the time someone actually commits to working on #XYZ, e.g. the triager will search for these reports and copy them to a dedicated folder, on demand.
Server-side setup
Convert the mailbox
The email mailbox we will be talking about in the whole section is a "regular" mailbox hosted on a trusted provider with a decent anti-spam setup.
Anti-spam
Note: let's avoid confusion between WhisperBack "open" relay and spam problem.
There are two channels to send us spam:
- directly to tails-support-private@
- to Whisperback's open relay
While channel 2 is perfect for spammers, they don't seem to know: all of the spam we receive is sent to tails-support-private@; it does not go through WhisperBack nor its open relay, but it goes through Schleuder.
In this proposed setup, our support email address, that received this spam, is hosted at an email provider with decent anti-spam capabilities, and without Schleuder in the loop, so presumably most of the spam will be filtered server side and we will never see it.
SIEVE filter
- server-side filter
- Condition (AND):
- Action: moves to trash
Setup for anyone with access to the support mailbox
Put replies (and forwarded messages) in the same folder of the message you are replying to
Under the Account Settings, Copies & Folders , Place replies in the folder of the message being replied to.
Don't mark messages as read automatically
That's not really required, but maybe you want to give it a try since the "Unread" flag is so important. Or at least, be super intentional about what state a message is in once you context switch out of it: only leave it as read if you're done processing it and nobody has to look at it again.
Thunderbird supports this with a global option.
Workflow
detailed in https://gitlab.tails.boum.org/tails/summit/-/wikis/Teams/Foundations_Team/Bug_Triaging/workflow
Step 2: move WhisperBack reports to this shared mailbox
Server-side setup
Solution to the WhisperBack "open" relay problem, relaying to a destination address hosted at a email provider that enforces modern standards: to send email, our server should authenticate to an SMTP account at whatever email provider + rewrite From to match that account. Keep accepting any incoming email with the expected destination address.
Workflow
Answering a bug reporter writing to Whisperback reports, if they come through a Schleuder mailing list
Assumption: tails-support-private@ is subscribed to the tails-bugs@ Schleuder mailing list.
- Reply to the bug reporter
- Mark the message as read
- We get 1 copy of the reply: the "sent" message
- We also get the copy message from schleuder
Slight problem: we get 2 copies.
This could be better handled by removing schleuder from the loop.
tails-bugs@boum.org with some "forwarder"
Answering a bug reporter writing to Whisperback reports, if we replace the Schleuder instance running on(assuming they even specified an email address)
- Reply
- Press reply
- Fix the recipient getting the actual email address from the body.
- send your reply
- Mark the message as read
- We get 1 copy of the reply: the "sent" message
Optional follow-up steps
Auto-reply
It never really delivered what we were hoping for, because:
- We have no Help Desk anymore.
- The process for changing the contents of the auto-reply message is not smooth, so we don't point users to current "hot known issues" and their workaround.
- We never implemented replying to WhisperBack reports (when users provide an email address).
Technically, we could re-implement it as an IMAP client (inspiration: https://git.lattuga.net/boyska/imaptab). Is it useful? If we want to do that, then we want to actually improve it: the status quo is already not great. Specifically, we'd want to improve the process for changing the contents of the auto-reply. And perhaps make it support WhisperBack reports too.
If it fits in S11 or another funding opportunity, this could be nice.
We think it's a SHOULD that shall not block step 1 nor 2.