[PATCH] Next attempt to get guessing of From addresses correct in replies

[Dirk Hohndel]

On Wed, 14 Apr 2010 10:21:42 -0700, Carl Worth <cworth at cworth.org> wrote:
> On Fri, 09 Apr 2010 15:53:04 -0700, Dirk Hohndel <hohndel at infradead.org> wrote:
> > + * WARNING - if the caller is asking for a header that could occur
> > + * multiple times than they MUST first call this function with a 
> > + * a value of NULL for header_desired to ensure that all of the
> > + * headers are parsed and concatenated before a match is returned
> ...
> > +	} else {
> > +	    /* not sure this makes sense for all headers that can occur
> > +	     * multiple times, but for now just concatenate headers
> > +	     */
> > +	    newhdr = strlen(decoded_value);
> > +	    hdrsofar = strlen(header_sofar);
> 
> I'm a little nervous about this semantic change.

So am I - but I haven't found a message where this would have bitten me.
 
> For example, I know that my mail collection contains at least some
> messages with multiple Message-ID headers, (I'm not sure that's legal,
> but they are there).

No, that is absolutely NOT RFC compliant. Wonder what creates those
messages...

> I found those when doing detailed comparisons of
> the database created by sup with that created by very early versions of
> what became the indexing code for notmuch. [Sup prefers the
> last-encountered Message-Id in the file, while Notmuch prefers the
> first.]

Actually, prior to another fix that I sent (and that you already
applied), notmuch would use the first if you came across this header for
the first time when searching for it (but since you'd search for
Message-Id fairly early on, that's likely what happened). But if your
header was remembered "en-passant" while searching for a different
header later in the file, notmuch would actually remember the last.

But again, I fixed that before making the change to concatenate
duplicates instead.
 
> So I'm concerned about the change above introducing subtle problems that
> might be hard to notice.

Yes, absolutely - a concatenated Message-Id would SUCK.
 
> How about an argument that asks explicitly for concatenated header
> values, (and this could just trigger a rescan of the headers and ignore
> the hash). I think that will be fine for your use case where you're just
> opening this message file to get this one concatenated header out,
> right?

That would work just fine. And avoid the potential unintended side
effects. 

I'm about to head for the airport - do you want to make that
modification yourself or should I do it tonight?

/D

-- 
Dirk Hohndel
Intel Open Source Technology Center