diff options
author | Konstantin Ryabitsev <konstantin@linuxfoundation.org> | 2020-12-28 13:04:02 -0500 |
---|---|---|
committer | Konstantin Ryabitsev <konstantin@linuxfoundation.org> | 2020-12-28 13:04:02 -0500 |
commit | f7622a9c8d5ad88c199e4151d50510285b6c7aeb (patch) | |
tree | 6fa529fd15c0717690f17269a01c6244cc80e29b /COPYING | |
parent | ba02bab54366ef4a90eb9405e4d64a9e33c3fd82 (diff) | |
download | b4-f7622a9c8d5ad88c199e4151d50510285b6c7aeb.tar.gz |
Save to/cc headers as-is for tracking
If we clean the to/cc headers to get rid of all unicode escaping, we run
into a Python bug that is unable to properly parse addresses, e.g.:
In [5]: from email import utils
In [6]: utils.getaddresses(['foo <foo@bar.com>'])
Out[6]: [('foo', 'foo@bar.com')]
In [7]: utils.getaddresses(['Shuming [范書銘] <shumingf@realtek.com>'])
Out[7]:
[('', 'Shuming'),
('', ''),
('', '范書銘'),
('', ''),
('', 'shumingf@realtek.com')]
If we store the headers as-is from the original message, we are less
likely to run into this bug, as all non-ascii sequences should be
qp-escaped in the original headers:
=?big5?B?U2h1bWluZyBbrVOu0bvKXQ==?= <shumingf@realtek.com>
This doesn't fix the underlying bug in Python, but works around it.
Reported-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
Diffstat (limited to 'COPYING')
0 files changed, 0 insertions, 0 deletions