Emails from Sydent should include headers that enable automated bounce and complaint handling

[Ben Banfield-Zanin]

Description:

Various email providers require you to keep your bounce & complaints rates low to keep being able to sending through them. Various providers also provide reports or feedback on which emails have bounced or been complained about. For low traffic identity servers it maybe possible to handle these reports manually, but it is less feasible for high traffic identity servers so there should be automation.

Proposal:

• Each and every email sent via Synapse includes 2 emails headers: 1 with a URL to an API indicating that this email bounced, 1 with a URL to an API indicating that this email was complained about
  • The URL should include enough parameters to provide the context (e.g. sender MXID, email type) that would allow Sydent to handle the bounce / complaint report
  • Alternatively at sending time, Sydent could store the context against message-id in the email and the API provides that message-id back
• Identity server administrators could setup a system that automatically processes bounce / complaint reports from the email provider and call the appropriate API
• On the API being called Sydent performs appropriate actions. The appropriate actions likely differ per report type and per email type and would require discussion, e.g.:
  • For complaints about being invited to a room we may want to block further attempts to that email address for that room
  • For complaints about email address verification emails we may either not want to block at all or just block for a short period of time

[reivilibre]

Alternatively at sending time, Sydent could store the context against message-id in the email and the API provides that message-id back

Assuming these headers can end up in someone's inbox, this would be much more preferable since otherwise you open yourself up to someone sending the API request themselves with someone else's MXID and attempting to deny them the ability to send e-mail invites. If the message ID is unpredictable then that closes this hole.

[Ben Banfield-Zanin]

I had been wondering about the parameters just being a single base64 encoded blob that's signed by the IS's signing key to prevent modifications. However I don't super care about the implementation more that some functionality exists that can automatically handle these reports :)