Courier IMAP, nnimap and large UIDs

Courier IMAP, nnimap and large UIDs

[Simon Josefsson]

I was browsing the Courier IMAP source to see if there is a easy
modification to it, so we don't have to fix nnimap :-) but I was
somewhat surprised.  As I read imapscanclient.c:do_imapscan_maildir2()
Courier allocate UIDs starting at 1 and increases this by one for new
mails.  Maybe this has changed in recent versions?

Anyone with a Courier IMAP server that feel like debugging this to see
what is really happening?  Especially a sample cur/courierimapuiddb
would be interesting to see.  Mail me, I guess it's not terribly
relevant on this mailing list.

Re: Courier IMAP, nnimap and large UIDs

[Steve Harris]

Simon Josefsson <simon@josefsson.org> writes:


[...]

> Courier allocate UIDs starting at 1 and increases this by one for new
> mails.  Maybe this has changed in recent versions?

My ISP is currently switching over to Courier, which only understands
maildir - hence my somewhat urgent tone lately on this issue. One of
the support guys at the ISP sent some test messages to the staged
server and showed me the message IDs, which carried the typical
time.pid.host stamp. I didn't get a chance to connect nnimap to it
yet, though, so I can't see what the IMAP server will send. The ISP
pointed out that since qmail is still doing the delivery, the message
IDs won't change just because Courier exposes the mailbox to IMAP. I'm
still confused about whether Courier could still present a different
UID to nnimap.

> Anyone with a Courier IMAP server that feel like debugging this to see
> what is really happening?  Especially a sample cur/courierimapuiddb
> would be interesting to see.  Mail me, I guess it's not terribly
> relevant on this mailing list.

Details may not be critical, but progress reports and ideas are
definitely relevant!

-- 
Steven E. Harris
Primus Knowledge Solutions, Inc.
http://www.primus.com

Re: Courier IMAP, nnimap and large UIDs

[Simon Josefsson]

Steve Harris <sharris@primus.com> writes:

> I'm still confused about whether Courier could still present a
> different UID to nnimap.

It seem to start at 1 and assigns contigious article numbers to
articles, so you should be fine.

> Details may not be critical, but progress reports and ideas are
> definitely relevant!

Someone on the nnimap list acknowledged that Courier work fine, so I
guess this is settled.  Sorry for spreading my confusion.

Re: Courier IMAP, nnimap and large UIDs

[Kai Großjohann]

On 19 Jul 2000, Steve Harris wrote:

> I'm still confused about whether Courier could still present a
> different UID to nnimap.

Note that UID != message id.  There is a Message-ID header which is a
property of an incoming message.  The IMAP server assigns a UID to
each incoming message using some method, but most probably it does not
take the Message-ID into account.  Note that two IMAP servers which
store the same message will have the the same Message-ID but will
probably assign different UIDs.

What's a Message-ID useful for, then?  Well, the IMAP server could
store a list of Message-IDs recently seen, and when a message arrives
twice, this can be detected.

kai
-- 
I like BOTH kinds of music.

Re: Courier IMAP, nnimap and large UIDs

[Steve Harris]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Note that UID != message id.  There is a Message-ID header which is a
> property of an incoming message.  The IMAP server assigns a UID to
> each incoming message using some method, but most probably it does not
> take the Message-ID into account.

[...]

Ah, but Kai, qmail's IMAP server does just that! The UIDs were the
"time" portion of maildir's "time.pid.host" naming scheme. I sure hope
Courier doesn't do the same.

Since I've obviously been confused by this Message ID/UID dichotomy in
the past, I can't give much more detail than to say that nnimap tells
Gnus that there's a HUGE number of articles - and the number usually
correlates _very closely_ with the time-stamp difference between the
first and last message in the folder.

-- 
Steven E. Harris
Primus Knowledge Solutions, Inc.
http://www.primus.com

Re: Courier IMAP, nnimap and large UIDs

[Kai Großjohann]

On 19 Jul 2000, Steve Harris wrote:

> Ah, but Kai, qmail's IMAP server does just that! The UIDs were the
> "time" portion of maildir's "time.pid.host" naming scheme. I sure
> hope Courier doesn't do the same.

Err.  So, what does it do with incoming Message-IDs?  This message
should have a header similar to:

    Message-ID: <xxxxxxxx.fsf@lucy.cs.uni-dortmund.de>

where I'm not sure about the xxxxxxxxx part.  Are you saying that the
qmail IMAP server rewrites the Message-ID headers of incoming messages?

kai
-- 
I like BOTH kinds of music.

Re: Courier IMAP, nnimap and large UIDs

[Steve Harris]

Kai.Grossjohann@CS.Uni-Dortmund.DE (Kai Großjohann) writes:

> Err.  So, what does it do with incoming Message-IDs?  This message
> should have a header similar to:
> 
>     Message-ID: <xxxxxxxx.fsf@lucy.cs.uni-dortmund.de>
> 
> where I'm not sure about the xxxxxxxxx part.  Are you saying that the
> qmail IMAP server rewrites the Message-ID headers of incoming messages?

No. Sorry, I think I mixed terminology again. The Message ID is as you
expect it - written by your server. Rather, I meant to say that the
*file name* given to the message in the maildir folder has the
"time.pid.host" format, and qmail is taking the first part of that
file name and using it as the UID. Does that make more sense?

-- 
Steven E. Harris
Primus Knowledge Solutions, Inc.
http://www.primus.com

Re: Courier IMAP, nnimap and large UIDs

[Kai Großjohann]

On 19 Jul 2000, Steve Harris wrote:

> No. Sorry, I think I mixed terminology again. The Message ID is as
> you expect it - written by your server. Rather, I meant to say that
> the *file name* given to the message in the maildir folder has the
> "time.pid.host" format, and qmail is taking the first part of that
> file name and using it as the UID. Does that make more sense?

Right.  So: the Message-IDs don't change when changing from qmail to
Courier, but that's not relevant.  The UIDs could change.

It would be really nifty if Gnus could cope with large article
numbers, or used a data type other than plain integer for the article
numbers. 

kai
-- 
I like BOTH kinds of music.