Re: header_get_value() and imap daemon bug

[Sam Roberts]

Aside: si tu pense je n'ecrie pas correct "bonsoir", tu dois voir
mon autre email en francais. Si ma enseigneur d'francais les voie,
elle elle vas tue...

I'm learning a whole language, slowly, one broken phrase at a time. Ruby is
easier. I take consolation in that even if I'm not always comprehensible,
I'm probably often funny.

[clipped: description of how header_get_value() returns a concatenation
of the values of all the matching header fields.]
> > Possible fixes:
> > 
> > 1 - return the first field
> > 
> >   If you want fields like Received: you will be using
> >   header_get_field_value() looking at each one.
> > 
> > 2 - add an index to header_get_value()
> >   
> >   so you ask for the 1st "received" field, or the 2nd, etc.
> > 
> >   this would have the nice side effect of allowing the replacement of
> >   header_get_value() and header_get_field_value() with a single function:
> > 
> >   header_get_value(header_t,
> >       const char *name, size_t index,
> >       char *value, size_t insz, size_t* outsz)
> > 
> >   a name of 0 could mean "any name", identical to the current
> >   header_get_field_value().
> > 
> > ===
> > 
> > I want to do 1 now, and 2 when I have the time (there are other things
> > to fix first).
> > 
> > Before I commit it, is imap, or something, relying on this odd
> > concatenation side-effect?

Quoteing address@hidden, on Sun, May 05, 2002 at 10:45:56PM -0400:
> The only way to answer this question, is to contact an IMAP server on
> port 149(?) and issue a FETCH of some specific headers.  You will find
> that it does return the duplications, IIRC.
> As usual in the RFC of IMAP there is no clear guidelines on this.
> And think most servers will do the prudent thing and return any duplication:
> To: fo\r\n
> To: bar\r\n
> xx FETCH OK.

Ah, OK, that makes complete sense! IMAP is giving you all the complete
headers, so you can parse them all, and find each value. That's fine.

It looks like our IMAP is just using the header_get_value() function, since
it gives:

3 fetch 3 (body.peek[header.fields(received)])
* 3 FETCH (BODY[HEADER.FIELDS ("RECEIVED")] {1340}
received: from ns.ca.certicom.com ([66.48.18.197])
        by pop.uniserve.com with esmtp (Exim 3.16 #2)
        id 16fM6p-0006wa-00
        for address@hidden; Mon, 25 Feb 2002 06:28:07 -0800
 from smtpmail.certicom.com (domino2.certicom.com [10.0.1.25])
        by ns.ca.certicom.com (Postfix) with SMTP id E5D501857
        for <address@hidden>; Mon, 25 Feb 2002 09:27:03 -0500 (EST)
...

But it looks like its got the output format wrong, here's Cyrus:

3 fetch 3 (body.peek[header.fields (received)])
* 3 FETCH (BODY[HEADER.FIELDS (received)] {657}
Received: from ns.ca.certicom.com ([66.48.18.197])
        by pop.uniserve.com with esmtp (Exim 3.16 #2)
        id 1701IH-000OKj-00
        for address@hidden; Tue, 23 Apr 2002 07:29:21 -0700
Received: from smtpmail.certicom.com (domino2.certicom.com [10.0.1.25])
        by ns.ca.certicom.com (Postfix) with SMTP id 810FE1804
        for <address@hidden>; Tue, 23 Apr 2002 10:24:57 -0400 (EDT)
...

Which is what you describe.

So this is a bug in mailutils, and I can do (1) since it won't affect
the IMAP daemon once the bug is fixed, and won't make it worse until
it is fixed. (2) would make it easier to write the correct IMAP code.

> But in any case, I agree we got it wrong, and the real solution is (2)
> and (1) is just a particular case with index = 0;
> 
> If you find time to do (2) virtual beer on me, unless you drive through 
> Ottawa 8-).
> 
> Later, I'm off working on my IDE.

Enjoy!

Salut,
Sam

-- 
Sam Roberts <address@hidden> (Vivez sans temps mort!)