Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cwjcc!hal!nic.MR.NET!umn-d-ub!uwvax!gjetost!solomon From: solomon@gjetost.cs.wisc.edu (Marvin Solomon) Newsgroups: comp.mail.elm Subject: Re: group reply includes sender Message-ID: <7190@spool.cs.wisc.edu> Date: 17 Feb 89 12:03:48 GMT References: <290@wubios.wustl.edu> <937@csd4.milw.wisc.edu> <4691@pbhyf.PacBell.COM> <2910@hplabsz.HPL.HP.COM> Sender: news@spool.cs.wisc.edu Reply-To: solomon@gjetost.cs.wisc.edu (Marvin Solomon) Organization: U of Wisconsin CS Dept Lines: 65 In article <2910@hplabsz.HPL.HP.COM> taylor@hplabs.HP.COM (Dave Taylor) writes: >Referencing a question about group reply including the recipient, Rob Bernardo >comments: > >> Actually ELM is advertized as removing the user from the to and cc lists >> of the original message when doing a group reply. I haven't investigated >> this bug, but I suspect ELM might be having a hard time telling if >> an address is to the user or not - it would involve a great deal of parsing >> and understanding of all manner of address formats. > >As a matter of fact it is quite a bit more simple than that; in the >users "elmrc" file there is a field called "alternatives" which is >intended to point to a list of strings that are of an almost arbitrary >format and are used for just this purpose; if an address in the list >built internally for a group reply completely contains one of the listed >alternatives for the user, then it is removed from the final list that >the message is sent to. Actually, it's a bit more complicated than that. In our environment, we have approximately 130 hosts. /usr/lib/aliases on each host has a list of about 650 aliases of the form user: user@home where "home" is the home host of the user (generally a workstation). Thus I can mail to a local user by simply typing his login name, without knowing his current home. However, that means there are potentially 130 different names that all mean "solomon". Suppose a user at cheddar.cs.wisc.edu (since this is Wisconsin, most of our workstations are named after cheeses) sends a message to me with a Cc: to joeblow. He types "solomon" for the "To:" line and "joeblow" on the "Cc:" line. Sendmail on his machine "canonicalizes" the addresses by tacking "@cheddar.cs.wisc.edu" on the end of each one [see comments below*]. If I type 'g', "solomon@cheddar.cs.wisc.edu" is included in the "Cc:" line, since Elm doesn't understand that that's me. What's the solution? Actually, there are two solutions, either of which would solve my problem, but both of which are probably worth implementing. The simple solution is to have a option not to include the "To:" item in the "Cc:" list of a 'g' reply. In fact, I don't really understand why that's not the default. Why would anyone want it otherwise? For cases in which I'm included in the "Cc:" list of the original message, perhaps the "alternatives" list should have some simple wildcard matching feature: alternatives = solomon@*.wisc.edu *Note: Before anybody says that my problem is that our sendmail configuration is broken, let me argue why I think sendmail is doing the (or at least *a*) "right thing". Rfc 822 requires that all addresses have an unambiguous context-independent meaning. On any of our local hosts, "solomon" means me, but if a message containing "solomon" should escape our local environment, it would contain an unusable (illegal) address. Thus every piece of mail that leaves a host is "canonicalized" by taking "@localhost" on the end of all addresses without @'s, where "localhost" is the *sending* host. You might argue that an address in the "To:" field should have "@destination" tacked on, rather than "@source", but that trick doesn't work for all cases in all fields containing addresses. Using "@sendinghost" works in more cases and it *is* correct, since "solomon@sendinghost" is indeed a correct address for me, valid anywhere in the universe. Since addresses without @'s are not legal in 822 headers, sendmail on his machine "canonicalizes" the addresses by tacking "@cheddar.cs.wisc.edu" on the end of each one. (This is Marvin Solomon Computer Sciences Department University of Wisconsin, Madison WI solomon@cs.wisc.edu ...seismo!uwvax!solomon