Great Circle Associates Majordomo-Users
(April 1999)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Re: Approved: password
From: Vicki Brown <vlb @ cfcl . com>
Date: Mon, 19 Apr 1999 12:50:56 -0700
To: Majordomo-Users @ GreatCircle . COM
In-reply-to: <377e5584.2358803840@smtp.omsys.com>
References: <v04204d02b33d6a12c79c@[207.135.77.148]><377e5584.2358803840@smtp.omsys.com>

At 22:50 -0500 4/17/99, tibbs@hpc.uh.edu wrote:
> The problem is that you never told anyone exactly what you sent to your
> list, nor did you include a copy of what you got back.  So it is extremely
> difficult for anyone to tell you what is going on.

Yes, I did. I told you I sent exactly what the docs told me to send (as far
as I could tell).  Line for line exactly. Approved at the top. No blank
lines. Take off the extra headers. Include all tof the original message
headers. I even told you which docs I used (list-owner-info).


At 04:00 +0000 4/18/99, Jeremy H. Griffith wrote:
> Here are the secret rules:

Gotta love them secret rules...

>
> 1. Make sure there is *no blank line* between the headers your mail
> client is providing, and the Approved: line.  That is the likely cause
> of your experience; the Approved: line then becomes the start of the
> message, instead of being seen as a header.

I would guess that a blank line got in there.  Not "I put one in" but "it
was put in for me when I sent the mail". Looking at my sent message, in my
sent-mail box, I see:

  To: scientists@company.com
  From: User Name <uname@company.com>
  Subject: lab cleanup
  Cc:
  Bcc:
  X-Attachments: :mouse1*:12633:Lab Duties 4/16/99:

  Approved: PASSWORD
  X-Sender: uname@company.com
  Message-Id: <v04011703b33d246285b2@[207.135.77.175]>
  Date: Fri, 16 Apr 1999 11:32:07 -0700
  To: scientists@company.com
  From: User Name <uname@company.com>
  Subject: lab cleanup

Of course, lines 1-7 weren't visible when I edited the message for sending.

<rant>
If a blank line got in there, apparently my mail client did it for me, as I
most assuredly did not put it in myself. If my client did it for me, I
cannot tell it not to. More to the point, this is _not_ a rare and unusual
mail client. If my mail client helpfully stuck a blank line in before the
first line of my posting, then you can bet your last dollar Someone Else's
mail client is going to do this too.

Which means that the requirement that "*no blank line* between the headers
the mail client is providing, and the Approved: line.", is a bad
requirement because it cannot be forced to be true. (Actually it's a bad
requirement anyway but we won't go there).

Thus the program at the other end, Majordomo, must take into account the
possibility that a blank line WILL be in this position... and must deal
with it.

And no, you can't say "Well, use Unix `mail'" or "use Pine" or "use approve
from the command line".  Because you can't know that the person approving a
given message even has Unix shell access. And because Majordomo is supposed
to be able to be administered via email. The point of a good interface is
to realize that things may come to it from funny unknown places. Counting
on vagaries of spacing is a Bad Idea.

If Majordomo is _consistently_ successful at reading my "auth" commands,
_consistently_ successful at reading my subscribe commands, _consistently_
successful at parsing who, lists, and info commands and _consistently_
successful at understanding
     approve password subscribe fred listname

but consistently unsuccessful (2 for 2, bad average) in terms of correctly
approving a BOUNCE message (well, it approved the message all right...),
then perhaps the error is not with the user.

I appreciate that you have tested this "hundreds of times" but I must point
out that you are testing in a poor laboratory. You _know_ what to do, You
_know_ what to expect, and You _know_ which email client you are using. I
hate to say this, but your tests are rigged.

So once again before I leave... will someone in a position to do so please
ensure that _Majordomo 2.0_ is sensible about finding, catching, parsing,
and then _removing_ Approved: password lines in messages.  Not based on
some funny squiggly unenforceable requirement for specialized spacing.
Just Do It.

Thank you.

</rant>
---
      |\      _,,,---,,_       Vicki Brown <vlb@cfcl.com>
ZZZzz /,`.-'`'    -.  ;-;;,_   Journeyman Sourceror: Scripts & Philtres
     |,4-  ) )-,_. ,\ (  `'-'  P.O. Box 1269  San Bruno  CA  94066
    '---''(_/--'  `-'\_) http://www.cfcl.com/~vlb  http://www.macperl.org



Follow-Ups:
References:
Indexed By Date Previous: Can't get 'Sender' to work
From: "Brett G. Durrett" <bdurrett@slick.ORG>
Next: usability of MJ 2.0
From: "Otis Gospodnetic" <otis@DOMINIS.com>
Indexed By Thread Previous: Re: Approved: password
From: Jeffrey Goldberg <J.Goldberg@Cranfield.ac.uk>
Next: Re: Approved: password
From: Dave Sill <de5@sws5.ctd.ornl.gov>

Google
 
Search Internet Search www.greatcircle.com