JBB@VIRGINIA.BITNET (Joseph B Burch Academic Computing) (02/02/90)
Richard - am I correct in assuming that the BSMTP envelope in which mail is placed is constructed from header information available at invocation and NOT from the header information current at the time mail is actually sent? If one chooses to ignore the warning "changes to header may make the mail undeliverable", one can freely modify headers with the often un- fortunate result that addresses that appear on outgoing mail may differ significantly from those of the BSMTP envelope. My point is that the warning message itself seems to state that whatever changes one has choosen to make to the header have indeed been incorpor- ated into the BSMTP envelope. But clearly this is not the case! Should not the text of the warning message be changed or, better still, provisions made to permit any header modifications to be incorporated into the BSMTP envelope? Thanks ... Joe
SCHAFER@RICEVM1.RICE.EDU (Richard A. Schafer) (02/02/90)
Yes, the BSMTP does not include anything updated by hand (although it does include things changed by INCLUDE/EXCLUDE subcomands). So you have a good point that the warning message should at least be changed. That's easy. Reflecting the actual manual changes might be a good idea but will take a lot longer to do. Richard
MAINTCMS@PUCC.BITNET (John Wagner) (02/03/90)
On Fri, 2 Feb 90 12:34:41 LCL Michael Wagner said: > Besides, most header >manipulation I do can't be done with the supplied commands. I've found that in my job as postmaster this is a big problem for me, also. I expect that once the new MAIL/MAILBOOK goes into production here I will be setting up a separate id to do postmaster stuff simply because I can no longer modify the headers. The list of things I need supported are: Full RFC822 addresses (including route addresses) "!" addresses (we see a fair amount of UUCP traffic) EXCLUDE that works with the full address Excluding of ids from only one header line type (to: cc:, etc.) I used to be able to do this stuff by hand. For me the change to BSMTP was a step backward. This is not to say the code is bad, it simply doesn't fit my needs as well as it did before.
MICHAEL@UTORONTO.BITNET (Michael Wagner) (02/03/90)
I don't understand something very fundamental about this discussion. Why not accept the changes to the header elements as requests from a naive user to change the header as he has? I.e., if MAIL/BOOK needs to have the INCLUDE/EXCLUDE issued in order to have the changes reflected in the BSMTP, why not issue them internally? Typing over the header is the most obvious way for someone to change something if they don't know much about the package (as is the case for most new users). Why not gently steer them back into acceptable usage by accepting the most obvious input? Now, granted, the typed-over input may be invalid, but the logic to determine that is already built-in to include/exclude. So if include/exclude fails, the type-over logic could re-instate the old header element. In fact, the command orientation of the header, combined with the full-screen orientation of the body, has always seemed odd to me. It seems to me a worthy goal to make all the full-screen editing work in the header as well, for those who even understand RFC822 headers. If you delete the last line in a header element, the comma on the previous line should disappear, and the header element should be re-checked for correct syntax. If you delete a must-exist element, a warning should occur, and you should be given the option of re-instating the essential element. And so on. If one set of commands (add line, delete line, etc) worked for both halves, there would be a smaller learning curve. Now, I know enough about the code to know that this is not a trivial task, so I'm not suggesting that this should be undertaken overnight. But I don't have a lot of sympathy for the sentiment, expressed recently a lot on this list, of let the buggers freeze in hell if they type over the headers rather than learning the extra handfull of commands for manipulating the headers. It sounds pretty user-hostile to me to adopt this sort of attitude. Besides, most header manipulation I do can't be done with the supplied commands. Michael
KS06054@UAFSYSB.BITNET (Ken Schriner) (02/03/90)
On Fri, 2 Feb 90 12:34:41 LCL Michael Wagner said: >I don't understand something very fundamental about this discussion. >Why not accept the changes to the header elements as requests from a >naive user to change the header as he has? As a naive user, yeah, how come. I train a lot of users to use mail and basically, they never understand why they can't type over the stuff in the header. Basically, me neither. Full screen means the full screen, not just the text area. >... I don't have a lot of sympathy for the sentiment, expressed >recently a lot on this list, of let the buggers freeze in hell if they >type over the headers rather than learning the extra handfull of >commands for manipulating the headers. I missed the mail about the buggers freezing in hell, too bad. I understand the concept though. It reminds me a lot of Ashton Tate's response to the dBase user community needing the ability to produce compiled code. I'm with the users (and Michael Wagner). I don't want to learn, or train, users to use the extra handful of commands. I want to tell new users to MAIL, just type over the stuff in the header area to change it. Ken Schriner BITNet : KS06054@UAFSYSB Computing Services University of Arkansas 220 ADSB Fayetteville, AR 72701 (501) 575-2905
SCHAFER@RICEVM1.RICE.EDU (Richard A. Schafer) (02/03/90)
On Fri, 2 Feb 90 14:22:30 CST Ken Schriner said: >On Fri, 2 Feb 90 12:34:41 LCL Michael Wagner said: >>I don't understand something very fundamental about this discussion. >>Why not accept the changes to the header elements as requests from a >>naive user to change the header as he has? > >As a naive user, yeah, how come. I train a lot of users to use mail >and basically, they never understand why they can't type over the stuff >in the header. Basically, me neither. Full screen means the full screen, >not just the text area. Frankly, I agree. But to be perfectly honest, I've just not had the time to do that kind of work. And it will be a fairly substantial amount of work, by the way. >>... I don't have a lot of sympathy for the sentiment, expressed >>recently a lot on this list, of let the buggers freeze in hell if they >>type over the headers rather than learning the extra handfull of >>commands for manipulating the headers. > >I missed the mail about the buggers freezing in hell, too bad. I understand >the concept though. It reminds me a lot of Ashton Tate's response to the >dBase user community needing the ability to produce compiled code. I'm with >the users (and Michael Wagner). I don't want to learn, or train, users >to use the extra handful of commands. I want to tell new users to MAIL, >just type over the stuff in the header area to change it. I think we can avoid too much of this by saying that this is a future objective. I will warn you of one thing, however: it's going to cost you something, because it means that the code will have to do a bunch of extra scanning of the header lines to make this work. Which would you prefer: when the user types over the header lines and produces something unparseable, 1. Notice the problem at that point (which means you have to scan the header lines *every* time a change is made) 2. Notice the problem only when you try to send the message (which means that the user won't be told when he or she makes the change but presumably quite a while afterwards, but does limit the amount of time spent scanning the header lines) It occurs to me that maybe we're really barking up an entirely wrong tree here. Do we really want to have to depend on people entering the exact syntax of an RFC822 address by hand? (Don't forget to put double quotes around the name if certain characters are in it; remember to put those funny angle bracket things in the right places, etc.) Maybe what we really need is a completely different way of looking at the entire problem that allows full-screen changes, sure, but in a less syntactically painful way. This will require a lot of thought to do right, but I'm not going to expend a lot of effort on manually updating header lines if I can think of a different, but better way of doing the same thing. Richard
JBB@VIRGINIA.BITNET (Joseph B Burch Academic Computing) (02/03/90)
On Fri, 2 Feb 90 15:22:06 CST <SCHAFER@RICEVM1.RICE.EDU> said: >Frankly, I agree. But to be perfectly honest, I've just not had the time >to do that kind of work. And it will be a fairly substantial amount of >work, by the way. > Sorry to have started a food fight, Richard! How about just disallowing cursor positioning in the header area for the time being. This should keep most folks happy... >I think we can avoid too much of this by saying that this is a future >objective. I will warn you of one thing, however: it's going to >cost you something, because it means that the code will have to do >a bunch of extra scanning of the header lines to make this work. > >Which would you prefer: when the user types over the header lines and >produces something unparseable, > >1. Notice the problem at that point (which means you have to scan the > header lines *every* time a change is made) >2. Notice the problem only when you try to send the message (which means > that the user won't be told when he or she makes the change but > presumably quite a while afterwards, but does limit the amount of time > spent scanning the header lines) > 3. Scan the header lines only after the cursor has first been moved into the header area and then a) moved away or b) a PF key has been struck. >It occurs to me that maybe we're really barking up an entirely wrong >tree here. Do we really want to have to depend on people entering >the exact syntax of an RFC822 address by hand? (Don't forget to >put double quotes around the name if certain characters are in it; >remember to put those funny angle bracket things in the right places, etc.) >Maybe what we really need is a completely different way of looking at >the entire problem that allows full-screen changes, sure, but in >a less syntactically painful way. This will require a lot of thought >to do right, but I'm not going to expend a lot of effort on manually >updating header lines if I can think of a different, but better way >of doing the same thing. > Sounds good to me, Richard. Thanks for your feedback ... Joe
NU021172@NDSUVM1.BITNET (Marty Hoag) (02/03/90)
As a postmaster who probably shares some of the feelings of the two Wagners (are you related?). But I think a better solution would be a command which would work like FORWARD (with some features of REPLY) but would totally "encapsulate" the original mail, including all the headers, in the body of the mail. My only problem is what to call this. Some systems have RESEND and FORWARD but I don't use them enough to remember which does what... Maybe something like PASS? It would be nice if there were a way to PASS to ALL original addresses or the FROM or whatever just as you can with REPLY. But like FORWARD it would open up a couple lines of white space followed by an "original message" line then the note as received (with RECEIVED: lines and all...). For example, entering PASS xyz@abc (ALL would creat a new mail item addressed to xyz@abc AND all the original recipients (not sure the best way to do that but it would be nice to be able to snatch addresses off the original note). The mail would look like: Date: ... From: me To: xyz@abc, ... (from all or whatever, if that is used) Subject: (hmmm... could include original one with "Re:" if none included on the pass command ===================... ...a couple lines left intentionally blank... ---------------------------- Original Mail ----------------------------------- Received:... etc. I know Richard has been thinking about this and has indicated he will probably do it some time (I hope I am reflecting his feelings correctly...;-). For now I have a command called PASS that simply does a FORWARD but stacks a "Reply *" to protect innocent recipients of items forwarded from a list with a reply-to the list... So maybe there is a different name someone could think of (GRAB, CAPTURE, BAG, ...). Marty
NU021172@NDSUVM1.BITNET (Marty Hoag) (02/03/90)
Hmmm... I would prefer to either leave things as they are (issue a warning anytime a header is changed) rather than have an all-out ban on cursor positioning in the headers. Right now I can change the non-BSMTP headers like Subject on mail I am forwarding (I choose to edit the subject for a moderated list for example...). I know, I could probably issue a subject command to add a new Resent-Subject but usually the changes I need to make are minor...
JBB@VIRGINIA.BITNET (Joseph B Burch Academic Computing) (02/03/90)
On Sat, 3 Feb 90 08:58:06 CST <NU021172@NDSUVM1.BITNET> said: > Hmmm... I would prefer to either leave things as they are (issue a >warning anytime a header is changed) rather than have an all-out ban on >cursor positioning in the headers. Right now I can change the non-BSMTP >headers like Subject on mail I am forwarding (I choose to edit the subject >for a moderated list for example...). I know, I could probably issue a >subject command to add a new Resent-Subject but usually the changes I need >to make are minor... Good point - how about allowing the cursor to be positioned ONLY in those fields that legitimately can be modified? Joe
C4898@UMSLVMA.BITNET (Larry Pickett) (02/05/90)
It seems this header conversation is headed in the direction of dividing the process of sending a piece of mail and maintaining the mailbooks into two parts: 1) preparation of the text of the message 2) maintenance/ initial preparation of the mail header/envelope/routing what ever. Richards points make sense. Perhaps we need to forget that the headers are attached to the body and think about a separate set of screens to enter that information on and the code to take that info and slap it onto the front correctly. When sending mail I don't care if I never see the header info, assuming that I can look at to verify where stuff is going. and for sure when reading discussion list mail I don't care about the headers particularly the received by stuff. Once in a while I'd peek at it but that might be 1 out of 50. Yes there are days I can't type my name correctly let alone rfc222 stuff.
NADWL@HDEDH1.BITNET (Scott Ophof) (02/05/90)
On Fri, 2 Feb 90 15:22:06 CST Richard A. Schafer said: >>>... >... >It occurs to me that maybe we're really barking up an entirely wrong >tree here. Do we really want to have to depend on people entering >the exact syntax of an RFC822 address by hand? (Don't forget to >... My general feeling is that where users could "botch up" the header, I'd prefer that line to be a RESERVED one, which of course means possible extra commands to effect changes. And elsewhere I wouldn't mind being rapped on the knuckles at SEND-time. By the way, I even get the "changes may make header ...{reminder when I type a prefix command on one of the header lines which does NOT affect the header at all! >Maybe what we really need is a completely different way of looking at >the entire problem that allows full-screen changes, sure, but in >a less syntactically painful way. This will require a lot of thought >... Yes. Regards. Scott/
NADWL@HDEDH1.BITNET (Scott Ophof) (02/06/90)
On Sat, 3 Feb 90 20:54:34 EST Nick Gimbrone said: >>... >This harkens back to my suggestion of a while back that we break SEND >mode up into 2 screens; one for the header and one for the body. These >two modes could then be treated completely separately/differently. >... This to me looks even better than my suggestion of RESERVEing the header lines. It also seems to me to be a more logical situation for the general user, increasing the resemblance to mail on paper, where the envelop and the contents of the letter are 2 completely separate entities (at least until the creation of envelops with transparent windows...). And maybe use the IDLINE for a short reminder to the user? Something like: "Mail to: Richard Schafer, Nick Gimbrone and MAIL/MAILBOOK" A maybe not completely unlogical continuation of Nick's idea would be to implement same for READ mode? And again using the IDLINE to display: "New mail from: ....." or "New mail sender: ......" or "Notebook MAILBOOK, item from/sender: ......" With the "Subject: ...." line as optional RESERVED line right under the IDLINE, and the CMDLINE at the bottom of the screen? Regards. Scott/
PAPAKHI@IUBVM.BITNET (A. Ralph Papakhian) (02/06/90)
I think you all should be careful about entering into split addressing and mail screens. I have tried to use an MVS mail system (it's called "EMMA," a product from SYSM) which works on that principle. After using MAIL/MAILBOOK I find EMMA to be fairly confusing: address on one screen, then compose mail on another, then try to figure out where your are, then "send." The simpler the better. Let MAIL/MAILBOOK users change the header on the same screen. --Comments from a user (not a programmer). Most sincerely, ##### @@@@ ### @@@@ MUSIC @@ ### @@ A. Ralph Papakhian, Music Library @@ ### @@ LIBRARY Indiana University, Bloomington, IN 47405 @@ ### @@ (812) 855-2970 ### #####
URZ02@DMSWWU1A.BITNET (Dr. Klaus-Bolko Mertz) (02/06/90)
On Fri, 2 Feb 90 12:34:41 LCL Michael Wagner said: > >Typing over the header is the most obvious way for someone to change >something if they don't know much about the package (as is the case >for most new users). Why not gently steer them back into acceptable >usage by accepting the most obvious input? > >Now, granted, the typed-over input may be invalid, but the logic to >determine that is already built-in to include/exclude. So if >include/exclude fails, the type-over logic could re-instate the old >header element. > >In fact, the command orientation of the header, combined with the >full-screen orientation of the body, has always seemed odd to me. It >seems to me a worthy goal to make all the full-screen editing work in >the header as well, for those who even understand RFC822 headers. If >you delete the last line in a header element, the comma on the >previous line should disappear, and the header element should be >re-checked for correct syntax. If you delete a must-exist element, a >warning should occur, and you should be given the option of >re-instating the essential element. And so on. If one set of commands >(add line, delete line, etc) worked for both halves, there would be a >smaller learning curve. That's my feeling too, and so I hesitated for a while to switch to 89.02.0B as our all-user's MAIL. But due to other benefits I'll do it soon. KBM
Q3642@PUCC.BITNET (Simcha M Druck) (02/07/90)
On Mon, 5 Feb 90 22:31:41 EST you said: >I think you all should be careful about entering into split addressing >and mail screens. I have tried to use an MVS mail system (it's called >"EMMA," a product from SYSM) which works on that principle. After >using MAIL/MAILBOOK I find EMMA to be fairly confusing: address on >one screen, then compose mail on another, then try to figure out where >your are, then "send." The simpler the better. Let MAIL/MAILBOOK >users change the header on the same screen. > > >--Comments from a user (not a programmer). > >Most sincerely, ##### > @@@@ ### @@@@ MUSIC > @@ ### @@ >A. Ralph Papakhian, Music Library @@ ### @@ LIBRARY >Indiana University, Bloomington, IN 47405 @@ ### @@ >(812) 855-2970 ### > ##### Could you tell me where I get more information on the MVS MAIL that you mentioned - thanks.
HABERNOL@TUBVM.CS.TU-BERLIN.DE (Thomas Habernoll) (02/07/90)
One more vote from a header mangler (it's not my free will, I'm paid to do so :-) In a perfect world we wouldn't need to mess around with headers. As the world is not perfect we need tools that allow us to fix it. For postmasters it is often much easier to change the header instead of writing long explanations to a user why this header should be changed. Therefore I can't use the new version of MAIL - some of the changes I have to do are not supported by commands, some would be arbitrary tedious if not done by overtyping. I would be pretty quiet if a way to manipulate headers were to the advantage of a small number of experienced users only, and would do harm to novice users. But this isn't the case here. Regardless of the grade of experience it violates the rule of least astonishment if a change of a header line doesn't has the effect one would expect. >[when to check for parsable headers] >Which would you prefer: when the user types over the header lines and >produces something unparseable, [1. immediately after the change, >2. when sending] The check should be done immediately. The actual sending may be a long time after the mistake was made (suspend/resume), and even if it is in the same session it may be hard to remember what you intended to do when you introduced the error. > Do we really want to have to depend on people entering >the exact syntax of an RFC822 address by hand? No, but then, some people are doing a better job here than some mailers/gateways :-) There are some gotchas which would make it worthwhile if the software could do a sanity check. But sometimes minimal knowledge of RFC822 is useful if not a prerequisite for using e-mail (lacking a perfect world). A typical modification (which is done much easier by editing the header instead of using a command interface), e.g. when replying to a mail: cryptO02731Id%unspellable.host.some.where%huh.whats.that%broken.gate.way becomes: cryptO02731Id@unspellable.host.some.where No program can know that broken.gate.way is broken, and that huh.whats.that is an extremely expensive mail path. Not everybody has to know this, but everybody who knows should have a chance to show another user what is to be done to get his mail through without retyping all these cryptograms from scratch. Therefore, please, let us mess around with all these funny header lines in the most convenient way. I wouldn't care how to modify headers in MAIL/MAILBOOK if it were not such a good program, both for novice and experienced users. I'm getting a lot of questions from our users regarding addresses, gateways, bang and percent hacks, but I'm getting close to zero questions regarding MAIL/MAILBOOK. And even if a hardnosed user dares to mention this software, you may be sure it's just because s/he is looking for some advanced features. Thomas
MAINTCMS@PUCC.BITNET (John Wagner) (02/08/90)
Christian, I have been working on a fix for handling VNET better. I'd be interested in your (and other folks) comments as to what is generally useful. Here's my assumptions: 1. VNET mail is recognized by the origin node of VNET (in the tag at the receiver's end) 2. The nickname id (i.e. the userid you must specify when sending the file to the VNET gateway) is given as the userid in the tag I am making several modifications, but I'll use the case of a PROFS file as an example. Once the mail file is recognized as being in PROFS format, the MAILPROF routine is called to reformat the headers into RFC822 conformance (we hope). If the file is from VNET, I now pass the correct userid (nickname@VNET taken from the tag) to use in the From: line (I should also have MAILPROF put in a comment for the real userid and node inside VNET, but I haven't done that yet). This allows the MAILPROF exit to properly reformat and rebuild the headers. Similar processing must be done for NOTE format files and replacement of the From: line must be done in RFC822 mail (I wish they would all use PROFS and make it easy). Is there anything else I should be doing?
REICHETZ@AWIIMC11.BITNET (Christian J. Reichetzeder) (02/08/90)
On Wed, 7 Feb 90 03:30:57 +0100 Thomas Habernoll said: > ..... As the world is not perfect we need tools that allow >us to fix it. For postmasters it is often much easier to change >the header instead of writing long explanations to a user why this >header should be changed. > ........ > cryptO02731Id%unspellable.host.some.where%huh.whats.that%broken.gate.way >becomes: > cryptO02731Id@unspellable.host.some.where > First, do YOU - as postmaster - change the header? Or do you tell the users to do it? In cases like the above I simply tell the user to make an entry in the names file. It's slightly more effort than overtyping the header - but only one time. And then it works "forever" ;-). While we are at it (speaking of broken addresses ...): 1) I'd like to see a "full power REPLY", i.e. I'd like to be able to pick up whatever field is in the original header if it contains a usable address (I've seen cases where the X-Original-From: contains a good, valid address while the From: is next to unuseable). 2) For cases where mail comes in with unusable addresses but a valid address is known an aliasing/replacement feature would be nice. Ever got mail from VNET? The *BM-N*T* or PR*FS header contains the VNET address but I have to reply to nickname@VNET. A special tag in the names file could help, one could do it even without this. Without a special tag I would do it as follows: * Look if the original address is in the NAMES file * If it is found look if LIST OF NAMES is specified * Use the first address of List-Of-Names for the reply otherwise take the original address As additional precaution you could check for a certain value for the name like ALIAS-OF-nickname. like: Nick: JUNKNICK Userid: VNETGuy Node: VNETHost Name: ALIAS-OF-JOEVNET List of Names: JOEVNET Nick: JOEVNET Userid: JOE0815 Node: VNET Name: Joe F. DeVnet How about ... ? Christian P.S.: Richard - the fixed MAILINDX is ok
AER7101@TECHNION.BITNET (Zvika Bar-Deroma) (02/09/90)
On Wed, 7 Feb 90 03:30:57 +0100 Thomas Habernoll said: > >I would be pretty quiet if a way to manipulate headers were to the >advantage of a small number of experienced users only, and would do >harm to novice users. But this isn't the case here. Regardless of the >grade of experience it violates the rule of least astonishment if >a change of a header line doesn't has the effect one would expect. > I think Thomas has implicitely raised an idea that could solve this business (it must bother lots of us - the discussion on that issue has been going on for a month or more, with a few variations). My suggestion is: Set an option ALTER.HEADER which defaults to NO. No means that one cannot alter the header (never mind now how it is implemented - SETting the header lines as RESERVed, having the header in a second file in the ring or any other idea method which implements this idea. The "experienced" user might set ALTER.HEADER YES in his personal MAILUSER XEDIT file, thus enabeling him to alter the header, with the possible negative "side effects". I'm not talking how to actually implement the idea as there are many who know the MAILBOOK code a lot better than I do, and more important - we first have to agree/convince Richard what the "best" solution (or compromise) is. /Zvika