[bit.listserv.mailbook] Proposals for yet another version of MAIL/BOOK

MAINT@DERRZE1.BITNET (Rainer M Woitok) (01/13/90)

Yesterday I installed  89-02-0A and was really impressed  by the various
enhancements  and  by the  performance  improvements  achieved by  using
these index  files. I'd nevertheless  like to make some  proposals, part
of which  arouse from my testing  and playing with the  new version, and
part of  which I'm carrying  around for quite  a while. The  sequence in
which I'll mention things is random and does not reflect any priority.

1. Message-Ids
   Since it  is now possible  to generate  a unique message-id  for each
   mail, it  would perhaps  be meaningful  to display  a message  with a
   message-id only  once in case  it is  cross posted to  several lists.
   But since you'll  see the mail only once, you  will respond only once
   and thus to only  one list. A way out would perhaps  be to modify the
   REPLY ALL  command in  such a way  that it would  really pick  up all
   addresses, even those in the X-To:  or Comments: To: fields. In order
   to  then bring  this feature  to a  widespread use,  the default  for
   MESSAGE.ID should perhaps be changed to YES.

2. SENDER and FROM options for the LOG(D) command
   When you  issue the LOG(D)  command without parameters,  the notebook
   to be  used is determined  from the  various header fields  which are
   scanned in a  sequence specified via the  LOGGING.PERSON option. This
   seems  not enough  for me.  I have  a PF-key  set to LOGD#REPLY FROM,
   and using it I end up with  the list mail I'm privately responding to
   being logged in,  say, MAILBOOK NOTEBOOK while my  response is logged
   in, say,  SCHAFER NOTEBOOK.  I would  prefer my  PF-key being  set to
   LOGD (FROM#REPLY FROM  TEXT in which case both items  would end up in
   SCHAFER NOTEBOOK. I would recommend  to interpret LOG (SENDER FROM as
   a request  to log the  item in both  notebooks if they  are different
   and to log  it only once if  they are not. Thus LOG  (SENDER FROM may
   or may not behave like LOG(SENDER#LOG(FROM.

3. I'd like to see a SELECTD command
   When I  read my incomming  mail and  encounter a subject  I'm totally
   desinterested in,  I'd like  to select all  items with  that peculiar
   subject  and to  immediately mark  them for  deletion, so  subsequent
   READs won't  pick them up.  Currently I have  to use SELECT  and then
   delete the items one by one by  hand, since deleting items from a set
   of  SELECTed menu  lines  is somewhat  awkward,  because the  numeric
   parameters passed  to the  DISCARD command refer  to the  position in
   the main menu  rather than to the position in  the current selection.
   (By the  way, since there are  some commands which take  as arguments
   the line number in the main  menu, could there be another displayable
   column with exactly  these numbers? I know, I know,  I could turn the
   prefix  on  and  set  it  to   numeric,  but  five  digits  for  that
   information seems a bit overdone.)

4. New sorting column STATUS (or similar)
   Since I can now sort according  to multiple columns, I'd like also to
   be able to sort according to the  status field, where either ' ' (old
   mail), '>'  (new mail) or  '-' (mail  to be discarded)  is displayed.
   Thus I could cleanly separate old from new mail.

5. Editing the header part
   This topic  has already been discussed  here, but I'd like  to add my
   two cents:  Since I'm working  in a fullscreen environment,  I'd like
   to  make changes  to  the  subject line  by  simply  typing over  it,
   without having  to use a  (line mode) SUBJECT command.  Similarly I'd
   like to  be able to  add a Reply-To:  line by simply  duplicating the
   From: line  and then changing  the From:  into a Reply-To:.  I'd even
   like to be able  to change recipients from a cc: status  to a Bcc: or
   to  a normal  To: status  and vice  versa simply  by typing  over the
   corresponding  fields, I'd  like  to  correct a  human  name, drop  a
   .BITNET suffix  without having to  clobber with INCLUDE  and EXCLUDE.
   Finally  I'd prefer  the  prefix-D command  for omitting  recipients.
   Couldn't MAIL postpone the creation  of the BSMTP envelope until SEND
   is issued? Couldn't  it even check for correct headers  (if they were
   modified) and insert  missing or drop extraeous commas  from the To:,
   cc:  and Bcc:  lines? The  manipulating of  the headers  currently is
   still  sort of  line  mode oriented.  (By  the way,  I  even get  the
   warning "Changes to the headers ..."  when I enter a prefix-A command
   in the separator line containing all these equal signs.)

6. TIME.ZONES option
   My private  TIMEZONE TABLE  file contains  slightly less  than eighty
   entries  of  time zones  I've  encountered.  Even  if I  omit  rather
   strange ones,  they clearly don't  fit into  a single line.  Thus I'd
   prefer the  TIME.ZONE option  to specify a  file containing  the time
   zone definitions  in the  format "zone_name offset  comment". Besides
   there are  time zones which  have offsets  of some hours  plus thirty
   minutes, for example

         CADT +10.5 Central Australian Daylight Time
         CAST +09.5 Central Australian Standard Time

   Does the TIME.ZONE option handle this?

7. What is the default of EXPAND.TABS?
   While  file MAIL89  CHANGES states  that the  default be  NO, PROFILE
   HELPMAIL claims it to be YES. Who is right?

8. Suboptimal use of screen width
   When I set MENU.FIELDS to FROM  DATE SIZE SUBJECT, the subject column
   of the main menu does not use  as much space as it could. The subject
   lines could be longer. Is there a way to do this?

9. Just for fun
   I  had my  main  menu sorted  according  to the  DATE  column when  I
   encountered a pair of mail items  where the reply was listed ahead of
   the original question:

         Barry Hathaway     1/11/90*PROFS acknowledgements and reo
         Richard A. Schafer 1/11/90 PROFS acknowledgements and reo

   I  checked the  time stamps:  Richard's  was 13:13:57  CST, which  is
   19:13:57 UT  and Barry's was  15:08:51 EDT  which is 19:08:51  UT. So
   the software  was correct: Fast-As-Lightning-Barry  responded roughly
   five minutes before Richard asked.

Sincerely
 Rainer


.----------------------------------------------------------------------.
| Rainer M. Woitok                 | Phone  : (+49 9131) 85-7811,-7031 |
| Regionales Rechenzentrum         | e-Mail : MAINT@DERRZE1.BITNET     |
| Friedrich-Alexander-Universitaet |                                   |
| D-8520 Erlangen                  |                                   |
| West Germany                     |                                   |
'----------------------------------------------------------------------'

HATHAWA@GECRDVM1.BITNET (Barry Hathaway) (01/15/90)

Here's another wish list item:

How about support for mailing lists.  Right now list of addresses must be
stored in the NAMES file which is limited in length.  In addition, it forces
you to create a list of nicknames and then define each nickname separately
so you can use full names in your mail.  What I would like to see is support
for using a separate file of names in say a LISTSERV format:

user1@node1 Full Name 1   --
user2@node2 Full Name 2    |-- FILE1 LIST
etc.                      --

Then when sending mail you use the list by saying

    MAIL FILE1         (or maybe  MAIL (LIST FILE1    )

This would allow the user to keep his mailing lists separate.  A possible
extension might be to include only the addressees in the BSMTP header and not
in the RFC822 header.

VALDIS@VTVM1.CC.VT.EDU (Valdis Kletnieks) (01/16/90)

On Mon, 15 Jan 90 08:31:01 EDT Barry Hathaway said:
>Here's another wish list item:

>How about support for mailing lists.  Right now list of addresses must be
>stored in the NAMES file which is limited in length.  In addition, it forces
>you to create a list of nicknames and then define each nickname separately
>so you can use full names in your mail.  What I would like to see is support
>for using a separate file of names in say a LISTSERV format:

Another good reason for adding this - ever have a :list. that was over
250 chars long?  Namefind can't deal with it too well - and yes, I *know* it
should be a Listserv lsit, but we shouldn't force people to jump through
hoops to make a rare mailing - the particular list I have is only used
once every 2 months or so...

                                   Valdis

SCHAFER@RICEVM1.RICE.EDU (Richard A. Schafer) (01/16/90)

There's a simple solution to long lists (outside of the LISTSERV solution).


:nick.MAJOR :list.minor1 minor2
:nick.MINOR1 :list.user1 user2...
:nick.MINOR2 :list.user50 user51...

Lists can be nested to any depth you'd like, with the obvious performance
hit that an additional NAMEFIND is required for every level.  The list
I maintain for distribution of the code itself is

:nick.MAILBOOK :list.continent1 continent2 ...
:nick.continent1 :list.country1 ...
:nick.country1 :list.region1 ...
:nick.region1 :list.user1...

Richard

NJG@CORNELLA.BITNET (Nick Gimbrone) (01/16/90)

On Mon, 15 Jan 90 15:38:56 CST Richard A. Schafer said:
>There's a simple solution to long lists (outside of the LISTSERV solution).
>:nick.MAJOR :list.minor1 minor2
>:nick.MINOR1 :list.user1 user2...
>:nick.MINOR2 :list.user50 user51...
And yet another is to use MAILER's distribution list support (hey, this
is a VM MUA, so a VM MTA is a fine solution too). We use these rather
heavilly here.

For historical reasons we have supported something similar to that
originally described (an external file which lists userids/nicknames
to send mail to, though it didn't allow the "friendly user name" part).
The mod to mailb00k is rather simple (just inserting another possible
resolution for the 'name' being sent-to/included).

We also have supported these same lists for sending files to NJE
network recipients via a "sendfile/card/disk/print/<whatever you care
to use as the transport>" front-end.  It is pretty flexable, though
slow (due to the use of NAMEFIND :-).

NADWL@HDEDH1.BITNET (Scott Ophof) (01/17/90)

On Fri, 12 Jan 90 14:06:31 CET Rainer M Woitok said:
>Yesterday I installed  89-02-0A and was really impressed  by the various
>enhancements  and  by the  performance  improvements  achieved by  using
>these index  files. ...

He done said a GOOD thing there!  (as he usually does)


>...
>4. New sorting column STATUS (or similar)
>   Since I can now sort according  to multiple columns, I'd like also to
>   be able to sort according to the  status field, where either ' ' (old
>   mail), '>'  (new mail) or  '-' (mail  to be discarded)  is displayed.
>   Thus I could cleanly separate old from new mail.

I have a REXX file (MAILSYNS XEDIT) to do that kind of things, like PRFON,
which sets up the prefix area the way I want it.
A SELECTD synonym for some code to pick up the column of "date:" on the
first line of the menu, from which it can calculate the position of " ", ">",
and "-", and then selectively display only the rest should then turn out to
be a "trivial"(?) coding exercise, methinks...


>5. Editing the header part
>   This topic  has already been discussed  here, but I'd like  to add my
>   two cents:  Since I'm working  in a fullscreen environment,  I'd like
>   to  make changes  to  the  subject line  by  simply  typing over  it,
>   without having  to use a  (line mode) SUBJECT command.  Similarly I'd
>...

I second the motion.  But what happens if Unsmart Normaluser by accident
overtypes a header line, and doesn't remember what it was supposed to be?


>9. Just for fun
>...
>         Barry Hathaway     1/11/90*PROFS acknowledgements and reo
>         Richard A. Schafer 1/11/90 PROFS acknowledgements and reo
>   I  checked the  time stamps:  Richard's  was 13:13:57  CST, which  is
>   19:13:57 UT  and Barry's was  15:08:51 EDT  which is 19:08:51  UT. So
>   the software  was correct: Fast-As-Lightning-Barry  responded roughly
>   five minutes before Richard asked.

Somebody's system TIME CLOCK set a "bit" wrong?

Regards.
Scott/

NJG@CORNELLA.BITNET (Nick Gimbrone) (01/17/90)

On Tue, 16 Jan 90 23:57:17 SET Scott Ophof said:
>On Fri, 12 Jan 90 14:06:31 CET Rainer M Woitok said:
>>4. New sorting column STATUS (or similar)
>>   Since I can now sort according  to multiple columns, I'd like also to
>>   be able to sort according to the  status field, where either ' ' (old
>>   mail), '>'  (new mail) or  '-' (mail  to be discarded)  is displayed.
>>   Thus I could cleanly separate old from new mail.
>be a "trivial"(?) coding exercise, methinks...
I think it is even more trivial to do it in the MAILB00K code (did it
originally back in 7/89). Here's the 89.02.0A version (not yet on 0B,
but this may also work there):

./ I 08910000          $ 8910001 1                    07/17/89 20:36:28
/* Following select must have items in numeric order, sigh */ /*ml071*/
./ I 08975950          $ 8975951 1                    07/17/89 20:36:28
    When(cursor.4 <= global.date_column.beg - 1) Then,
       cols = global.date_column.beg-1 global.date_column.beg-1
       /* delete/unread flag */                               /*ml071*/

What could be easier :-).

>Somebody's system TIME CLOCK set a "bit" wrong?
Jezz, we have 5 cpus in one room that often differ that that much (or
or more :-).

NJG@CORNELLA.BITNET (Nick Gimbrone) (01/17/90)

On Fri, 12 Jan 90 14:06:31 CET Rainer M Woitok said:
>3. I'd like to see a SELECTD command
Why not just "select" the items then use "delete *" to get rid of them
all... (last time I tried it this was a bit noisy, but perhaps that could
be fixed :-). No need for a new command when two simple ones will do.
>6. TIME.ZONES option
>   My private  TIMEZONE TABLE  file contains  slightly less  than eighty
>   entries  of  time zones  I've  encountered.  Even  if I  omit  rather
>   strange ones,  they clearly don't  fit into  a single line.  Thus I'd
>   prefer the  TIME.ZONE option  to specify a  file containing  the time
You could just have the macro pick up the contents of the file and put
it into a string to set the option (or have the option set via a
variable set in your macro in any of (most likely) hundreds of
ways...).  No changes to the base mailbook code needed...

MAINT@CLVM.BITNET (Richard Seifert(IBM Systems Maintenance)) (01/17/90)

On Wed, 17 Jan 90 09:32:22 ECT Jim Blake said:
>>
>>5. Editing the header part
>>   This topic  has already been discussed  here, but I'd like  to add my
>>   two cents:  Since I'm working  in a fullscreen environment,  I'd like
>>   to  make changes  to  the  subject line  by  simply  typing over  it,
>>   without having  to use a  (line mode) SUBJECT command.  Similarly I'd
>>...
>>
>
>Don't weaken, Richard. I do not want to hear the complaints from the
>unsavvy users who clobbered their headers.
>
>Unless you wanted to make it yet another option. Say...HEADER.CLOBBER=OK
>
>jb

     Just to add my opinion, I sort of like Jim's idea.  It is handy (at times)
 to be able to alter the header, if you know what you are doing.  However,
 Joe-Fred User, who may or may not know what he is doing, should probably not
 be allowed to make the same alterations.

Rich

AS0JEB@BINGVMA.BITNET (Jim Blake) (01/18/90)

>
>5. Editing the header part
>   This topic  has already been discussed  here, but I'd like  to add my
>   two cents:  Since I'm working  in a fullscreen environment,  I'd like
>   to  make changes  to  the  subject line  by  simply  typing over  it,
>   without having  to use a  (line mode) SUBJECT command.  Similarly I'd
>...
>

Don't weaken, Richard. I do not want to hear the complaints from the
unsavvy users who clobbered their headers.

Unless you wanted to make it yet another option. Say...HEADER.CLOBBER=OK

jb

MICHAEL@UTORONTO.BITNET (Michael Wagner) (01/18/90)

>>Somebody's system TIME CLOCK set a "bit" wrong?
>Jezz, we have 5 cpus in one room that often differ that that much (or
>or more :-).

Which seems like a good reason, to me, not to use date/time as a
sort field for the "intuitive" order, which is who replied to whom.

Michael

JAUUS@CUVMB.BITNET (jbaltz) (01/18/90)

On Wed, 17 Jan 90 11:09:12 EDT Richard Seifert(IBM Systems Maintenance) said:
>
> Just to add my opinion, I sort of like Jim's idea.  It is handy (at times)
>to be able to alter the header, if you know what you are doing.  However,
>Joe-Fred User, who may or may not know what he is doing, should probably not
>be allowed to make the same alterations.
>

Better yet would be to have a variable (either NOVICE or EXPERT, either
one) that would
a) allow you to edit headers
b) shorten the final message to something like:
purge nn msgs? ynm

