(Were you looking for the Vocation Server proposal?)
To provide to email users a facility which automatically sends responses to selected messages.
Email auto-responders (of which the UNIX vacation program is the canonical example) allow email users to have selected incoming email messages automatically responded to by sending a prepared message to the original sender. In this way users can notify anyone attempting to contact them that they are on vacation, out sick, or otherwise unable to personally read and respond to their email.
Certain checks are made to ensure that incoming messages were sent to the user specifically (rather than to a mailing list the user happens to be on, for example) to reduce the frequency of inappropriate auto-responses. A record of who has been responded to is maintained for each user so that only one auto-response is sent to any given original sender during a user-specified time period.
The service consists of:
Any DCI user; i.e. anyone with a valid email.unc.edu mail address.
One reason often cited for campus groups running their own email servers is the ability to use the services of some auto-responder like vacation. In order to facilitate these groups moving to ATN's email server, we feel compelled to offer appropriate similar functionality.
There are other auto-responders available. However, our email infrastructure does not lend itself well to the standard vacation implementation, largely because of security concerns. (Specifically, having the email daemon run arbitrary programs on behalf of a user whenever messages arrive is a practice easily exploited by those inclined away from benevolence.)
More to the point, however, is that most vacation implementations simply don't scale beyond a moderate number of users on a single host -- limits which our DCI have long since exceeded.
Further, such auto-responders generally require a user to login to a UNIX host, whereas we find a diminishing proportion of our email users use the login nodes to manage their email. They prefer instead to run mail clients on remote machines. For these users, a Web interface is a much more natural alternative.
Documentation is an integral part of any service implementation. The Web interface should have click-able links to full user documentation. This same text should be adequate for those providing technical assistance. On-screen text in the Web interface should provide enough guidance for anyone vaguely familiar with the auto-responder concept to run it without being surprised.
System administration should be possible for any sysadmin familiar with running sendmail. Emergency procedures are the same as those for other UserID-related Web services on bes. System documentation should follow the guidelines set forth by the Director of Academic Systems in ATN Production Services Standard Operating Procedures [Knott, 1998].
| 1999/11/01 - 11/17 | Complete coding, conversion from test system to production implementation. |
| 11/03 - 11/17 | Write user level documentation. Submit to Doc group for editing. |
| 11/15 - 11/17 | Documentation created for system administration and maintenance purposes. |
| 11/17 - 12/01 | Open to ATN staff for testing purposes. |
| ??? - | Feedback, performance evaluated. Further decisions on production deployment considered. Revisions and testing to programs and documentation as deemed necessary. |
| 12/08(?) | Production deployment |
Use of the vacation server falls under the guidelines laid out for email and for ATN UserIDs in general.
Free! Unlimited updates available on a whim.
Minimal. Though we don't know how many people will use the service, we expect initially there will be reasonably low numbers. This is by design, as we don't intend to actively promote its use until we've had a chance to evaluate server load and system scalability.
The Web interface is being developed and will be deployed on bes, which acts as the host for all our authenticated UserID-related CGI applications. The vacation server machine is an Intel-based Linux box (hapi.isis.unc.edu), though the services it provides could easily be moved to any production UNIX host running sendmail and AFS. Disk requirements are minimal.
There has been discussion of limiting initial access to faculty and staff, thereby eliminating a potential flood of requests when students go away on breaks. We don't have enough information on either potential demand or system performance to make a rational decision on this point.
The ITRC will need to be familiar with the basic principles of email forwarding and email aliases. With that understanding, the operation of the Web interface should be straightforward. Even if this service is offered to the entire campus, there likely would be only a small number of questions, and they will probably be simple ones.
Most of the tasks required to establish this service have been or will be performed by Todd Lewis. The scope of the ongoing software maintenance and administration is roughly equivalent to that required for the sendpage.unc.edu system/service. Further development falls into the DANDE group's domain (which, coincidentally, is where Todd works).
The Core Technologies Group would provide assistance should it become necessary to move the service to another physical box, but the similarity of the architecture to that of the sendpage service, along with limited staffing in Core Tech, justifies leaving the two systems in DANDE's domain at this time.
The Business Office should not be affected.
The Control Center may monitor the system and/or receive calls reporting service problems.
The ITRC will likely receive some calls about the service. Most of these questions will be addressed in the available on-line documentation. Calls with technical issues may be referred to DANDE's CGI people, in the same fashion as UserID Creation or sendpage issues are handled presently. Likewise, administrators will notify the ITRC if there is scheduled or known down-time.
The service requires a substantial amount of system administration and programming time during implementation. Once up and running, it should require only routine, mostly automated, monitoring.
Usage statistics will be important in determining the usefulness of the service as well as other information needs.
User feedback and anecdotal information from the ITRC will be crucial for properly balancing perceived needs with available development resources in the future.
Todd M. Lewis
1999/11/01
http://www.unc.edu/~utoddl/vacationserver.html