IMAP Problems

IMAP Problems

[Niranjan Rao]

Hello,

gnus-version Gnus v5.9.0
emacs-version 21.2.1 on Windows 2K Server

I tried connecting to MS Exchange IMAP server using
following settings

(gnus-select-method (quote (nnimap "AAMAIN"
(nnimap-authenticator login) (nnimap-stream ssl)
(nnimap-server-port 143) (nnimap-list-pattern ("INBOX")))))

and

(gnus-secondary-select-methods (quote ((nnimap "AAMAIN"
(nnimap-authenticator anonymous) (nnimap-stream SSL)
(nnimap-list-pattern ("Inbox"))))))

through customization. The buffers for logging are also
activated using 
(setq imap-log "*imap-log*")
(setq imap-debug "*imap-debug*")
(setq nnimap-debug "*nnimap-debug*")

The log seems to show that gnus is able to connect to the
server though I never saw *imap-log* buffer being
created. As suggested in some of the articles I searched
through google, I tried imap-open function as follows

(imap-open "AAMAIN")
it returns 
" *imap* AAMAIN:0"

My problem is after showing the message of executing openssl
program gnus/emacs just hangs. It of course comes out after
hitting Ctrl-G. I have verified server name and port number
as Outlook express is able to connect to the imap server
using the same port and log on using secure password
authentication checked.

Am I doing something wrong ? I'll be glad to
post contents from any debug buffers if some one wants to
examine it.

-- Niranjan

------------------------------------------------------------
If you're in a vehicle going the speed of light, what happens
when you turn on the headlights?
------------------------------------------------------------

Re: IMAP Problems

[Paul Jarc]

Niranjan Rao <niranjan@adviceamerica.com> wrote:
> (gnus-select-method (quote (nnimap "AAMAIN"
> (nnimap-authenticator login) (nnimap-stream ssl)
> (nnimap-server-port 143) (nnimap-list-pattern ("INBOX")))))
>
> and
>
> (gnus-secondary-select-methods (quote ((nnimap "AAMAIN"
> (nnimap-authenticator anonymous) (nnimap-stream SSL)
> (nnimap-list-pattern ("Inbox"))))))

Are you using both of these settings together?  They should not both
be called "AAMAIN".  You can use the nnimap-address server parameter
to make both of them connect to the same machine, but the select
methods should not both have the same name.


paul

Re: IMAP Problems

[Simon Josefsson]

On 10 Apr 2002, Niranjan Rao wrote:

> Hello,
> 
> gnus-version Gnus v5.9.0
> emacs-version 21.2.1 on Windows 2K Server
> 
> I tried connecting to MS Exchange IMAP server using
> following settings
> 
> (gnus-select-method (quote (nnimap "AAMAIN"
> (nnimap-authenticator login) (nnimap-stream ssl)
> (nnimap-server-port 143) (nnimap-list-pattern ("INBOX")))))
> 
> and
> 
> (gnus-secondary-select-methods (quote ((nnimap "AAMAIN"
> (nnimap-authenticator anonymous) (nnimap-stream SSL)
                                                  ^^^
It should be ssl.

> (nnimap-list-pattern ("Inbox"))))))
> 
> through customization. The buffers for logging are also
> activated using 
> (setq imap-log "*imap-log*")
> (setq imap-debug "*imap-debug*")
> (setq nnimap-debug "*nnimap-debug*")
> 
> The log seems to show that gnus is able to connect to the
> server though I never saw *imap-log* buffer being
> created.

It will be generated when there is any data to log.

> As suggested in some of the articles I searched
> through google, I tried imap-open function as follows
> 
> (imap-open "AAMAIN")
> it returns 
> " *imap* AAMAIN:0"
> 
> My problem is after showing the message of executing openssl
> program gnus/emacs just hangs. It of course comes out after
> hitting Ctrl-G. I have verified server name and port number
> as Outlook express is able to connect to the imap server
> using the same port and log on using secure password
> authentication checked.

The problem might be related to CRLF confusion in imap.el / Windows /
OpenSSL.  Can you try frobbing `imap-client-eol' and (maybe more 
importantly) `imap-server-eol'?  Try experimenting with \r\n and \n 
values.  You'd might want to edebug imap-ssl-open and look in the  
*nnimap* server buffer for what kind of eol character is returned.