&c. I'm sure if I sat down to think I could come up with more :)

DISCLAIMER: I don't speak for Columbia, and Columbia doesn't speak for me

//jbaltz
Jerry B. Altzman
jbaltz@cunixf.cc.columbia.edu    jauus@CUVMB    NEVIS::JBALTZ (HEPnet)
+1 212 854 8058

MAINT@DERRZE1.BITNET (Rainer M Woitok) (01/18/90)

On Tue, 16 Jan 90 23:57:17 SET Scott Ophof said:
>On Fri, 12 Jan 90 14:06:31 CET Rainer M Woitok said:
>> ...
>>   I  checked the  time stamps:  Richard's  was 13:13:57  CST, which  is
>>   19:13:57 UT  and Barry's was  15:08:51 EDT  which is 19:08:51  UT.
>> ...
>
>Somebody's system TIME CLOCK set a "bit" wrong?

Not  necessarily. Look  at  Barry's  time zone.  I  says  "EDT", but  it
probably  should still  read "EST"  (we're  only in  January now).  This
points to a general deficiency of  the way, computer vendors are dealing
with the  computer system clock and  time zone. Almost all  computers we
had so  far had  to be brought  down and re-IPLed  to change  the system
clock,  and our  IBM even  needed a  system generation  twice a  year to
change  the time  zone  information  (we now  have  installed  a mod,  I
obtained from John F. Chandler  <PEPMNT@CFAAMP> over the net, which does
the change of time and time zone twice a year automagically).

Sincerely
 Rainer

.----------------------------------------------------------------------.
| Rainer M. Woitok                 | Phone  : (+49 9131) 85-7811,-7031 |
| Regionales Rechenzentrum         | Fax    : (+49 9131) 30 29 41      |
| Friedrich-Alexander-Universitaet | Telex  : d 629 755 tf erl         |
| D-8520 Erlangen                  | e-Mail : MAINT@DERRZE1.BITNET     |
| West Germany                     |                                   |
'----------------------------------------------------------------------'

MAINT@DERRZE1.BITNET (Rainer M Woitok) (01/18/90)

On Tue, 16 Jan 90 22:31:57 EST Nick Gimbrone said:
>On Fri, 12 Jan 90 14:06:31 CET Rainer M Woitok said:
>>3. I'd like to see a SELECTD command
>Why not just "select" the items then use "delete *" to get rid of them
>all...

Neither  does HELP  DISCARD or  HELD DELETE  mention "*"  as a  possible
argument nor  does my 89-02-0A version  support it. If I  issue "DISCARD
*" after having  selected some items, I  get a message to  the effect of
Value "*" not allowed.

> ...
>>6. TIME.ZONES option
>>   My private  TIMEZONE TABLE  file contains  slightly less  than eighty
>>   entries  of  time zones  I've  encountered.  Even  if I  omit  rather
>>   strange ones,  they clearly don't  fit into  a single line.  Thus I'd
>>   prefer the  TIME.ZONE option  to specify a  file containing  the time
>You could just have the macro pick up the contents of the file and put
>it into a string to set the option (or have the option set via a
>variable set in your macro in any of (most likely) hundreds of
>ways...).  No changes to the base mailbook code needed...

For the  sake of argument lets  assume only 50 time  zones (there should
be approximately 24  round the globe (standard) plus the  same 24 during
the  summer (daylight)  plus some  widespread synonyms  like UT  for GMT
etc). Then you have

      50 * 3 = 150 chars for the time zone abbreviation
      50 * 1 =  50 blanks to separate zone name from value
 -1 + 50 * 1 =  49 blanks to separate value from next zone
      10 * 1 =  10 digits for positive offsets < 10
       4 * 2 =   8 digits for positive offsets > 9 (offset may be as big as 13)
      10 * 2 =  20 digits for negative offsets < 10
       4 * 3 =  12 digits for negative offsets > 9
              -----
               299 characters needed for the value


This number is  reduced a bit because some time  zone abbreviations only
use two characters,  but there are less than 44  two character time zone
abbreviations  in  my  file.  Since  GLOBALV  imposes  a  limit  of  255
characters on  the value's length,  SETMAIL will somehow or  other choke
on it or at  least truncate it. So, as far as I  see, there is currently
no way to do that (let alone hundreds).

Sincerely
 Rainer

.----------------------------------------------------------------------.
| Rainer M. Woitok                 | Phone  : (+49 9131) 85-7811,-7031 |
| Regionales Rechenzentrum         | Fax    : (+49 9131) 30 29 41      |
| Friedrich-Alexander-Universitaet | Telex  : d 629 755 tf erl         |
| D-8520 Erlangen                  | e-Mail : MAINT@DERRZE1.BITNET     |
| West Germany                     |                                   |
'----------------------------------------------------------------------'

NADWL@HDEDH1.BITNET (Scott Ophof) (01/18/90)

On Wed, 17 Jan 90 09:32:22 ECT Jim Blake said:
>>5. Editing the header part
>>...
>Unless you wanted to make it yet another option. Say...HEADER.CLOBBER=OK

That would also mean adding the option:

      DEFAULT.RESPONSIBLE.IF.ERRORS=userid()

where no nicknames or nodeids would be accepted, and any other value than the
invoker's would result in a (reverse) highlighted, blinking, beeping screen...

Regards.
Scott/

NADWL@HDEDH1.BITNET (Scott Ophof) (01/18/90)

On Wed, 17 Jan 90 15:43:11 CET Rainer M Woitok said:
>On Tue, 16 Jan 90 22:31:57 EST Nick Gimbrone said:
>>On Fri, 12 Jan 90 14:06:31 CET Rainer M Woitok said:
>> ...
>>>6. TIME.ZONES option
>>>...
>For the  sake of argument lets  assume only 50 time  zones (there should
>be approximately 24  round the globe (standard) plus the  same 24 during
>the  summer (daylight)  plus some  widespread synonyms  like UT  for GMT
>etc). Then you have
>...
>               299 characters needed for the value
>...
>abbreviations  in  my  file.  Since  GLOBALV  imposes  a  limit  of  255
>characters on  the value's length,  SETMAIL will somehow or  other choke
>...

So put the standard zones in one global variable, and the daylight savers in
another?

Regards.
Scott/

MAINT@DERRZE1.BITNET (Rainer M Woitok) (01/18/90)

On Wed, 17 Jan 90 09:32:22 ECT Jim Blake said:
>Don't weaken, Richard. I do not want to hear the complaints from the
>unsavvy users who clobbered their headers.
>
>Unless you wanted to make it yet another option. Say...HEADER.CLOBBER=OK

I can't quite see your point.  As I understand it, before release 89-02-
0A  it was  always  possible to  clobber  your headers.  You  did get  a
warning message,  but only  after the headers  were destroyed.  Did this
former possibility of clobbering the headers cause any serious problems?

By the way,  if you would do it  in a very noble way,  the program could
save the  original headers  before you clobber  them, check  them before
really sending  the mail (of  course only if  they were changed  at all)
and refuse to send  when the headers are rotten. It'd then  be up to you
to unclobber the headers, possibly by  typing something to the effect of
RECOVER or UNDO to again get the original headers.

Sincerely
 Rainer

.----------------------------------------------------------------------.
| Rainer M. Woitok                 | Phone  : (+49 9131) 85-7811,-7031 |
| Regionales Rechenzentrum         | Fax    : (+49 9131) 30 29 41      |
| Friedrich-Alexander-Universitaet | Telex  : d 629 755 tf erl         |
| D-8520 Erlangen                  | e-Mail : MAINT@DERRZE1.BITNET     |
| West Germany                     |                                   |
'----------------------------------------------------------------------'

GKMCU@CUNYVM.BITNET (Geert K. Marien) (01/19/90)

>On Tue, 16 Jan 90 22:31:57 EST Nick Gimbrone said:
>>On Fri, 12 Jan 90 14:06:31 CET Rainer M Woitok said:
>>>3. I'd like to see a SELECTD command
>>Why not just "select" the items then use "delete *" to get rid of them
>>all...
>
>Neither  does HELP  DISCARD or  HELD DELETE  mention "*"  as a  possible
>argument nor  does my 89-02-0A version  support it. If I  issue "DISCARD
>*" after having  selected some items, I  get a message to  the effect of
>Value "*" not allowed.

I have a mod for 89.01 version 0B that allows a DELETE * (and also an
UNDELETE *) option.  It works just like (un)DELETE 1:*.  The price is right.

/Geert

CMS2@ETSU.BITNET (Bill Williams) (01/19/90)

On Wed, 17 Jan 90 09:32:22 ECT Jim Blake said:
>>5. Editing the header part
>>   This topic  has already been discussed  here, but I'd like  to add my
>>   two cents:  Since I'm working  in a fullscreen environment,  I'd like
>>   to  make changes  to  the  subject line  by  simply  typing over  it,
>>   without having  to use a  (line mode) SUBJECT command.  Similarly I'd
>>...
>Don't weaken, Richard. I do not want to hear the complaints from the
>unsavvy users who clobbered their headers.

I don't mind the BSMTP envelope idea, but I now *need* an option to do a
"temporary" CHECK.LOCAL.ID=NO for "just this mail item".

OR perhaps a 'pc: userid' like the cc: and bcc: options which indicates
a pseudo-id instead of the option to override the CHECK.LOCAL.ID.

It is necessary sometimes to MAIL to a pseudo local user -- for example:
    MAIL C_CLASS
where C_CLASS is not really a local userid but rather a LIST defined in
our MAILER (r2.05).

Yes, I can set my CHECK option to NO, do the MAIL and then set my CHECK
back to YES, but the main use of the MAILER LIST capability is for
(*gasp*) users.  Since users are the very ones with the expertise to
really trash the headers by editing them, they are the very ones I don't
want to be able to 'edit' the headers.  And they need to be watched over
in events where they are actually misspelling the name of the target and
ending up with a genuinely wrong destination; this means that they need
to do something deliberate in order to *know* that they're specifying a
pseudo user -- the list.

Or perhaps some special :tag.value in the names file for the given LIST
to tell MAIL that this user's Ok.  Maybe a :node. with non-valid node
name characters to indicate that this is a local pseudo user?

Any "easy to set up for the end user"  (we're talkin faculty, here)
method for using MAIL to talk to the MAILER defined LIST userid would be
helpful.  Or is the best thing to simply create dummy CMS userids for each
list-name in MAILER and just let the rough side drag?   :-)

BTW: I'm OCO for MAIL/MAILBOOK.
----------
    B.R.Wms

MAINTCMS@PUCC.BITNET (John Wagner) (01/19/90)

A nice change would be to always support 'POSTMASTER' no matter what
the check.local.id value is set to.

   John Wagner