Allow setting e-mail headers in configuration file

[a-0-dev]

Setting email headers like X-Auto-Response-Suppress can be very useful when enabling email notifications, as you may be flooded with auto-responses from absent employees etc.

Using a noreply email address can be an alternative in some cases, but not all (for us this is not an option).

I can imagine this is a minor fix. Either, if it's only this one header, put a boolean flag in the email configuration part which, if set, makes synapse add the header to all sent emails. Or, if multiple headers are interesting, allow some yaml-list-like structure where admins can set custom headers as needed.

Especially the first option is probably a very minor fix, but would have great impact on our use of synapse.

[DMRobertson]

For reference, X-Auto-Response-Suppress seems to be something to do with Exchange: see https://learn.microsoft.com/en-us/openspecs/exchange_server_protocols/ms-oxcmail/ced68690-498a-4567-9d14-5c01f974d8b1

I think we'd probably accept a PR which adds a config option that lets you specify arbitrary headers.

Something like:

email:
  outgoing_headers:
      X-Auto-Response-Suppress: "OOF"
      X-Something-Else: "Potato"

Rough implementation plan:

1. Define new config format in the config manual. Include which version of Synapse this would be added in.
2. Parse new config from yaml in emailconfig.py.
3. Read that config in send_email.py and apply it to the headers here:
   

   synapse/synapse/handlers/send_email.py

   Lines 184 to 189 in e8519e0

   	multipart_msg = MIMEMultipart("alternative")
   	multipart_msg["Subject"] = subject
   	multipart_msg["From"] = from_string
   	multipart_msg["To"] = email_address
   	multipart_msg["Date"] = email.utils.formatdate()
   	multipart_msg["Message-ID"] = email.utils.make_msgid()

4. Write a short test case in test_email.py which proves your config is read and sent out as a header.

[clokep]

I think we'd probably accept a PR which adds a config option that lets you specify arbitrary headers.

If there's no downside to including this header, maybe we should just include it? I'd prefer less config, if possible, and just use good defaults.

[DMRobertson]

That's fair. I was thinking of not wanting to block further "can we also send this header?" requests on implementation work.

It looks like X-Auto-Response-Suppress: All is what we need? That's easy enough to do, I may as well just PR it now.

[domrim]

there is a RFC with recommendations regarding "Automatic Responses to Electronic Mail": https://datatracker.ietf.org/doc/html/rfc3834

I just quickly read it, and it states

Automatic responses SHOULD NOT be issued in response to any message which contains an Auto-Submitted header field (see below), where that field has any value other than "no".

It may also be good to include the "Microsoft-Header" X-Auto-Response-Suppress: All.
The RFC also mentions the Precedence Header (but also states it gets ignored very often), also the List-Id Header may be a part of the solution to prevent auto-responses.