Bug#754913: tracker.debian.org: Overhaul of incoming mail handling

[Raphaël Hertzog <hertzog@debian.org>]

Package: tracker.debian.org
Severity: important

I want to redesign the way we handle incoming mails to fix a few
shortcomings:

1/ We currently use different email addresses to forward email to
   subscribers (<pkg>@tracker.debian.org) and to collect "news" which
   will be displayed on the web (_auto@tracker.debian.org).
   There's no good reason for this separation because the latter
   is really a subset of the former.

2/ We have to accept all possible emails because our scheme relies on
   <sourcepackage>@tracker.debian.org. It would be better to use a single
   email (eg dispatch@tracker.debian.org) to collect everything and then
   rely on headers and standard "user expansion" (eg
   dispatch+<pkg>_<keyword>@tracker.debian.org) to differentiate between
   source packages.

3/ The current naming scheme involves theoretical namespace conflicts
   between control@tracker.debian.org (the bot) and the email associated
   to a "control" package (if it existed) and makes it difficult to
   add supplementary email namespaces inside @tracker.debian.org... and I
   might want (at some point) to add new email addresses for teams
   and/or for use in Maintainer fields (think of
   http://dep.debian.net/deps/dep2/)

My plan is thus to create a new set of MailProcessing classes whose job
is to analyze incoming emails and decide what to do with them. It would
build on the current plugin mechanism so that each django app can effectively
extend/replace the default rules with its own set of classification rules.
Mails that do not mach any rules are archived in a mailbox for inspection,
just in case.

In conjunction with #754745, this "mail processing" would happen in real
time on new mails added to a single Maildir (where the single
incoming email delivers the mails).


I submit this to share my plan and to invite interested contributors to
review this idea and possibly share their feedback.

Cheers,