> OK, I'm not really understanding the point of "..." in your post, but > it's probably irrelevant.
Yes, it's irrelevant ;-) > It seems that the issue is that > email.Utils.parseaddr doesn't seem to be a realiable address parser, is > that correct? It's not an issue with this particular point. I've encountered some unfixed issues while developping the notification stuff and the unit tests, and found some still open points in the various ML I read by that time. > If so, has there been any attempt at fixing email.Utils.parseaddr? I do not follow this topic, to be honest. Even if it is fixed, it's not really relevant: I do not want to verify data formatted by one library with the very same library. The notification implementation uses the email library (as it should - I hope), but the unit tests do not and I think it's better this way. If the email implementation changes for some reason, I hope the notification unit tests will fail. I prefer to understand and fix the tests - if they fail rather than to let Trac sends invalid emails ;-) Cheers, Manu _______________________________________________ Trac mailing list [email protected] http://lists.edgewall.com/mailman/listinfo/trac
