Errors thrown in Gettor if "To:" address field doesn't match gettor@tp.o
I was checking the logs for errors and found a bunch of the following failures:
2020-04-29 07:57:51+0000 [email parser] Error while parsing email content: [Failure instance: Traceba
ck: <class 'KeyError'>: 'command'
/usr/lib/python3/dist-packages/twisted/internet/defer.py:311:addCallbacks
/usr/lib/python3/dist-packages/twisted/internet/defer.py:654:_runCallbacks
/usr/lib/python3/dist-packages/twisted/internet/defer.py:1613:unwindGenerator
/usr/lib/python3/dist-packages/twisted/internet/defer.py:1529:_cancellableInlineCallbacks
--- <exception caught here> ---
/usr/lib/python3/dist-packages/twisted/internet/defer.py:1418:_inlineCallbacks
/srv/gettor.torproject.org/home/gettor/gettor/parse/email.py:250:parse_callback
].
I noticed this is caused by parse
returning an empty request here which only happens if the "To:"
address doesn't match gettor@torproject.org
exactly. After doing more looking, I found the following mismatched addresses:
- "To:" address is just blank
- gettor+[lang code]@torproject.org (e.g., gettor+en@torproject.org).
- [random user]@gmail.com
- [user]@[random domain].[random tld]
(where random = no known connection to gettor, not cryptographically random :))
For the blank and random addresses, I wonder how this is happening. Perhaps we're relying on information that's not consistently configured correctly on user email clients?
For addresses of the form gettor+[lang code]@torproject.org, it looks like gettor used to work by accepting emails of this form to determine localization (see https://twitter.com/get_tor/status/754126179506982912). Perhaps we shouldn't be throwing these out, even though we no longer do localization this way. We could use these language codes once we get around to localizing gettor messages as an optional step.