You could try frobbing `imap-process-connection-type' as well.

Re: IMAP problems

[Frank Schmitt]

Simon Josefsson <jas@extundo.com> writes:

> Frank Schmitt <usereplyto@Frank-Schmitt.net> writes:
>
>> I just tried this. starttls exits quietly after the ". capability".
>
> Oh, too bad I didn't wage any money on the bet, then. :-)
[...]
> Or, you could remove the 'starttls' binary.

I was to lazy to investigate this any further and switched over to
openssl instead which works nicely now. (OK, I had the problem that
saying g in group buffer didn't find new mails which i solved by
convincing the administrator of the IMAP server that 
Copyright 1998-2003 Double Precision, Inc.
looks much better than
Copyright 1998-2001 Double Precision, Inc.

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

Re: IMAP problems

[Simon Josefsson]

Frank Schmitt <usereplyto@Frank-Schmitt.net> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> Nothing after this?  No response to the LOGIN command?  The IMAP trace
>> looked fine until then.  Perhaps your 'startls' binary is broken?
>> Type 'starttls mail1.kens.com 143' and type '. starttls' into it, do
>> 'kill -ALRM <pidofstarttls>' and then type '. capability' followed by
>> 'login myusername yourpassword'.  You should be logged in then.
>
> I just tried this. starttls exits quietly after the ". capability".

Oh, too bad I didn't wage any money on the bet, then. :-)

Gnus should ideally notice that the process died, and imap.el do
contain such logic, but I think you ran into a Emacs bug too.  If you
can find out why `process-status' inside `imap-starttls-open' return
'run even though the process has died, and report that to the Emacs
for Windows people, and they fix it, Gnus will happily continue the
login procedure using the normal network connection.

Or, you could remove the 'starttls' binary.

Re: IMAP problems

[Simon Josefsson]

Frank Schmitt <usereplyto@Frank-Schmitt.net> writes:

> Simon Josefsson <jas@extundo.com> writes:
>
>> ...
>>> 2 CAPABILITY
>>>
>>> 3 LOGIN "myusername" ""
>>
>> Nothing after this?  No response to the LOGIN command?  The IMAP trace
>> looked fine until then.  Perhaps your 'startls' binary is broken?
>> Type 'starttls mail1.kens.com 143' and type '. starttls' into it, do
>> 'kill -ALRM <pidofstarttls>' and then type '. capability' followed by
>> 'login myusername yourpassword'.  You should be logged in then.
>>
>>> | 2 <- imap-opened: (run)
>>
>> Looks fine too, the only reason I can find is that 'starttls' somehow
>> dies after a while.
>
> I think, I found where the problem is: I'm working under MS Windows,
> using a starttls compiled by me under the cygwin environment. Could it
> be possible that there are CRLF vs. CR problems? I've got this idea
> because the IMAP-LOG buffer has extra linefeeds in it (every line looks
> like this:
> foo bar foo bar^M
> schlurps murks^M
> )

The imap-log should look like that.  And since you got passed the
first CAPABILITY exchange, I doubt this is the problem, but it is
possible.  OTOH, I have never heard of anyone successfully using
starttls under cygwin, so I'm betting on a b0rken starttls binary.
Does it work if you use it manually if you follow the instructions
above?

Re: IMAP problems

[Frank Schmitt]

Simon Josefsson <jas@extundo.com> writes:

> Nothing after this?  No response to the LOGIN command?  The IMAP trace
> looked fine until then.  Perhaps your 'startls' binary is broken?
> Type 'starttls mail1.kens.com 143' and type '. starttls' into it, do
> 'kill -ALRM <pidofstarttls>' and then type '. capability' followed by
> 'login myusername yourpassword'.  You should be logged in then.

I just tried this. starttls exits quietly after the ". capability".

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

Re: IMAP problems

[Frank Schmitt]

Simon Josefsson <jas@extundo.com> writes:

