On May 17, 2007, at 5:47 PM, Jordan K. Hubbard wrote:
On May 16, 2007, at 5:12 PM, James Berry wrote:
Following discussion with several of you, and more thought, my thinking is now:
(1) Obfuscate plain text email addresses by using the form:
- tld/domain/username user@bar.com ==> com/bar/user
- if there are multiple components in the hostname, only the dot before the tld is turned into a slash: user@foo.bar.com ==> com/foo.bar/user
- If the domain/tld is macports.org, then it may be dropped: user@macports.org ==> user
This kind of begs the question: What's the point of these fields again?
Is it to report bugs? I suspect not, since we have a bug tracking system for that already and if you're going to contact the maintainer directly then you're short-circuiting the bug reporting mechanism and will probably just get a nice reply saying "please file a bug report" if the maintainer is as busy as most folks anyway.
Is it for port maintainers to talk to other port maintainers? If so, we could just as easily keep this information in a side database and have the maintainer field in the portfile contain some sort of identifier that's purely unique to the macports project and doesn't even need to look like an email address - it could be a hash of someone's account record.
Needless to say, in either case we could also have a port command which did the right thing with the information to preserve ease of use. "port bug" to automatically open and jump into a new bug report, "port feedback" to talk to the maintainer. Since you've now front-ended the process, there's no need to make the Portfiel fields even vaguely comprehensible to a spammer.
Thoughts?
Hi Jordan, Sure, I agree in principle that we're heading in a direction that makes what you suggest possible. And this proposal does cover part of that: if somebody has a macports.org account, they can just use the user name portion of their email address. But we need to bridge the gap between the now (when we don't have any good way for people to get accounts if they're not committers) and the fact that most of the maintainer email addresses in those files don't belong to committers....and we'd like to find a quick and easy way to mangle them out of sight of some of the spammers. So can we do more with a more elaborate system? Sure. But rather than spend a lot of time on this issue _right_now_, especially when those systems are still taking shape, I'm looking for a quick fix, to keep more addresses out of the hands of spammers, and some sort of mangling seems like an easy way thing to do without dwelling too much on this problem while there are other more critical things to solve. James
- Jordan