david@wubios.wustl.edu (David J. Camp) (01/30/89)
When I di a group reply, my own address is included in the Cc: list. Unix mail is smart enough to prevent this, elm should too. -David- -- Bitnet: david@wubios.wustl ^ Mr. David J. Camp Internet: david%wubios@wucs1.wustl.edu < * > Box 8067, Biostatistics uucp: uunet!wucs1!wubios!david v 660 South Euclid Washington University Medical School Saint Louis, MO 63110
dave@csd4.milw.wisc.edu (David A Rasmussen) (02/14/89)
From article <290@wubios.wustl.edu>, by david@wubios.wustl.edu (David J. Camp): > When I di a group reply, my own address is included in the Cc: list. > Unix mail is smart enough to prevent this, elm should too. > This is really a religious issue. I have taught introductory unix courses at my site, and people always WANT to be included in the list, even if they send it out. (then I have to explain to them they have to take our editor course before they can add "metoo" to their .mailrc file - we start out with mail and some later see the light with elm ;-)) I suppose elm could have a "metoo" option. I don't want it though so I'm not going to write it up :-) -- Dave Rasmussen c/o Computing Services Division @ U of WI - Milwaukee Internet: dave@csd4.milw.wisc.edu Uucp: uwvax!uwmcsd1!uwmcsd4!dave {o,o} Any opinions expressed are my own. Now, for a limited time, they can be yours too, for the incredible price of only $19.95.
rob@pbhyf.PacBell.COM (Rob Bernardo) (02/14/89)
In article <937@csd4.milw.wisc.edu> dave@csd4.milw.wisc.edu (David A Rasmussen) writes:
+From article <290@wubios.wustl.edu>, by david@wubios.wustl.edu (David J. Camp):
+> When I di a group reply, my own address is included in the Cc: list.
+> Unix mail is smart enough to prevent this, elm should too.
+>
+This is really a religious issue. I have taught introductory unix courses
+at my site, and people always WANT to be included in the list, even if they
+send it out.
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.
--
Rob Bernardo, Pacific Bell UNIX/C Reusable Code Library
Email: ...![backbone]!pacbell!pbhyf!rob OR rob@pbhyf.PacBell.COM
Office: (415) 823-2417 Room 4E750A, San Ramon Valley Administrative Center
Residence: (415) 827-4301 R Bar JB, Concord, Californiataylor@hplabsz.HP.COM (Dave Taylor) (02/14/89)
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. For example, I could have alternatives = postmaster@digital in my 'elmrc' file, in which case a message addressed to: From: Mike McGuire <mcguire@columbia.edu> To: postmaster@digital.dec.com, john@hiscomputer.domain Cc: taylor would have a group reply list of: john@hiscomputer.domain, taylor, mcguire@columbia.edu since it would recognize "postmaster@digital" as an alternative for me. (actually, I think it also recognizes by default the trivla user@hostname and hostname!user pairs...) From the far corners of the earth, -- Dave Taylor Intuitive Systems Los Altos, CA guest of HP Labs
david@wubios.wustl.edu (David J. Camp) (02/17/89)
In: article <4691@pbhyf.PacBell.COM> you write:
:>In article <937@csd4.milw.wisc.edu> dave@csd4.milw.wisc.edu (David A Rasmussen) writes:
:>+From article <290@wubios.wustl.edu>, by david@wubios.wustl.edu (David J. Camp):
:>+> When I di a group reply, my own address is included in the Cc: list.
:>+> Unix mail is smart enough to prevent this, elm should too.
:>+>
:>+This is really a religious issue. I have taught introductory unix courses
:>+at my site, and people always WANT to be included in the list, even if they
:>+send it out.
:>
:>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.
:>--
It seems reasonable that if you want a copy of outgoing mail, to enable
the savemail= option. That makes it unnecessary to address mail to
yourself, because you are keeping a copy anyway.
-David-
--
Bitnet: david@wubios.wustl ^ Mr. David J. Camp
Internet: david%wubios@wucs1.wustl.edu < * > Box 8067, Biostatistics
uucp: uunet!wucs1!wubios!david v 660 South Euclid
Washington University Medical School Saint Louis, MO 63110
--
Bitnet: david@wubios.wustl ^ Mr. David J. Camp
Internet: david%wubios@wucs1.wustl.edu < * > Box 8067, Biostatistics
uucp: uunet!wucs1!wubios!david v 660 South Euclid
Washington University Medical School Saint Louis, MO 63110solomon@gjetost.cs.wisc.edu (Marvin Solomon) (02/17/89)
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
rob@pbhyf.PacBell.COM (Rob Bernardo) (02/18/89)
In article <7190@spool.cs.wisc.edu> solomon@gjetost.cs.wisc.edu (Marvin Solomon) writes:
+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?
The 'r' (reply) replies to the sender of the message; the 'g' (group reply)
replies to the sender *and* the recipients of the message.
Would you really want to reply to the secondary ("Cc:) recipients and the
sender, but *not* to the primary ("To:) recipients of the message as well?
Furthermore this wouldn't solve the problem of mailing yourself a message
in doing a group reply because you might be in the cc-list, not the to-list.
--
Rob Bernardo, Pacific Bell UNIX/C Reusable Code Library
Email: ...![backbone]!pacbell!pbhyf!rob OR rob@pbhyf.PacBell.COM
Office: (415) 823-2417 Room 4E750A, San Ramon Valley Administrative Center
Residence: (415) 827-4301 R Bar JB, Concord, Californiazeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (02/18/89)
>"right thing". Rfc 822 requires that all addresses have an unambiguous >context-independent meaning. On any of our local hosts, "solomon" means >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 Elm does needs an option to fully qualify all addresses. People using elm + smail 2.5 have problems with mail going out with things like "Cc: jon" which confuses some sites. -- Jon Zeeff zeeff@b-tech.ann-arbor.mi.us Ann Arbor, MI mailrus!b-tech!zeeff
rob@pbhyf.PacBell.COM (Rob Bernardo) (02/19/89)
In article <5121@b-tech.ann-arbor.mi.us> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes:
+>"right thing". Rfc 822 requires that all addresses have an unambiguous
+>context-independent meaning. On any of our local hosts, "solomon" means
+>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
+
+
+Elm does needs an option to fully qualify all addresses. People using
+elm + smail 2.5 have problems with mail going out with things like "Cc: jon"
+which confuses some sites.
If I understand you correctly, I don't think that would work.
When ELM is sending a message, addresses occur in two places: (1) in
the header lines (To and Cc) and (2) in the command line for ELM's
execution of the mail transport agent. What it sounds like ELM would
have to do, in this proposal, is expand the addresses in the headers
according to the smail alias database, but leave them unexpanded in
the command line, where smail would deal with them. There's something
very unmodular about that: the expansion of the aliases should be done
either one place or the other, esp. considering that smail and ELM
are not part of the same package.
It seems to me that if smail 2.5 has it's own alias database and it
translates the address "jon" into something more universally meaningful,
it is up the smail to rewrite the headers of the message as well.
--
Rob Bernardo, Pacific Bell UNIX/C Reusable Code Library
Email: ...![backbone]!pacbell!pbhyf!rob OR rob@pbhyf.PacBell.COM
Office: (415) 823-2417 Room 4E750A, San Ramon Valley Administrative Center
Residence: (415) 827-4301 R Bar JB, Concord, Californiazeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (02/19/89)
>In article <5121@b-tech.ann-arbor.mi.us> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: >+Elm does needs an option to fully qualify all addresses. People using >+elm + smail 2.5 have problems with mail going out with things like "Cc: jon" >+which confuses some sites. > >If I understand you correctly, I don't think that would work. > >have to do, in this proposal, is expand the addresses in the headers >according to the smail alias database, but leave them unexpanded in While there are problems with what you mention, I'm only asking that elm fully qualify local addresses with the local site name. This doesn't require any lookup in a smail alias file - just appending thissite.domain to anything not containing ! or @. I've accomlished this here by modifying the elm sources to strip out the To: and Cc: lines and letting smail put them back in. It's not perfect (Cc vs To: info is lost), but it's better than having mail go out with "To: jon" header lines in it. -- Jon Zeeff zeeff@b-tech.ann-arbor.mi.us Ann Arbor, MI mailrus!b-tech!zeeff
jim@tiamat.fsc.com (Jim O'Connor) (02/20/89)
In article <4726@pbhyf.PacBell.COM>, rob@pbhyf.PacBell.COM (Rob Bernardo) writes: > In article <5121@b-tech.ann-arbor.mi.us> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: > + > +Elm does needs an option to fully qualify all addresses. People using > +elm + smail 2.5 have problems with mail going out with things like "Cc: jon" > +which confuses some sites. I came across this, before installing elm, when switching from smail2.5 to smail3. Headers which looked like "To: jim" under smail2.5 were suddenly showing up as "To: jim@fsc2086.fsc.com" under smail3. Since "jim" was getting mapped to "jim@tiamat.fsc.com" in the alias file, I wasn't sure I liked this. But as the smail3 author pointed out to me, smail3 was doing this correctly, according to RFC822. Apparently, it's smail2.5 that is not being fully compatible by not qualifying any address that has not already been qualified. > If I understand you correctly, I don't think that would work. > > It seems to me that if smail 2.5 has it's own alias database and it > translates the address "jon" into something more universally meaningful, > it is up the smail to rewrite the headers of the message as well. Even if "jon" isn't mapped to some other address, as I understand it, it is the responsibility of the delivery agent to fully qualify all addresses. smail3 performs that function very well. ------------- James B. O'Connor jim@tiamat.fsc.com Filtration Sciences Corporation 615/821-4022 x. 651 *** Altos users unite! mail to "info-altos-request@tiamat.fsc.com" ***
gertjan@atcmp.nl (Gertjan Vinkesteyn) (02/22/89)
I made some fixes to this problem including the Cc: and Reply-To: fields wanna have it? I can post it if there is enough enthousiasm for it. -- UUCP and other network )\/( ..!hp4nl!kunivv1!atcmpe!gertjan connections via mcvax )/\( gertjan@atcmp.nl (internet) This note does not necessarily represent the position of AT Computing BV