>>>>> "PAR" == Paul Allen Rice <PaulRice@Broadcast.Net> writes:
PAR> I can see where this would be helpful for some things, but as tight as
PAR> I run my ships...
The point is that the BOUNCE message comes from Majordomo and the response
to it is supposed to go back to Majordomo. I'd point you at the reject
script at my FTP site, but I doubt you could make use of it because, like
the approve script, it requires Unix and perl.
PAR> I'm not just being a power-weilding dictator about it, I want the
PAR> luser to LEARN what's going on.
OK, well, the point is that in an ideal implementation you don't
communicate with the luser; Majordomo acts as an arbitrator and both you
and the luser see things from it. It could be considered a deficiency in
the current implementation that it doesn't work that way.
I suppose given the current implementation you could make an argument for
making the luser's address prominent because the majordomo address is
already well known while the luser's is not. But then things are moving
closer to the ideal implementation with 2.0 and there is absolutely no way
that anyone's insane enough to change current practise for 1.94.x.
PAR> Since most email clients that I know of that have automation
PAR> capabilities use the SENDER:, FROM: or REPLY-TO: headers to send their
PAR> replies to, an X-Header wouldn't do any good.
You miss the point. You said it was hard to find it to cut-and-paste it.
I was offering to at least put it in the header.
PAR> Choosing what items to bounce replies to majordomo, and what items to
PAR> bounce to the sender.
Done in 2.0. Next?
PAR> In some ways I would prefer the major send the luser himself the
PAR> bounce saying something to the effect of... "sorry, luser, you don't
PAR> belong here, trying subbing first, then posting."
Done in 2.0. Next?
PAR> or "you used a bad word. please try again", of course in more
PAR> appropriate terms, but you get what I mean.
Done in 2.0. Is it getting old yet?
In 2.0 you have fine-grained control via a (very) simple programming
language-like thing embedded within the server. Taboo and admin matches
can have severities attached to them (although I haven't finished coding up
numeric comparisons in the language so you can't yet make use of them).
You can have different responses for different severities, or for different
classes of subscribers, or for admin and taboo matches, or whatever. You
can let your inner circle say all of those nasty 'subscribe' words without
being bounced. You can bounce some things to the owner, drop others in the
trash can, and even send some back to the requester/poster to make sure
that they really wanted to do that. You can customize (almost) all of the
messages that the server generates, and even upload new ones. Yes, all of
this really does work today (except the severity stuff). It still has bugs
and isn't necessarily optimal yet (and it sure as hell isn't properly
documented), but these aren't just vaporous features. (Though I will say
that acknowledgment of owner-rejected tokens is a yet-to-be-implemented
feature, because I'm still trying to figure out how to let the owner reject
a token with an explanation. All in good time.)
But I have to get back to coding....
- J<
References:
|
|
