My connecting flights were cancelled, so I'm here foe another day.
>>>>> "BR" == Brock Rozen <firstname.lastname@example.org> writes:
BR> If somebody can do #3 than they can definetly do #2, so what's the
Say I want to mail an announcement to my moderated list and I use a mailer
that won't let me add to the header. I either put an approved line as the
first line of the body (#3); Majordomo removes it but otherwise passes the
message unchanged. If you can't do #3, you have to mail the message, then
approve it yourself, which is inconvenient. Recall that this gets asked
rather often on majordomo-users.
BR> Regardless, wouldn't it take majordomo more processing with #2 because
BR> when it finds the Approved header it also needs to verify that headers
BR> exist after it, but in #3 it just finds Approved and processes without
BR> regard to headers (if they exist then it turns into #2).
BR> We need to use SOME SORT of standard in regards to headers. I think #4
BR> and #5 don't help us come anywhere close to this.
I agree. If I can think of a simple way of handling some of the more
common cases I'll play with it, but otherwise I think it's not worth it.
BR> Did majordomo allow these types of approval up to now?
I think it's up in the air because it's not well documented at all. The
question probably is: which approval methods _should_ be allowed?
BR> Wait a minute. Since the general specification for setting headers (I'm
BR> talking in perl or otherwise, not specifically majordomo) is to set the
BR> headers, then issue a blank line (\n\n) between the headers and the
BR> message. Why not have majordomo follow the same specification?
It's not documented to work that way. Or is it? Hmmm, there doesn't seem
to be too much documentation on this, which means we're pretty free to mess
with it. That's probably better than what I was thinking; I thought we had
to allow the blank line between Approved: and the rest of the headers. If
we don't then we're set.
BR> I think allowing for two different types of headers for approval gets
BR> very tricky, complicated and confusing. Especially when one becomes
BR> disallowed for one type of approval and another for another.
I do too. If we can use the blank line to signal the start of body or
headers and body, we're set.
BR> I also agree with the proposal of ignoring #4 and #5 and allowing 1, 2
BR> and 3. I disagree with Approved-Body: and think we should use the blank
BR> line method to distinguish between headers and message body.
I think we're in agreement now.
BR> Hope you have (had by the time you read this?) a good vacation.
Jason L. Tibbitts III - email@example.com - 713/743-8684 - 221SR1
System Manager: University of Houston High Performance Computing Center
1994 PC800 "Kuroneko" DoD# 1723