Malte, the "zz-email-not-unique" seems like a nice dotlrn-way of handling the change.
It is not really necessary to understand how people collectively manage a resource, such as one email address --just that it happens all the time all over the world. Why do we need to know if people use 2+ clients for 1 email, or a web interface, filters and maybe a little cooperation in manually managing emails?
OpenACS should consider it part of the behavioral norm as much as any other community user variation.
Constraints for corporate/legal/privacy reasons does not hold. The first person who registers to an OpenACS site using a shared email results in similar circumstances to when multiple parties register with the same email. In each case, an email potentially destined to one person may be read by more than one. How can the site owners be responsible for that?
Certainly ecommerce should have strict requirements. But might it be reasonable to assume that those sharing an email might also be sharing other private info?
How to enforce privacy when multiple parties share the same email?
Use a web-based intra-OpenACS community email package to convey email subject/content, and send a generic notification to the user's email address. I believe a package like that is in development.
Maybe the zz-email-not-unique code could be added to the intra-site-messaging package.
Sites that want to keep the constraint might be satisfied with by just creating a parameter somewhere that automatically sets username to email_address on registration etc.
