syd@dsinc.DSI.COM (Syd Weinstein) (05/25/89)
Before I get inundated with postings and mail, at PL8, Elm has
a different appearance in regards to signatures. This is to allow
the built in editor to be used with signatures and to allow for
delayed determination (until send time) of which signature to use.
The signature is appended to the message, it just doesn't appear in
the editor buffer anymore.
--
=====================================================================
Sydney S. Weinstein, CDP, CCP Elm Coordinator
Datacomp Systems, Inc. Voice: (215) 947-9900
syd@DSI.COM or {bpa,vu-vlsi}!dsinc!syd FAX: (215) 938-0235phil@wubios.wustl.edu (J. Philip Miller) (05/26/89)
In article <133@dsinc.DSI.COM> syd@dsinc.DSI.COM (Syd Weinstein) writes: > >The signature is appended to the message, it just doesn't appear in >the editor buffer anymore. Anyway to know (while you are editing the outgoing message) what signature elm intends to append? -- -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* J. Philip Miller - Div of Biostat - Washington Univ Medical School phil@wubios.WUstl.edu - Internet phil@wubios.wustl - bitnet (314) 362-3617 c90562jm@wuvmd - alternate bitnet
rob@PacBell.COM (Rob Bernardo) (05/26/89)
In article <465@wubios.wustl.edu> phil@wubios.UUCP (J. Philip Miller) writes: +In article <133@dsinc.DSI.COM> syd@dsinc.DSI.COM (Syd Weinstein) writes: +> +>The signature is appended to the message, it just doesn't appear in +>the editor buffer anymore. + +Anyway to know (while you are editing the outgoing message) what signature elm +intends to append? If any of the to or cc addresses are remote, the remote signature is used. An address is considered remote if either it contains a ! it contains a @ but is not of the form logname@thishost.thisdomain One* reason for making the decision between the local and remote signature *after* editing the message is that the user can change the to or cc list after editing the message by going into the header editing screen. I.e., remote vs. local cannot be accurately determined until the message is about to be dispatched to the MTA. -- Rob Bernardo, Pacific Bell UNIX/C Reusable Code Library Email: ...![backbone]!pacbell!pbhyf!rob OR rob@pbhyf.PacBell.COM Office: (415) 823-2417 Room 4E850O San Ramon Valley Administrative Center Residence: (415) 827-4301 R Bar JB, Concord, California
phil@wubios.wustl.edu (J. Philip Miller) (05/27/89)
In article <5419@pbhyf.PacBell.COM> rob@PacBell.COM (Rob Bernardo) writes: >In article <465@wubios.wustl.edu> phil@wubios.UUCP (J. Philip Miller) writes: >+In article <133@dsinc.DSI.COM> syd@dsinc.DSI.COM (Syd Weinstein) writes: >+> >+Anyway to know (while you are editing the outgoing message) what signature elm >+intends to append? > >If any of the to or cc addresses are remote, the remote signature is used. >An address is considered remote if either > it contains a ! > it contains a @ but is not of the form logname@thishost.thisdomain > I cannot figure out how to know what the to or cc addresses are WHILE I AM EDITING THE MESSAGE. The only way that I know how to do that is to stop editing the file, go to the headers menu and figure it out from the to & cc lines displayed there. While we are on the subject, is it possible to expand the definition of local to also include other hosts in 'thisdomain' rather than just 'thishost' ? In a posting in reply to another note in this thread I indicated that one way of helping all of these problems would be to allow the user to change the name of the file that elm will include as the signature file as part of the header menu. This would allow one to then override any of these local/remote dimensions. -phil -- -*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* J. Philip Miller - Div of Biostat - Washington Univ Medical School phil@wubios.WUstl.edu - Internet phil@wubios.wustl - bitnet (314) 362-3617 c90562jm@wuvmd - alternate bitnet
rob@PacBell.COM (Rob Bernardo) (05/27/89)
J. Philip Miller writes: +Anyway to know (while you are editing the outgoing message) what signature elm +ntends to append? Rob Bernardo writes: +If any of the to or cc addresses are remote, the remote signature is used. +An address is considered remote if either + it contains a ! + it contains a @ but is not of the form logname@thishost.thisdomain J. Philip Miller writes: +I cannot figure out how to know what the to or cc addresses are WHILE I AM +EDITING THE MESSAGE. The only way that I know how to do that is to stop +editing the file, go to the headers menu and figure it out from the to & cc +lines displayed there. I'm not sure why you're saying this. ELM figures it out for you. And it figures it out after you have gotten past all opportunity to change the to list or cc list, i.e. after you enter 's' on the send menu. (Prior to that you could enter 'h' and change the to and cc headers.) That's why ELM needs to wait until this point, (which is after you edit your message), before it can accurately decide which signature file to use. This is why the old method was technically inaccurate: you could change the to list or cc list *after* ELM made its decision. +In a posting in reply to another note in this thread I indicated that one way +of helping all of these problems would be to allow the user to change the name +of the file that elm will include as the signature file as part of the header +menu. Or simply DON'T define the signature files in your elmrc, and then jsut read them in while you're in your editor. -- Rob Bernardo, Pacific Bell UNIX/C Reusable Code Library Email: ...![backbone]!pacbell!pbhyf!rob OR rob@pbhyf.PacBell.COM Office: (415) 823-2417 Room 4E850O San Ramon Valley Administrative Center Residence: (415) 827-4301 R Bar JB, Concord, California
jgd@csd4.milw.wisc.edu (John G Dobnick,EMS E380,4142295727,) (05/27/89)
From article <133@dsinc.DSI.COM>, by syd@dsinc.DSI.COM (Syd Weinstein): > Before I get inundated with postings and mail, at PL8, Elm has > a different appearance in regards to signatures. For whatever the reason this change was made, it *is* an obvious (to the user) change. I merely observe here that *some* of our users will be *extremely* upset about this -- *any* change to *anything* annoys them. Change makes them think that we, the technical support staff, are *not* doing our jobs properly, but instead are just out to gratuitously irritate them. They're wrong, of course, but they still think that way. Unfortunately, these are also the users who run the place and control the purse strings around here. Need I say more? [And now for something complete different: A serious question. Why can't the "builtin editor" append the signature file in the same manner that the "external editor" does? Spoken as by one who has not read the Elm code, as indeed I have not.] -- John G Dobnick, Elm proponent and all around good guy! Computing Services Division @ University of Wisconsin - Milwaukee INTERNET: jgd@csd4.milw.wisc.edu UUCP: <backbone>!uwvax!uwmcsd1!jgd "Knowing how things work is the basis for appreciation, and is thus a source of civilized delight." -- William Safire
rob@PacBell.COM (Rob Bernardo) (05/27/89)
In article <2654@csd4.milw.wisc.edu> jgd@csd4.milw.wisc.edu (John G Dobnick,EMS E380,4142295727,) writes:
+ Why can't the "builtin editor" append the signature file in the same
+ manner that the "external editor" does?
Actually, ELM appends the signature file and then invokes whichever
editor. The builtin editor is rather simply-minded. It basically reads
lines from standard input and writes (appends) them to a temporary file,
which becomes the text of the message to dispatch. The builtin editor
provides no mechanism for backing up or editing any previously entered
lines; all you can do is append to the message. Because of that, ELM
can not invoke the builtin editor if the message has any pre-existing
contents, such as when you forward a message or reply to a message
quoting the original message. The way ELM used to append the signature
file to the temp message text file prior ot editing, ELM could therefore
not invoke the builtin editor on the temp messsage text file.
If you were using the builtin editor, and if there were some way of it
inserting lines before the signature, rather than appending lines to the
end of the file, the pre-appending of the signature file would be
useless, insofar as the builtin editor gives you no mechanism for
editing the signature lines.
NOTE: This is simply an explanation of the code and not a defense of
the code.
--
Rob Bernardo, Pacific Bell UNIX/C Reusable Code Library
Email: ...![backbone]!pacbell!pbhyf!rob OR rob@pbhyf.PacBell.COM
Office: (415) 823-2417 Room 4E850O San Ramon Valley Administrative Center
Residence: (415) 827-4301 R Bar JB, Concord, Californiasyd@dsinc.DSI.COM (Syd Weinstein) (05/27/89)
Ok, we have another full blown feature problem here, where a bug being
fixed will break another user appearance. I cannot predict these in
advance, no matter how much you say ... but it changes the appearance,
after all, any bug fix thats not totally internal changes the appearance.
So for the moment, if you don't like the changes in patch 8, back them
out and wait out the discussion. For those of you that wondered why
I even posted that patch (and remember, I post but do not write them)
here is part of the message I sent to the elm development group today
in re solving this problem:
The signature problem is a three part problem.
Here are the three parts, and remember that the patch solved two of
them, but caused people to be upset and end up with a third.
Ok.
1. Signatures were being confused as to local/remote.
The code checks to see if the address has you domain name in it
and uses local, else it uses remote. The patch fixed this.
2. One cannot reliably decide if an address is local or remote until
after the message is complete due to allowing header changes to make
a local address remote.
The patch fixed this one. However this caused part of the problem
with seeing the signature in the editor buffer.
3. And the major item on the bug list this patch fixed: If you use
signatures you cannot use the built-in editor.
By delaying the signature code we can use the builtin editor.
Ok, just backing out patch 8 will return the old behavoir, but it will
not solve the items on the bug list. So I ask.... how does the group
desire to solve number 3.
After all, if you have a sig file and you use the built in editor,
you cannot use the built in editor and are forced to your default
external editor.
This is also a major problem. I am open to solutions.
Thus we have the mixed goal of fixing the problems on the bug list,
and in my mind (and remember thats personal opinion), this patch
did just that, fix the items on the bug list.
Also, remember, this is 2.2 patches, so grandious solutions with new
features such as a list of sites considered local will be taken
as suggestions for 2.3, not as a way to fix 2.2. The fix to 2.2 has
to be simple minded and solve the bugs, but not make major changes.
(Thus rewriting the internal editor is out for a fix to 2.2).
One possible solution is just to document that if you want signatures
you cannot use the built-in editor, but that disenfrancises a large
body of users that use the built-in editor.
So, here is a full blown item to discuss, as we also will be doing so
on the development group. I will hold off patch 9 until a solution is
reached, thus if you back out patch 8, you won't miss anything.
--
=====================================================================
Sydney S. Weinstein, CDP, CCP Elm Coordinator
Datacomp Systems, Inc. Voice: (215) 947-9900
syd@DSI.COM or {bpa,vu-vlsi}!dsinc!syd FAX: (215) 938-0235jgd@csd4.milw.wisc.edu (John G Dobnick,EMS E380,4142295727,) (05/29/89)
From article <137@dsinc.DSI.COM>, by syd@dsinc.DSI.COM (Syd Weinstein): > Ok, we have another full blown feature problem here, where a bug being > fixed will break another user appearance. [... explaination deleted...] > So, here is a full blown item to discuss, as we also will be doing so > on the development group. I will hold off patch 9 until a solution is > reached, thus if you back out patch 8, you won't miss anything. A few generalized comments. Firstly, I now understand what we are *really* talking about. (Thanks, Rob and Syd, for your messages.) The so-called "builtin editor" is *not* an editor at all, but rather a "text insertion mode". The terminology is confusing -- at least *I* was confused. (I somehow got the impression that the "builtin editor" was a *real* editor. Silly me.) Secondly, I do not have a solution to the signature inclusion problem. One possibility, and this may well be the proper way to go, is to use only *one* signature file, for all address forms. This will certainly simplify things. Thirdly, on the subject of whether to integrate PL 8 and live with the new behavior *and* be able to accept future patches, or freeze at PL 7 and forego future fixes (an idea I don't particularly like)... In PL 9, "ifdef" the signature inclusion code such that a compiletime parameter will select either the old or new method of inclusion. Modify the "configure" script to ask which method the site prefers. This will 1) allow a site to select its preference, and 2) allow a site to continue to apply future patches. [No, I have no idea how much work this will be. Sounds like it is the only way to keep everyone happy, though. *And* still allow us to keep Elm at "current" patch levels.] Thanks for your support -- John G Dobnick Computing Services Division @ University of Wisconsin - Milwaukee INTERNET: jgd@csd4.milw.wisc.edu UUCP: <backbone>!uwvax!uwmcsd1!jgd "Knowing how things work is the basis for appreciation, and is thus a source of civilized delight." -- William Safire
syd@dsinc.DSI.COM (Syd Weinstein) (05/29/89)
First, an item of administration, John is part of the Elm Development
Group.
In article <2662@csd4.milw.wisc.edu> jgd@csd4.milw.wisc.edu (John G Dobnick,EMS E380,4142295727,) writes:
:Firstly, I now understand what we are *really* talking about. (Thanks,
:Rob and Syd, for your messages.) The so-called "builtin editor" is *not*
:an editor at all, but rather a "text insertion mode". The terminology is
:confusing -- at least *I* was confused. (I somehow got the impression that
:the "builtin editor" was a *real* editor. Silly me.)
The built in 'editor' is really more like the mail entry mode of the
Berkeley Mail User Agent often called Mail or mailx. If that helps
other people understand it.
:Thirdly, on the subject of whether to integrate PL 8 and live with the
:new behavior *and* be able to accept future patches, or freeze at PL 7
:and forego future fixes (an idea I don't particularly like)...
As coordinator, I also do not like the idea of people being unable to
apply future fixes. But also be aware, that this freeze will probably
last several weeks while this is sorted out. After all, a concensus
on the net is never reached quickly. I am sitting on the patch, which
was going to be part of PL9, which restores q to obeying ASK mode.
It will still be part of PL9, but when PL9 comes out is now uncertain.
: In PL 9, "ifdef" the signature inclusion code such that a compiletime
: parameter will select either the old or new method of inclusion.
: Modify the "configure" script to ask which method the site prefers.
: This will 1) allow a site to select its preference, and 2) allow
: a site to continue to apply future patches.
I don't really favor this one, although its not hard to do. I think the
single signature file proposed by John is worth considering, but not
for a patch. I feel thats a 2.3 issue. 2.2 supports multiple signature
files.
What I need to reemphasize is that there will be two solutions to this
problem. One is a short term solution for a patch, which must effect
only a few files and be relatively small. The second is a rewrite
of the functional specification and required code changes to make this
more rational, and perhaps simpler for 2.3.
--
=====================================================================
Sydney S. Weinstein, CDP, CCP Elm Coordinator
Datacomp Systems, Inc. Voice: (215) 947-9900
syd@DSI.COM or {bpa,vu-vlsi}!dsinc!syd FAX: (215) 938-0235edwin@ruuinf.cs.ruu.nl (Edwin Kremer) (05/29/89)
First of all, I should say that I *really* like ELM and also appreciate the activities of the ELM development group, trying to develop the best of the best. In article <137@dsinc.DSI.COM>, syd@dsinc.DSI.COM (Syd Weinstein) writes: > 1. Signatures were being confused as to local/remote. > > The code checks to see if the address has you domain name in it > and uses local, else it uses remote. The patch fixed this. Ok, I *like* this feature, but I see an implementation problem: looking at the code, I would say it checks "<hostname><domain>" and not if your domain is just part of the address. So if you are on machine "xxx" at domain "sub.top", only "...@xxx.sub.top" checks out to be local. But what if I mail to a collegue who happens to own machine "yyy" and thus would be addressed "...@yyy.sub.top" ????? Isn't it more logical to just check if the address ENDS with your domain (leading '.' stripped to be able to hide machine names and have a smart sendmail running) and have all "...@whatever.sub.top" taken local ??? Any comments on this ??? --[ Edwin ]-- -- Edwin Kremer, Department of Computer Science, University of Utrecht Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands Phone: +31 - 30 - 534104 | UUCP : ...!hp4nl!ruuinf!edwin "I speak for myself ..." | INTERNET: edwin@cs.ruu.nl
jonathan@cs.keele.ac.uk (Jonathan Knight) (05/30/89)
From article <1346@ruuinf.cs.ruu.nl>, by edwin@ruuinf.cs.ruu.nl (Edwin Kremer): > First of all, I should say that I *really* like ELM and also appreciate > the activities of the ELM development group, trying to develop the best of > the best. Ditto > > In article <137@dsinc.DSI.COM>, syd@dsinc.DSI.COM (Syd Weinstein) writes: > > 1. Signatures were being confused as to local/remote. > > > > The code checks to see if the address has you domain name in it > > and uses local, else it uses remote. The patch fixed this. > Ok, I *like* this feature, but I see an implementation problem: > looking at the code, I would say it checks "<hostname><domain>" and not if > your domain is just part of the address. So if you are on machine "xxx" at > domain "sub.top", only "...@xxx.sub.top" checks out to be local. But what > if I mail to a collegue who happens to own machine "yyy" and thus would be > addressed "...@yyy.sub.top" ????? > Isn't it more logical to just check if the address ENDS with your domain > (leading '.' stripped to be able to hide machine names and have a smart > sendmail running) and have all "...@whatever.sub.top" taken local ??? What about us in the UK? Our addresses START with the domain. And what about local machines which are in a different domain. I.E. we have several departmemts, one is Computer Science and another in Communications and Neuroscience. Their domain is uk.ac.kl.co and ours is uk.ac.kl.cs but all are on the ethernet and so the local signature would do just fine. There is also the problem of long a short domain names. Here in the UK we have two forms of the domain name, one short and one long. So uk.ac.kl.cs and uk.ac.keele.cs are both valid addresses for the same machine. Both need to be recongised as local. There's also the question of local addresses such as 'jonathan@derek'. Sendmail expands this up to a fully qualified domain name which then resloves into my local machine. So that needs the local signature too. Perhaps and easy solution would be to select the local signature on these conditions (these will need modifying for the UUCP world). 1. The address does not have a '.' in it. 2. The address matches a list of domains. The list will be like this: .kl.ac.uk .keele.ac.uk Elm would then need to test the address for 'kl', 'keele', 'kl.ac' 'keele.ac', 'kl.ac.uk', 'keele.ac.uk' to see if its local. And it would have to check both ends of the address. How about a simple question if both local and remote signatures are defined and there is an address (rather than just a username): Local or Remote signature [R] ? @ > -- > Edwin Kremer, Department of Computer Science, University of Utrecht > Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands > Phone: +31 - 30 - 534104 | UUCP : ...!hp4nl!ruuinf!edwin > "I speak for myself ..." | INTERNET: edwin@cs.ruu.nl -- ______ JANET :jonathan@uk.ac.keele.cs Jonathan Knight, / BITNET:jonathan%cs.kl.ac.uk@ukacrl Department of Computer Science / _ __ other :jonathan@cs.keele.ac.uk University of Keele, Keele, (_/ (_) / / UUCP :...!ukc!kl-cs!jonathan Staffordshire. ST5 5BG. U.K.
hans@duttnph.UUCP (Hans Buurman) (05/30/89)
Suggestion: at the point where the user has a choice between s(end), e(dit), f(orget) and h(eader), add the possibility to go to a signature menu. At this point he may change from the default (which could be determined because we are ready to send), or maybe edit the signature (based on a well-chosen template, maybe an option in elmrc). Once the user has modified the signature, it should remain that way (so no automatic change if the header is changed afterwards. A warning maybe). So: add to the s,e,f,h header an S(ignature option), which then gives you the choice between: r(emote signature), l(ocal signature) and e(dit signature). For e, load the template (or remote signature) in the external editor and let the user edit. Would this make everybody happy ? Hans (I'm still happily at PL0, but if Syd sends out the patch for the q-key I'll follow). ----------------------------------------------------------------------------- Hans Buurman | hans@duttnph.UUCP Pattern Recognition Group | Faculty of Applied Physics | mcvax!hp4nl!dutrun!duttnph!hans Delft University of Technology | tel. 31 - (0) 15 - 78 46 94
ccdn@levels.sait.edu.au (DAVID NEWALL) (05/30/89)
In article <137@dsinc.DSI.COM>, syd@dsinc.DSI.COM (Syd Weinstein) writes: > 3. And the major item on the bug list this patch fixed: If you use > signatures you cannot use the built-in editor. > > By delaying the signature code we can use the builtin editor. > > So I ask.... how does the group desire to solve number 3. My suggestion: if the user is using the built in editor, then choose the signature file, and append it, when the message is being sent. If the user is using an external editor, then choose and append the signature after the "to" and "cc" addresses have been entered. David Newall Phone: +61 8 343 3160 Unix Systems Programmer Fax: +61 8 349 6939 Academic Computing Service E-mail: ccdn@levels.sait.oz.au SA Institute of Technology Post: The Levels, South Australia, 5095
edwin@ruuinf.cs.ruu.nl (Edwin Kremer) (05/30/89)
In article <614@kl-cs.UUCP>, jonathan@cs.keele.ac.uk (Jonathan Knight) writes: > > What about us in the UK? Our addresses START with the domain. Oops, I forgot you guys drive on the other side (no, no, I don't say it's the *wrong* side!) of the road :-) I tried to say "....@whatever.sub.top" makes the decision local/remote just a bit more floating than "....@thishost.sub.top" > Perhaps and easy solution would be to select the local signature on > these conditions (these will need modifying for the UUCP world). > 1. The address does not have a '.' in it. > 2. The address matches a list of domains. > > The list will be like this: > .kl.ac.uk > .keele.ac.uk Hmm, that would be yet another file to maintain. Besides, it differs for each individual user: some guy on a remote machine or another domain might know me but not my neighbour. This could be implemented just like the header weedout list in the users elmrc, but I don't think we want to bother users with this kind of mailing details. > How about a simple question if both local and remote signatures are > defined and there is an address (rather than just a username): > Local or Remote signature [R] ? @ Sure, but we always try to have the software taken care of as many details as possible, don't we ?? Anyway, I would agree with a solution like this - it's more user-friendly than having to read the right signature file into your editor buffer by hand (as suggested in the discussion earlier) .... --[ Edwin ]-- -- Edwin Kremer, Department of Computer Science, University of Utrecht Padualaan 14, P.O. Box 80.089, 3508 TB Utrecht, The Netherlands Phone: +31 - 30 - 534104 | UUCP : ...!hp4nl!ruuinf!edwin "I speak for myself ..." | INTERNET: edwin@cs.ruu.nl
fred@cdin-1.UUCP (Fred Rump) (05/31/89)
In article <5423@pbhyf.PacBell.COM> rob@PacBell.COM (Rob Bernardo) writes: ->J. Philip Miller writes: ->+Anyway to know (while you are editing the outgoing message) what signature elm ->+ntends to append? -> ->I'm not sure why you're saying this. ELM figures it out for you. And it ->figures it out after you have gotten past all opportunity to change the ->to list or cc list, i.e. after you enter 's' on the send menu. (Prior ->to that you could enter 'h' and change the to and cc headers.) That's ->Or simply DON'T define the signature files in your elmrc, and then jsut ->read them in while you're in your editor. I really don't understand all the fuss about the signatures. seems to work fine the way it is in PL8. If you want new features, wait for new major releases. In the meantime, why freeze everything for the rest of us who like what the folks, who work so hard at this FREE code, are able to accomplish. No body will please everybody all the time. So let's get on with it. fred -- Fred Rump | UUCP: {uunet bpa dsinc}!cdin-1!fred CompuData, Inc. | or ...{allegra killer gatech!uflorida decvax!ucf-cs} 10501 Drummond Rd. | !ki4pv!cdis-1!cdin-1!fred Philadelphia, Pa. 19154| Internet: fred@cdin-1.uu.net (215-824-3000)
ignatz@chinet.chi.il.us (Dave Ihnat) (06/02/89)
If I might make an observation, the problem that seems to have been encountered isn't even necessarily because there was a feature change. It is because, once a version of a program is released, users commonly don't expect the intended behavior of the release version to be changed by what they expected to be a simple bugfix. Normally, such a behavior change would be analyzed, discussed, and then designed into the next release of the system after developers and users had hashed out exactly how they wanted the system to behave. Patch 8 unilaterally and without announcement or discussion changed a very visible aspect of Elm behavior; this confuses naieve users, worries administrators (who have to suspect, initially, that they did something to the system), and can undermine the confidence of the user community in the stability of the tool. The cat's out of the bag for this particular patch and function; I'd suggest a followup patch that makes the new behavior optional, and clean up the situation for good in the next release. But in the future, when writing a patch, perhaps we should all ask "Is this a correction to make the program honor the documented features of this release, or is it a feature enhancement and/or functional change? If the latter, is it important enough to introduce in the current release, or does it belong in the next release?" And finally, if it is important enough to do this, it should be announced *and discussed* before its posting. Dave Ihnat Analysts International Corp aicchi!ignatz || ignatz@chinet.chi.il.us || ignatz@homebru.chi.il.us
mike@pcsbst.UUCP (Mike Schroeder) (06/05/89)
In article <469@wubios.wustl.edu> phil@wubios.UUCP (J. Philip Miller) writes: >In article <5419@pbhyf.PacBell.COM> rob@PacBell.COM (Rob Bernardo) writes: >>In article <465@wubios.wustl.edu> phil@wubios.UUCP (J. Philip Miller) writes: >>+In article <133@dsinc.DSI.COM> syd@dsinc.DSI.COM (Syd Weinstein) writes: [ lot's of discussion on when to append signature files deleted ] > >While we are on the subject, is it possible to expand the definition of local >to also include other hosts in 'thisdomain' rather than just 'thishost' ? yes, Yes, YEs, YES!!!! Actually, I've noted this before, and Syd has already acknowledged that this might be changed in some way in future. > >In a posting in reply to another note in this thread I indicated that one way >of helping all of these problems would be to allow the user to change the name >of the file that elm will include as the signature file as part of the header >menu. This would allow one to then override any of these local/remote >dimensions. > not a bad idea. How about taking up this suggestion? -- Mike Schroeder PCS-Mail: msc SNAIL: PCS GmbH; Pfaelzer-Wald-Str. 36; D-8000 Muenchen 90; W. Germany DOMAIN: msc@cochise.pcs.de (EUR) or msc@cochise.pcs.com (US) BANG: ..unido!pcsbst!msc (EUR) or ..pyramid!pcsbst!msc (US) VOICE: xx49-89-68004208