I can assist you with this matter. When TeamDynamix creates customer records from an email address, this is because it has not matched that email on any of the 3 email fields on any existing User or Customer record in your tenant. This email came in with the FROM address set as firstname.lastname@example.org. That email was not in the system, so it created an account for that email because you enabled the setting to allow creation. I cannot say as to why it came in from the @uwaterloo.ca address, perhaps the user sent it from the wrong alias/domain in their mail client/device? But regardless, whatever the FROM address is on the email we received (in the actual email message headers), that is what is going to get used for matching and customer creation. We have no way to know on our end that the email came from an alias.
Secondly, reply tokens are "scoped" to the actual email address that is notified from the ticket. If the user replies back from a different address than the token is for, that is why that message comes into play. The below KBs talk about how reply-by-email work in some detail, so refer to those for more details.
The short answer is that we recommend only using a single address when communicating back and forth with TeamDynamix. If you are switching between email aliases/address domains, that is going to throw off the reply token and you will get those proxy situations.
This is definitely something we have heard about before from other customers. Typically they are requesting that we offer a way to disable the validation that replies are from the same address as the system notified from the technician. Some solutions suggested include only validating that the reply address has a token and is on a user account in the system. If that is the case, allow it through and mark it as the record the email address is for. This would pose some potential phishing issues though if someone were attempting to spoof replies as someone else in the organization (think pretending to be a director or CXO and granting authority to do something). That is why currently we err on the side of breaking the reply chain and putting in a warning when this happens. If you would also like to see this behavior changed, I would recommend submitting an enhancement ticket here to +1 market evidence for a change:
If there is anything else I can do to assist, let me know.