John:
> If these are spam, then: https://wiki.roundup-tracker.org/AntiSpam and
> https://wiki.roundup-tracker.org/SpamBayesIntegration may be useful.

They seemingly are not, which is why I thought it worth raising this issue in
the first place. QQ mail, with its numerical local parts, seems to be one of the
most popular domestic Chinese email providers.

John:
> However William, you said "creator" reports a problem, but you shouldn't
> (AFAIK) be able to set creator from the web interface (raises an error as a
> protected property)

You are correct. I mixed it up with "initiator", a custom Link to user in our
schema, when drafting the initial email. I'll set try_id_parsing="no" on initiator
and nosy in our schema for now.

John:
> William, where were you looking for info on solving your problem?

https://www.roundup-tracker.org/docs/reference.html. try_id_parsing is described
there, but the docs say IssueClass automatically includes nosy, so I wrongly
assumed its attributes couldn't be changed. A note next to that sentence saying
the built-in properties can be redefined in schema.py would have saved me.

Ralf:
> Maybe we can create a configurable template for user creation via
> mailgw. This could add a prefix or suffix and/or mandate the use of the
> full email address for the username.

John:
> I suggest adding a `_try_id` property (default True) to class Class

I'm not sure which way forward is best. A class-level try_id_parsing would fix our
case with a couple of lines in schema.py, while a mailgw username template would
avoid creating ambiguous usernames in the first place. What I want to underline
is that addresses in this format are in active use and in many cases completely
legitimate. Since the stock templates break on them out of the box, I think it's
worth tracking either way.