> ...
>> 2 CAPABILITY
>>
>> 3 LOGIN "myusername" ""
>
> Nothing after this?  No response to the LOGIN command?  The IMAP trace
> looked fine until then.  Perhaps your 'startls' binary is broken?
> Type 'starttls mail1.kens.com 143' and type '. starttls' into it, do
> 'kill -ALRM <pidofstarttls>' and then type '. capability' followed by
> 'login myusername yourpassword'.  You should be logged in then.
>
>> | 2 <- imap-opened: (run)
>
> Looks fine too, the only reason I can find is that 'starttls' somehow
> dies after a while.

I think, I found where the problem is: I'm working under MS Windows,
using a starttls compiled by me under the cygwin environment. Could it
be possible that there are CRLF vs. CR problems? I've got this idea
because the IMAP-LOG buffer has extra linefeeds in it (every line looks
like this:
foo bar foo bar^M
schlurps murks^M
)

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

Re: IMAP problems

[Simon Josefsson]

Frank Schmitt <usereplyto@Frank-Schmitt.net> writes:

> Hello
>
> I've problems connecting to an IMAP server with Gnus. It seems
> something goes wrong when authenticating with the server, but what?
>
> Here's what I have in my .gnus:
>
> (add-to-list 'gnus-secondary-select-methods 
>                          '(nnimap "mail1"
>                                   (nnimap-address "mail1.kens.com")))
>
> When Gnus starts, the connection to the server isn't established, if I
> go to server buffer status is set to "denied".
>
> Here's what *imap-log* says
>  
...
> 2 CAPABILITY
>
> 3 LOGIN "myusername" ""

Nothing after this?  No response to the LOGIN command?  The IMAP trace
looked fine until then.  Perhaps your 'startls' binary is broken?
Type 'starttls mail1.kens.com 143' and type '. starttls' into it, do
'kill -ALRM <pidofstarttls>' and then type '. capability' followed by
'login myusername yourpassword'.  You should be logged in then.

> | 2 <- imap-opened: (run)

Looks fine too, the only reason I can find is that 'starttls' somehow
dies after a while.

IMAP problems

[Frank Schmitt]

Hello

I've problems connecting to an IMAP server with Gnus. It seems
something goes wrong when authenticating with the server, but what?

Here's what I have in my .gnus:

(add-to-list 'gnus-secondary-select-methods 
                         '(nnimap "mail1"
                                  (nnimap-address "mail1.kens.com")))

When Gnus starts, the connection to the server isn't established, if I
go to server buffer status is set to "denied".

Here's what *imap-log* says
 
* OK Courier-IMAP ready. Copyright 1998-2001 Double Precision, Inc.  See COPYING for distribution information.

1 CAPABILITY

* CAPABILITY IMAP4rev1 CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT STARTTLS

1 OK CAPABILITY completed

* OK Courier-IMAP ready. Copyright 1998-2001 Double Precision, Inc.  See COPYING for distribution information.

1 STARTTLS

1 OK Begin SSL/TLS negotation now.

2 LOGOUT

* BYE Courier-IMAP server shutting down

2 OK LOGOUT completed

2 CAPABILITY

3 LOGIN "myusername" ""


and here the contents of *imap-debug*:

======================================================================
1 -> imap-opened: buffer=" *nnimap* mail1"
1 <- imap-opened: nil
======================================================================
1 -> imap-open: server="mail1.kens.com" port=nil stream=nil auth=nil buffer=" *nnimap* mail1"
| 2 -> imap-opened: buffer=" *nnimap* mail1"
| 2 <- imap-opened: nil
| 2 -> imap-open-1: buffer=" *nnimap* mail1"
| | 3 -> imap-network-open: name="imap" buffer=" *nnimap* mail1" server="mail1.kens.com" port=nil
| | | 4 -> imap-parse-greeting: 
| | | 4 <- imap-parse-greeting: nil
| | | 4 -> imap-parse-greeting: 
| | | 4 <- imap-parse-greeting: nonauth
| | 3 <- imap-network-open: #<process imap>
| 2 <- imap-open-1: #<process imap>
| 2 -> imap-capability: identifier=AUTH=GSSAPI buffer=" *nnimap* mail1"
| | 3 -> imap-send-command-wait: command="CAPABILITY" buffer=nil
| | | 4 -> imap-send-command: command="CAPABILITY" buffer=nil
| | | | 5 -> imap-send-command-1: cmdstr="1 CAPABILITY"
| | | | 5 <- imap-send-command-1: nil
| | | 4 <- imap-send-command: 1
| | | 4 -> imap-wait-for-tag: tag=1 buffer=nil
| | | | 5 -> imap-arrival-filter: proc=#<process imap> string="* CAPABILITY IMAP4rev1 CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT STARTTLS

