mailinglists ...

Gerard Beekmans gerard at
Mon Nov 20 20:32:10 PST 2000

> My apologies. I plead lack of a FAQ :)


> Erm, last i heard, "From " was not a header but rather the unix mailbox
> format's message seperator. Most client's probably can filter based
> on it, but....

Last I heard, I heard the same. I plead I've been trying to convert a 
Mandrake system to LFS while keeping the password database intact which uses 
MD5 passwords and PAM so I had to install PAM and libpwdb was giving me major 
headaches...I haven't been all here today with my replies.

> My full argument goes like this:

And I understand your reasoning. As you probably have been opinions are 
divided on the matter. Some would like to see the subject tags, other don't 
want to see it and others don't care whether the tags come in place or not.

I realize that if a message is bcc'ed to a list, filtering on To: or CC: 
doesn't do any good. Then you can use the "From " header if your mail client 
does a decent job. I know KMail itself doesn't. It transforms the "From " 
header into "From sender at `date`" instead of how it was sent out by 
linuxfromscratch "From listname-owner at `date`"

So yes there clients that deviate from conventions a bit and change certain 
headers around. I have this thing where I don't want to start making up for 
the 'brokeness' of certain clients. I also know how dependant and fond one 
becomes of an email client and saying "well, then you should switch to 
something worth being called an email client" is too harsh too (unless you 
use MS Outlook. Then I don't have mercy ;) So my own arguments are divided as 
well. On one hand I don't mind putting the subject tags in place so that 
every single email client has something to filter on. On the other hand it 
just doesn't look great when you look in your lfs-discuss mail folder and see 
[LFS-DISCUSS] everywhere. I find it a mess (I've tried it by sed'ing through 
the mbox file and appending that subject tag everywhere) so I am reluctant to 
do so.

So it comes down to:
1) I can make the change for the better for some people, for the worse for 
2) I can leave it as it is for the better of some people, for the worse for 

If I do make the change it doesn't really make things worse for people. It 
doesn't screw any filters up since nobody is filtering on Subject: anyways. 
But it will look messy which I know some of us won't appreciate (I'll get 
used to it and don't care after a while I know that for myself).

There is a third option:
3) Hack Listar and invent a custom header. Call it:
	X-LFS-Mailinglist: listname

If anything will be done, it's trying to get Listar to send the 
X-LFS-Mailinglist: header along with every email and if somebody emails with 
X-Mailinglist: in place, enforce a change to the current list (to stop 
prankers from sending an email to lfs-discuss with an X-LFS-Mailinglist: 
lfs-apps header).

The good things about option number 3:
1) It won't break any current filter setups
2) It's perfectly legal to invent an X- header so we won't break email clients
3) It's the only way to guarantee a perfect filtering even with CC and BCC 
and when TO: and CC: contain two different lists (cross-posts), 
X-LFS-Mailinglist: will still only contain one list and the post will end up 
in the proper mailbox

The bad things I can think of:
1) it will increase every email by max. 31 characters. Big deal? I doubt it.
2) I know there are MDA's, MTA's and MTU's that ignore and strip all X- 
headers from an email so it won't work (they for those alternative people 
there's always To: and CC:)

Looking back on that I think the dedicated LFS email header is the most 
elegant solution. Would anybody disagree and can that person a good reason 
not to invent the X-LFS-Mailinglist: header? If not I'll work on it tomorrow 
and see if Listar can be pursuaded to start sending the tag.

Gerard Beekmans

-*- If Linux doesn't have the solution, you have the wrong problem -*-

Unsubscribe: send email to lfs-discuss-request at
and put unsubscribe in the subject header of the message

More information about the lfs-dev mailing list