process-mail dies on malformed email addresses

[Aaron Bentley]

If the To or CC header of an email contains entries that lack an '@', an oops like OOPS-1803C4636 will result.

Such emails are unlikely to be generated by users, because normal mail programs usually determine the SMTP TO from the user-entered To, CC and BCC values, and copy them into the To and Cc headers. The email that produced this oops was spam.

This bug could be fixed by making processing more tolerant of invalid email addresses, or by using X-Original-To instead of To+CC. X-Original-To will always be a valid address, since it's inserted by the mail delivery system.

[Gary Poster (gary)]

See RT 37768 re X-Original-To

[Robert Collins (lifeless)]

We really don't want process-mail dying, so this meets the oops policy.

[Martin Pool (mbp)]

As well as the specific case mentioned here, there are also many failures due to unicode errors, eg

2012-03-20 22:00:44 ERROR An exception was raised inside the handler:
http://launchpadlibrarian.net/97631604/245b4198-72d8-11e1-a8a6-001e0bc3957e.txt
 -> http://launchpadlibrarian.net/97631605/nWgbd1SJsILyTRyy9pThN07NLlx.txt ('mar\<email address hidden>' is not US-ASCII)

Many of the ones I've looked at seem to be spam and perhaps they really are malformed, but that probably constitutes an expected error and shouldn't be an oops.

There might be other cases where the encoding is actually valid and we're reading it wrong.