1 OK CAPABILITY completed

"
| | | | | 6 -> imap-find-next-line: 
| | | | | 6 <- imap-find-next-line: 113
| | | | | 6 -> imap-parse-response: 
| | | | | | 7 -> imap-parse-resp-text: 
| | | | | | | 8 -> imap-parse-resp-text-code: 
| | | | | | | 8 <- imap-parse-resp-text-code: nil
| | | | | | 7 <- imap-parse-resp-text: nil
| | | | | 6 <- imap-parse-response: nil
| | | | | 6 -> imap-find-next-line: 
| | | | | 6 <- imap-find-next-line: 98
| | | | | 6 -> imap-parse-response: 
| | | | | 6 <- imap-parse-response: (IMAP4REV1 CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT STARTTLS)
| | | | | 6 -> imap-find-next-line: 
| | | | | 6 <- imap-find-next-line: 28
| | | | | 6 -> imap-parse-response: 
| | | | | | 7 -> imap-parse-resp-text: 
| | | | | | | 8 -> imap-parse-resp-text-code: 
| | | | | | | 8 <- imap-parse-resp-text-code: nil
| | | | | | 7 <- imap-parse-resp-text: nil
| | | | | 6 <- imap-parse-response: nil
| | | | | 6 -> imap-find-next-line: 
| | | | | 6 <- imap-find-next-line: nil
| | | | 5 <- imap-arrival-filter: nil
| | | 4 <- imap-wait-for-tag: OK
| | 3 <- imap-send-command-wait: OK
| 2 <- imap-capability: nil
| 2 -> imap-capability: identifier=AUTH=KERBEROS_V4 buffer=" *nnimap* mail1"
| 2 <- imap-capability: nil
| 2 -> imap-capability: identifier=STARTTLS buffer=" *nnimap* mail1"
| 2 <- imap-capability: (STARTTLS)
| 2 -> imap-open-1: buffer=#<buffer  *temp*>
| | 3 -> imap-parse-greeting: 
| | 3 <- imap-parse-greeting: nil
| | 3 -> imap-parse-greeting: 
| | 3 <- imap-parse-greeting: nonauth
| | 3 -> imap-send-command-wait: command="STARTTLS" buffer=nil
| | | 4 -> imap-send-command: command="STARTTLS" buffer=nil
| | | | 5 -> imap-send-command-1: cmdstr="1 STARTTLS"
| | | | 5 <- imap-send-command-1: nil
| | | 4 <- imap-send-command: 1
| | | 4 -> imap-wait-for-tag: tag=1 buffer=nil
| | | | 5 -> imap-arrival-filter: proc=#<process imap<1>> string="1 OK Begin SSL/TLS negotation now.

"
| | | | | 6 -> imap-find-next-line: 
| | | | | 6 <- imap-find-next-line: 113
| | | | | 6 -> imap-parse-response: 
| | | | | | 7 -> imap-parse-resp-text: 
| | | | | | | 8 -> imap-parse-resp-text-code: 
| | | | | | | 8 <- imap-parse-resp-text-code: nil
| | | | | | 7 <- imap-parse-resp-text: nil
| | | | | 6 <- imap-parse-response: nil
| | | | | 6 -> imap-find-next-line: 
| | | | | 6 <- imap-find-next-line: 37
| | | | | 6 -> imap-parse-response: 
| | | | | | 7 -> imap-parse-resp-text: 
| | | | | | | 8 -> imap-parse-resp-text-code: 
| | | | | | | 8 <- imap-parse-resp-text-code: nil
| | | | | | 7 <- imap-parse-resp-text: nil
| | | | | 6 <- imap-parse-response: nil
| | | | | 6 -> imap-find-next-line: 
| | | | | 6 <- imap-find-next-line: nil
| | | | 5 <- imap-arrival-filter: nil
| | | 4 <- imap-wait-for-tag: OK
| | 3 <- imap-send-command-wait: OK
| 2 <- imap-open-1: #<process imap<1>>
| 2 -> imap-close: buffer=" *nnimap* mail1"
| | 3 -> imap-opened: buffer=nil
| | 3 <- imap-opened: (open run)
| | 3 -> imap-send-command-wait: command="LOGOUT" buffer=nil
| | | 4 -> imap-send-command: command="LOGOUT" buffer=nil
| | | | 5 -> imap-send-command-1: cmdstr="2 LOGOUT"
| | | | 5 <- imap-send-command-1: nil
| | | 4 <- imap-send-command: 2
| | | 4 -> imap-wait-for-tag: tag=2 buffer=nil
| | | | 5 -> imap-arrival-filter: proc=#<process imap> string="* BYE Courier-IMAP server shutting down

