Path: utzoo!attcan!uunet!lll-winken!ncis.llnl.gov!helios.ee.lbl.gov!pasteur!agate!bionet!csd4.milw.wisc.edu!leah!itsgw!rpi!sun.soe.clarkson.edu!batcomputer!cornell!uw-beaver!blake!ogccse!littlei!omepd!merlyn From: merlyn@intelob.intel.com (Randal L. Schwartz @ Stonehenge) Newsgroups: comp.mail.sendmail Subject: vacation processing (was Re: Still trying to get smart routing working.) Summary: :-) Message-ID: <4084@omepd.UUCP> Date: 20 Jan 89 20:40:14 GMT References: <412@execu.UUCP> <7094@xanth.cs.odu.edu> <412@avsd.UUCP> <3656@phri.UUCP> Sender: news@omepd.UUCP Reply-To: merlyn@intelob.intel.com (Randal L. Schwartz @ Stonehenge) Organization: Stonehenge; netaccess via BiiN, Hillsboro, Oregon, USA Lines: 32 In-reply-to: roy@phri.UUCP (Roy Smith) In article <3656@phri.UUCP>, roy@phri (Roy Smith) writes: | In article <412@avsd.UUCP> childers@avsd.UUCP (Richard Childers) writes: | > Always use /usr/lib/aliases, and concentrate all your network problems into | > one place. .forward is an obsolete mechanism from a decade ago. | | I'd almost agree with that, except that it would be nice if people | could set up things like vacation on their own (do you, as postmaster, | really want to change /usr/lib/aliases every time somebody goes on vacation | or comes back?) Of course, the alternative is to have sendmail (or | whatever MTA you use) deal with vacation processing itself. Yeah, that'd do it. Have sendmail deal with vacation processing itself. And, just like everything else in sendmail, it should be flexible. Maybe the user could have a "~/.vacation" file which would specify the response text (like "I'm in Siberia... back when it thaws"), and if the user wanted to do something more complicated, he/she could even *put* *the* *name* of a customized program into the text file. Now, we'd need a way of telling a program from a text... maybe if the text began with a "|", so I could have "|/usr/merlyn/vacation-response-handler"... Ooops. Nevermind. Just re-invented ".forward" (hee hee). (In case it isn't clear, I support the use of user-supplied mail-handlers, although the current scheme is bad for multiple users with the same home directory, and can lead to bad errors.) -- Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 on contract to BiiN (for now :-), Hillsboro, Oregon, USA. ARPA: <@iwarp.intel.com:merlyn@intelob.intel.com> (fastest!) MX-Internet: UUCP: ...[!uunet]!tektronix!biin!merlyn Standard disclaimer: I *am* my employer!