Re: Porting digested new list archives to mail-archive

Jeff,

Thanks again--more things are clear now. But your response raises more 
questions in my mind as well. Please bear with me, we're almost there I 
think.

Keeping in mind that I am splitting Digests into individual messages, I 
have to fake whatever headers are not already there within the 
individual messages. In the case of my digests, the existing headers are 
only:

Date:
From:
Subject:

To this I add a ^From_ line just before the date line to make it an mbox 
format (this is taken from the Digest header and copied in front of each 
email in the digest, so it's identical for several emails.

An example of this ^From_ line is this:
	From - Mon Nov 28 11:00:05 2005

Now, with this background, here are my further questions:

1. I thought I would have to add a "To:" line to my "faked" headers, but 
you are saying that it is never used, is it OK if the To: line is 
completely absent?

> The only things indexed for search are: message-id,

2. Will it choke if there is no Message-ID? I know this is used in 
threading but in an earlier email you said that in the absence of 
Message-ID it would thread on Subject, but just want to make sure it 
won't reject the email without a Message-ID field.

> ... subject  ... sender name (extracted from From: header)

No issue on these.

> ... date (usually extracted from the Recieved: header)

3. Hmm, again, there is no Received header. Will it properly take the 
date from the Date: field in that case and not choke on the absence of 
any Received headers? The date field format (from an actual example) is:
	Date:    Mon, 28 Nov 2005 17:55:14 +1100

> ... posting address (for example, gossip-piJqB+B6DfPJghKJT/[email protected] ... Every message is
 > sorted and organized according to posting address ... but the To: header
 > is never indexed for search, never used during import, and there is no
 > benefit for you to adjust it.

4. This is where I'm most confused now. Where *is* the posting address 
extracted from if not from the To: header? Is it an internal field in 
your archive message database that is (a) predetermined manually in an 
import, (b) mapped to a fixed internally stored name for new incoming 
email (based on headers including To:) and nothing else? In your earlier 
response, where I had asked about the varying forms of To: addresses in 
my old archives that needed to be imported (e.g., [email protected], 
[email protected], [email protected]) in terms of confusing 
search (since I incorrectly imagined that the To: line would be looked 
for in the search), you had replied:

> Search will have no concept of alternative list names. There is no reasonable way to overcome this.

but now you say search never looks at the To: lines and they aren't used 
in imports either. So in light of your latest response I don't 
understand now why search would have an issue of "alternative list 
names"--they are alternative To: lines but the same list, and the 
variations exist only in archives--new email would have a consistent To: 
line reflecting the current posting address.

> A merged archive will have the same posting
> address for every message, with no memory about what life was like
> before the merge.

OK, this is consistent with the "To:" line never being used for search. 
So the "l=" parameter in the search would always have to be the new list 
name following a merge, correct? That shouldn't be an issue.

Shahrukh