Vicki Brown <vlb@cfcl.com> wrote:
>
>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.
That looks correct. You say the message was delivered, but the
Approved field wasn't stripped? Did the Date and Message-Id fields in
the copy you received match these?
><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.
Don't be coy. What mailer did you use? I'm not aware of any mailers
that insert extra lines, but it's possible.
>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).
The approval interface is arguably bad, but many thousands of lists
have used it for several years, so it's at least usable.
>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.
But it doesn't, and nobody has ever claimed a need for it to, which is
why it's unlikely that the need has suddenly come up now.
>...
>
>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.
There are a few possibilities:
(1) majordomo has a bug in the approval process that leaks
passwords,
(2) you're not sending the messages in the right format,
(3) something is munging your properly-formatted messages before
they get to majordomo, or
(4) majordomo and/or your list is misconfigured.
(1) is very unlikely since nobody else is seeing the same
behavior. Before people will takes claims of (1) seriously, you'll
have to eliminate (2)-(4) or provide better documentation.
(2) seems unlikely given the snippet above from your sent-mail
folder.
(3) is possible, and could be confirmed by modifying the list alias to
log a copy of incoming messages to a file, e.g., assuming sendmail:
listname: "|/blah/blah/wrapper resend blah", /foo/bar/listname
(4) is possible, and might be confirmed by providing:
a copy of a message resent by majordomo that contains a password,
content of all of the list's aliases
copy of the list's config file
You should probably start by creating a test list with yourself as the
only subscriber.
>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.
But they're not "tests", they're production lists that live on
thousands of majordomo servers serving many thousands of lists. This
*does* work consistently.
-Dave
Follow-Ups:
References:
|
|