2 OK LOGOUT completed

"
| | | | | 6 -> imap-find-next-line: 
| | | | | 6 <- imap-find-next-line: 42
| | | | | 6 -> imap-parse-response: 
| | | | | | 7 -> imap-parse-resp-text: 
| | | | | | | 8 -> imap-parse-resp-text-code: 
| | | | | | | 8 <- imap-parse-resp-text-code: nil
| | | | | | 7 <- imap-parse-resp-text: nil
| | | | | 6 <- imap-parse-response: nil
| | | | | 6 -> imap-find-next-line: 
| | | | | 6 <- imap-find-next-line: 24
| | | | | 6 -> imap-parse-response: 
| | | | | | 7 -> imap-parse-resp-text: 
| | | | | | | 8 -> imap-parse-resp-text-code: 
| | | | | | | 8 <- imap-parse-resp-text-code: nil
| | | | | | 7 <- imap-parse-resp-text: nil
| | | | | 6 <- imap-parse-response: nil
| | | | | 6 -> imap-find-next-line: 
| | | | | 6 <- imap-find-next-line: nil
| | | | 5 <- imap-arrival-filter: nil
| | | 4 <- imap-wait-for-tag: OK
| | 3 <- imap-send-command-wait: OK
| 2 <- imap-close: t
| 2 -> imap-opened: buffer=" *nnimap* mail1"
| 2 <- imap-opened: (run)

-- 
Did you ever realize how much text fits in eighty columns? If you now consider
that a signature usually consists of up to four lines, this gives you enough
space to spread a tremendous amount of information with your messages. So seize
this opportunity and don't waste your signature with bullshit nobody will read.

Re: IMAP problems.

[visigoth]

David Moore <dmoore@UCSD.EDU> writes:

> 	As long as they are always increasing, logically things will
> work with subtracting an offset.  I also suspect that converting the
> UID's will not be too expensive, since you will probably have to do
> other cleanup on the incoming data anyways.

In fact, there's a pass over the input with a string-replace to quote
things properly, followed by a read to get it in--that's how I'm doing
things right now.  I suspect switching from (read) to reading strings
by hand would not speed this up much, but I haven't really checked
into it.

> 	When the message numbers come in, you could just stick a space
> character before the 5th digit from the right hand edge of the number,
> then use read to load both of these numbers (if there are less than 5
> digits, just do 1 read).  The first (left hand) number is always between
> 0-42949, and the second is always between 0-99999, which are both
> representable in emacs.  Subtract your initial number from these pair
> wise and multiple the first by 10000.  Then just stuff that value back
> into the buffer.
> 
> Initial number is 123432 -->  keep: (1 23431)  ;; make first message #1
> 
> When you get: 137563	-->  (1 37563) - (1 23432) = (0 14131)
> 			-->  new value: 14131

I already have some code which turns numbers into (a . b) pairs in the
input stream for reading--I can just adapt that.  (Should've thought
of that in the the first place--was thinking of either that or delta,
but the combo is good.)

> Of course, it might just be faster to stick a .0 on the end of the
> number, read it as a float, do a float subtraction and convert back to
> an integer.  The overhead of simple floating point operations isn't as
> large in emacs as in other languages, due to the large constant overhead
> of the interpreter.

> 	And I suspect that the cost of mangling won't be that noticable
> in current gnus, due to high costs elsewhere in NOV processing.

