Date | Commit message (Collapse) |
|
I didn't wait until September to do it, this year!
|
|
Apparently, neither our previous address parsing code nor
Email::Address::XS recognizes local, username-only addresses
in the form of <username> (without "@host"). Without
this change, Email::Address::XS->address would return
"undef", so we need to filter it out via "grep { defined }"
It seems the cases where users email each other on the same
machine is small and public-inbox won't be able to index
addresses for those cases... Oh well :/
|
|
Email::Address::XS is a dependency of modern versions of Email::MIME,
so it's likely loaded and installed on newer systems, already;
and capable of handling more corner-cases than our pure-Perl
fallback.
We still fallback to the imperfect-but-good-enough-in-practice
pure-Perl code while avoiding the non-XS Email::Address (which
was susceptible to DoS attacks (CVE-2015-7686)). We just need
to keep "git fast-import" happy.
|
|
Some users will set their From: headers in the form of:
"<user@example.com> (A U Thor)", where their name is in
the parenthesized comment. Use that instead of the
email address, if available.
|
|
|
|
There's a lot of weird characters which show up in LKML archives
which we did not support before. Furthermore, allow spaces
before the '>' in the From: line as at least some non-spam
poster used it.
|
|
Using update-copyrights from gnulib
While we're at it, use the SPDX identifier for AGPL-3.0+ to
ease mechanical processing.
|
|
Not sure why or how I missed this before; but the common address
parsing routine we have should be more correct.
Add a test to ensure excessively quoted names don't make it
through, either.
|
|
They're uncommon, fortunately, but we make no attempt to
handle nested comments (which would open us up to things
like CVE-2015-7686) or use the comment in place of a
missing name.
|
|
It seems common for address entries to end up as:
"foo@example" <foo@example>
Avoid needlessly displaying the domain name in that case.
|
|
We may remove from_name in the future.
...And disallow quotes in email addresses.
Technically I believe they're allowed, but they're definitely
uncommon and unlikely to show up in legitimate mail.
|