Keep contact address on file for accounts

[adehnert]

It would be useful for a couple reasons to have email addresses on file for lockers. signup could prompt for this information and store it in LDAP, and then pony could allow further changes.

Uses of this data could include:

• reporting compromised apps
• reporting upgrade failures of apps
• possibly automatically poking people whose apps are generating a lot of error_log spew
• subscribing users to scripts-announce or informing certain users (old Mediawiki's, say) of upgrades

There is a consensus that "forwarding mail of people not signed up for mail_scripts" is *not* a good use, and those people should bounce.

There's also a question of how to initially populate the database, though I think that should be out-of-scope for this ticket.

[andersk]

From my zephyrs:

We absolutely want this in some form. I think the biggest worry before was how to force groups to keep their contact address updated.

The reason that scripts currently uses the locker root’s admin ACL for access instead of some other ACL (e.g. some ACL on web_scripts or a separately maintained list) is that we couldn’t come up with anything else that groups wouldn’t forget to update with transfers of locker control.

I want the right answer to be “email the ACL”, but for many lockers the ACL is too big (e.g. system:cwisfac, or every member of a large student group).

Maybe one answer is to require the contact address to be a user or list that has admin bits on the root of the locker, monitor this condition daily, and yell at someone as soon as it ceases to be the case.

We may need to start yelling sooner, to try to catch contact lists with only users who are soon to be deactivated.

[jdreed]

We may need to start yelling sooner, to try to catch contact lists with only users who are soon to be deactivated.

There's no reason we couldn't involve Scripts in the deactivation process. When the doom list is first generated in November, something could check it for people who are on Scripts ACLs, and either contact them, or only contact them if they're the only person on an ACL, or whatever.

[achernya]

After talking with Anders and Mitch for a bit after the meeting, we came up with the following idea as a starting point:

• Create a web form where users can submit a contact address
• Write an automated script that does some heuristic to figure out what are potential contacts for group lockers
• Use the results of this script to send a mass-mail to users to fill out the web form.
• Potentially: Run this script periodically on lockers that do not have a user-set contact to poke them into doing so, also taking into permission changes

We also discussed if we should display this email on error pages for lockers, and quickly ran into the problem of privacy: we don't want outsiders to be able to harvest email addresses by crafting error pages. One possible solution to this was creating fake addresses that would be forwarded by Scripts, but this is problematic since it opens us up to being considered a SPAM gateway (maybe) so that is a separate problem to solve.

[adehnert]

After slightly more discussion on zephyr, we are okay with also making signup-minimal prompt you if you don't have an address set, though we don't require it.

The finer points of whether or not, and how, to display contact addresses was discussed further and no real consensus seemed to be reached. (-i trac-#193 has more info.)

[adehnert]

There's a lot of neat stuff that could be done with this, and I keep being sad we don't have it, so I'm taking the liberty of bumping the priority.

[ezyang]

We'll need to add an objectType more descriptive than posixAccount, unless we decide to abuse gecos or description for it. It might be simpler for us to abuse them that way: maybe use description?