On 3 Jul 1996, Jason L Tibbitts III wrote:
> [The recipient list is getting a bit long now; please trim the line
> appropriately for followups.]
It's necessary as all of us are involved in this process.
> >>>>> "BR" == Brock Rozen <brozen@netvoyage.net> writes:
>
> BR> But I'm interested, *what* exactly is going to be fixed or changed in
> BR> regards to this?
>
> Well, refer to Chan's message. If we write things to be as permissible as
> possible, we have five approval formats:
>
> 1. Approved: in the headers.
> 2. Approved: as first line in the body, followed by headers and body of
> approved message.
> 3. Approved: as first line in the body, followed by rest of message.
> 4, 5. Approved: somewhere in body, followed by headers and body or just
> body.
>
> Now #1 is great if you want to send a posting without being asked for your
> approval. (Say, you're sending an announcement.) #2 is what approve uses.
> #3 is for poor souls who have pitiful mailer software that won't let them
> add to the header. #4 and #5 are for those whose mailers add junk, like
> CC:mail.
>
> Chan proposes disallowing #3. It's really only a convenience to keep
> things from being bounced to the moderator if the submitter knows the
> password and has a stupid mailer. I think it would be nice to allow it
> just because, but only if it can be done cleanly. Thoughts?
If somebody can do #3 than they can definetly do #2, so what's the
difference? In #3 majordomo would use the headers already present in the
message. In #2 the user supplies the headers. I don't think there's any
reason to disallow #3, and actually, I think it's something good to have.
Regardless, wouldn't it take majordomo more processing with #2 because
when it finds the Approved header it also needs to verify that headers
exist after it, but in #3 it just finds Approved and processes without
regard to headers (if they exist then it turns into #2).
> I don't think #4 and #5 are worth it, because these mailers tend to do other
> stupid things like indent every line in the body with tabs and other junk.
> Unfortunately not allowing these actually prevents some users from running
> lists at all, at least until they get better software. Disallowing #3 just
> makes things inconvenient. It's not hard to allow either of these if you
> don't worry about dealing with the other manglings these mailers commit,
> but it makes the next point much worse.
We need to use SOME SORT of standard in regards to headers. I think #4 and
#5 don't help us come anywhere close to this.
Did majordomo allow these types of approval up to now? If not, then why
should we start? Has anybody requested it? If yes, then those people can
continue using outdated versions of majordomo. Hey, they're already using
outdated mail software (if they can't do any of the other methods they
*must* be).
> Note that allowing both #2 and #3 introduces an ambiguity; how can you tell
> that what follows is headers or body? To solve this I propose that instead
> of Approved:, the string Approved-Body: be used in #3 to indicate that the
> body is approved but that the original headers be kept. This is added
> complexity, which isn't great since people with braindead software tend not
> to know much about what's going on but I can't see another way around it.
> We're adding capability here.
Wait a minute. Since the general specification for setting headers (I'm
talking in perl or otherwise, not specifically majordomo) is to set the
headers, then issue a blank line (\n\n) between the headers and the
message. Why not have majordomo follow the same specification? Approved:
would be the first header. Everything up until a blank line would also be
considered a header. Thus, if the person wants only Approved: w/o headers
then they just put a blank line after Approved:, otherwise they add
headers IMMEDIATELY and when they're done they insert a blank line between
headers and message. I also believe that this is how 1.93 handled
Approved: and additional headers.
I think allowing for two different types of headers for approval gets very
tricky, complicated and confusing. Especially when one becomes disallowed
for one type of approval and another for another.
> So I propose ignoring #4 and #5, allowing #'s 1, 2, and 3, and using
> Approved-Body: to indicate #3. This is just an idea; I haven't actually
> done anything and would love to see a better solution. Please make
> suggestions and argue about it at leisure; I'll be here for just a few more
> hours but I archive all of this so I'll read it when I get back.
I also agree with the proposal of ignoring #4 and #5 and allowing 1, 2 and
3. I disagree with Approved-Body: and think we should use the blank line
method to distinguish between headers and message body.
Hope you have (had by the time you read this?) a good vacation.
-------------------------------------------------------------------------
| Brock Rozen | brozen@netvoyage.net | http://www.netvoyage.net/~brozen |
-------------------------------------------------------------------------
Follow-Ups:
References:
|
|
