Empirically, we only get these for malformed emails where the charset
specified in a message part header does not match the true encoding of
the part. I checked what the resulting Zulip looked like for the
original offender, and it looked find with ignoring errors.
(imported from commit ac6ba65b611cb22d4ec547b75a585abce6fc50b0)
The overall message charset may be null or not match the part's
charset. Even though it's unclear from the documentation,
experimentally using the charset for a message part seems to give you
the charset even for non-multipart emails.
(imported from commit 0e1d23073f4c53041f9760e66a6635f8a94893d1)
This will allow mail with an implicit destination (mailing lists, complex
forwarding) to be received by our system.
See http://support.google.com/a/bin/answer.py?hl=en&answer=2368151 for
documentation of Google's behaviour that adds this header.
(imported from commit f8fd500e3c27e12af5941c63c91d5c796a2cd24a)
Previously the email gateway had to be the only address in a recipient
field or we'd mis-parse the recipient.
This commit also makes the mirror correctly handle addresses of the
form "Jessica McKellar <jesstess@zulip.com>".
(imported from commit 7435f2b59b8f47dc599cc869f64597a730af7d12)
The mirror will use INBOX when deployed and Test locally. Send an
e-mail to the Test mailbox by including the word "localhost" in the
subject; a GMail filter will place it in Test on receipt.
(imported from commit bacf9a9554c8c5e1f3ec8497761edf2c15d3745d)
For now, just do this, and we'll reach out to realms having trouble
manually. We may eventually need to automatically reply to the e-mail,
reach out to a realm admin, etc.
(imported from commit 5c5ac354066f9e9be3fb928e1f8801613c22c1ac)