Inbound Mail
This project is aimed at improving the communication and response handling flow, giving data security enhancements in addition thanks to removing the mailing list from the picture. The goal is to have one place to handle all communication with requesters about a request.
The tool sends emails to requesters, or users send emails to requesters using their personal address. This has caused issues before where requesters have wondered why they're getting mail from a personal address. It also relies on users CCing the mailing list for accountability, which spreads private data into many mailboxes and a hard-to-purge mail archive, as well as the tool. This is tied to a request ID, and as such is tied to a username.
- Overall high-level project plan (@stwalkerster)
- Propose idea to WMF (@cyberpower678)
- Finalise scope and plan (depends on above)
High-level:
Inbound mail:
-
Getting mail to the Labs instance
- Will WMF want to handle this?
-
How should we handle HTML-only mail? Security and all that jazz.
- We should just display text only, but if the mail is HTML-only then we could have issues sanitizing it?
-
Attachment handling. Probably need a different subdomain for this (!).
-
Mail that is lost - wrong address, dropped request data, etc? Should we log this?
- Internal mailbox would solve this. Probably can't do anything with them though.
-
Mail routing from MTA to tool code
- Think Phabricator!
-
Mail security - DKIM/SPF/etc
- Install mailparse on instance/vagrant
- Install (MTA-of-choice) on instance
- Add script to handle inbound mail
- Add comment as log entry or comment?
- Log entry will allow us to handle it differently to comments
- Log entry can't be edited, has a descriptive header
- Probably FK constraints on comment users
- Generate email hashes for all new requests.
- Change close code to send from the hashed address
- Create new inbound mail queue
- Change queue code to not support deferring to "inbound mail" queue
- This is used in a lot of places. We probably want to encapsulate this in a helper instead of using the config variable directly.
- Attachment handling
- Data purge script changes - clear attachments and mail hash?
- Spam handling - clearing the hash for old requests seems like a good defense, but we should probably have a way of blocking further emails on a request. Maybe an admin-only ban button? Shouldn't clear the hash in case it needs to be re-enabled.
- Move mail handling out of the custom close workflow to be more obvious, and allow mail sending on closed requests.
- Testing code - my thoughts are a shell script which injects mail into the pipe script in the same way as the MTA would. That way it's MTA-independent, and not-MTA-dependant.
- In-tool mailbox
- Allow changing of requested username on the tool
- Remove CC to mailing list - all data is now on the tool