[bit.listserv.mailbook] BSMTP header

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