On Fri, 5 Jul 1996, Jason L Tibbitts III wrote:
> BR> But we should have Approved: be treated the same, no matter where it is
> BR> placed.
>
> No, it's impossible to avoid ambiguity if you do it that way. An approved:
> in the header must accept those headers and not do any processing on the
> body. An Approved: in the body can be followed by headers to be used
> instead of the normal ones.
Ok, I guess I'll live with it :) That sounds reasonable.
> BR> Headers should NEVER be thrown away except Approved: and some other
> BR> specific ones. They can either be added to, replaced or deleted (only
> BR> if done specifically).
>
> No, you can't do this. If you see headers after Approved: in the body, you
> must throw out all previous headers. Why? Well, my mailer adds X-Mailer:,
> yours might add X-Face:. You don't want any of the moderator's headers
> stuck in the outgoing message. Remember also that before resend gets it
> the MTA till have tacked on at least one Received: which you don't want in
> there. Also note that To: is not a required header, but the message from
> the moderator will most likely have one.
Gotcha, also agreed now.
> BR> Also, I want to write a small specification paper as to how we'll
> BR> handle headers and Approved: so that we have no problems understanding
> BR> each other and others have something to look at.
>
> OK. I was hoping to get a preliminary patch out before I left but I just
> got sidetracked on the approval password thing. I decided that was a
> little more important.
I read what you have below and that seems to be the jist of it. I'm going
to post a small message to majordomo-users (since we have a week before
work starts on this) and just see what people might have to say.
> BR> As soon as we make the final decisions listed above I'll start working
> BR> on it.
>
> I have a feeling discussion has ended for tonight, so I'm out of it for
> another week. I think everything was basically cleared up except for the
> bit about throwing away headers vs selectively replacing/deleting them. I
> kind of feel strongly that we just can't do it the way you're talking about
> with the reasonably small fixes I'm trying to get in, so I think we should
> just sit on these three approval methods:
>
> 1. Put Approved: in the headers; it will be removed and message will go out
> without requiring approval. (This already works.)
>
> 2. Put Approved: as the first line of the body, a blank line, then the body
> of the message to go out. The normal message headers will be used, the
> Approved: and the blank line will be deleted.
>
> 3. Put Approved: as the first line of the body, immediately followed by a
> complete message (comprised of headers, blank line, body). Original
> headers will be thrown out and replaced by everything between Approved: and
> the first blank line.
Ok, I'm agreed on all three. What you've written above seems to clear-up
all ambiguities and still set a defined way of handling Approved: in each
case w/o too much difference overall.
One problem I forsee though is in the difference in handling in number two
and number three (which have now changed numbers). #2 above uses the set
headers while #3 throws out and puts in new ones. Since both have Approved:
in the same place, how will majordomo know the difference? We have to make
sure that in #2 (above) that the message doesn't get sent out w/o headers.
> Now, the only issue left is whether the headers included should get altered
> as normal message headers do (subject_prefix, strip, etc.) I need to stare
> at the code to see if strip gets done, but subject_prefix doesn't seem to.
> This may be a sticky issue, but I won't be able to really tell until I get
> deep into it.
I think it's a matter of "principle" here. Either we allow subject_prefix,
etc etc or we don't. If they're there then we have to allow it. If we
can't do it then we have to take them out.
-------------------------------------------------------------------------
| Brock Rozen | brozen@netvoyage.net | http://www.netvoyage.net/~brozen |
-------------------------------------------------------------------------
References:
|
|