Well--I'll go with the pair of ints for now, just because it seems a
little cleaner.  We'll see what happens.  I've got a nice little imap
library now, for low-level stuff.  Now I should be able to write the
application layer callbacks for it (read nnimap.el), and we'll have
something that works in not too long.

My former approach was taking IMAP stream and converting it to NNTP
stream, so that Gnus was happy.  I think this approach will work
better.

Like I said, I'll be away for a week now--chances are, there'll be
something that works for IMAP4 (I might try to support older IMAPs
later, but I don't have anything that supports them, and I intend to
rely heavily on UIDs, so...) with a few weeks.

John.

Re: IMAP problems.

[David Moore]

> So--there are a couple of ways I can see of dealing with this.  One is
> to squirrel away the UID of the first message of a folder the first
> time you look at it--this number would be stored either as a string or
> as a float, since neither of these are limited to 32 bit integers.
> When a message is fetched or received from the server, the UID is read
> as a float or a string and then added/substracted from the "base" UID
> that was originally read (UIDs are guaranteed to grow over time.
> Usually grow by 1 per message in folder.) depending on whether it's
> going out or coming in.
> 
> This is kind of icky.  It means that we have to keep an extra number
> around for the group (not too hard), and that we need to mangle every
> message number as it goes from Emacs <-> IMAP.  If it's a string, we
> need to do our own math.  If it's a float, we need to do float math.
> 
> Any other ideas about how to deal with this?

	As long as they are always increasing, logically things will
work with subtracting an offset.  I also suspect that converting the
UID's will not be too expensive, since you will probably have to do
other cleanup on the incoming data anyways.

	When the message numbers come in, you could just stick a space
character before the 5th digit from the right hand edge of the number,
then use read to load both of these numbers (if there are less than 5
digits, just do 1 read).  The first (left hand) number is always between
0-42949, and the second is always between 0-99999, which are both
representable in emacs.  Subtract your initial number from these pair
wise and multiple the first by 10000.  Then just stuff that value back
into the buffer.


Initial number is 123432 -->  keep: (1 23431)  ;; make first message #1

When you get: 137563	-->  (1 37563) - (1 23432) = (0 14131)
			-->  new value: 14131


Of course, it might just be faster to stick a .0 on the end of the
number, read it as a float, do a float subtraction and convert back to
an integer.  The overhead of simple floating point operations isn't as
large in emacs as in other languages, due to the large constant overhead
of the interpreter.

	And I suspect that the cost of mangling won't be that noticable
in current gnus, due to high costs elsewhere in NOV processing.


-- 
David Moore <dmoore@ucsd.edu>       | Computer Systems Lab      __o
UCSD Dept. Computer Science - 0114  | Work: (619) 534-8604    _ \<,_
La Jolla, CA 92093-0114             | Fax:  (619) 534-1445   (_)/ (_)
<URL:http://oj.egbt.org/dmoore/>    | Solo Furnace Creek 508 -- 1996!

IMAP problems.

[visigoth]

Okay.  I just ran into the latest really major problem with Gnus doing
IMAP.  The most convenient thing for Gnus to use as the message number
for these messages is their UID--the problem is, UID (and UIDVALIDITY,
which is a number that's used to verify that the UIDs are the same as
the last time you looked, i.e. the group wasn't moved and then
recreated or something) are defined by the IMAP spec as 32bit
integers.  And, in fact, they -are- 32-bit integers.  And the UIDs
don't start at one, they start higher...  In fact, in my IMAP INBOX
right now, all the UIDs are outside the range of integers that Emacs
can manipulate.

This isn't good.

So--there are a couple of ways I can see of dealing with this.  One is
to squirrel away the UID of the first message of a folder the first
time you look at it--this number would be stored either as a string or
as a float, since neither of these are limited to 32 bit integers.
When a message is fetched or received from the server, the UID is read
as a float or a string and then added/substracted from the "base" UID
that was originally read (UIDs are guaranteed to grow over time.
Usually grow by 1 per message in folder.) depending on whether it's
going out or coming in.

This is kind of icky.  It means that we have to keep an extra number
around for the group (not too hard), and that we need to mangle every
message number as it goes from Emacs <-> IMAP.  If it's a string, we
need to do our own math.  If it's a float, we need to do float math.

Any other ideas about how to deal with this?

John.