When I said that I personally dislike tagged subjects,
philo(_at_)radix(_dot_)net shared,
| From the LISTSERV online documentation:
| http://www.lsoft.com/manuals/user/user.html#2.13
|
| The new SUBJECTHDR (minimum abbreviation: SUBJ) header option is provided
| for users who want to see a "tag" in the subject line of their incoming
| list mail that indicates where the mail is coming from (e.g., to activate a
| filter in their mail program to drop the message into a specified
| notebook). SUBJECTHDR is slightly different from the other header options,
| as it simply adds to the existing header definition--for instance, if the
| user is already set to DUALHDR, a SET listname SUBJ command leaves DUALHDR
| in effect and just adds the tag to the subject line. To turn off the
| subject tags, the user simply sets another header option, which
| automatically turns the SUBJECTHDR option off.
Yes, that's very true of LISTSERV. But not all lists run under LISTSERV.
This one, for example, runs under SmartList, where the equivalent behavior
can be patched in, but it then affects all members. With Majordomo, there
is a per-list setting for it (and it is buggy, as I said, not recognizing
"RE:" as equivalent to "Re:" for example). Individual members do not have
individual choices with SmartList and Majordomo.
That said, I have my own homebrew mailing list concoction, and as with
LISTSERV I offer it as an option (without forcing it on all members and
without the bugs in Majordomo's implementation) and DUALHDR is another option
I offer, though I do not have a way for a member to get both SUBJECTHDR and
DUALHDR. (Right now no one is using either option any longer.)
| In other words, if you don't like it, turn it off.
Correction: "If you don't like it, don't turn it on," as it is never the
default for new subscriptions. And guess what, Philo: when I'm on a list
running under LISTSERV, I don't turn SUBJECTHDR on (nor DUALHDR for that
matter).
But when I'm on a list where it is forced on all members, I can either put
up with it or make more work for procmail (and a fork to formail or sed)
by taking it out in my .procmailrc.