Subject: [Imap-uw] Question regarding behavior of imapd

From: Terry Figel <[email-masked]>
Date: Thu, 22 Dec 2005 15:44:56 -0800

Hi-
I've witnessed the following from various clients:
The client has imap set to check their email every 15 minutes (or whatever),
the server has recieved new mail, but the client does not get any 
notification of this
Sometimes restarting the client fixes it.
othertimes you need to kill the imapd process on the server.

Is this a known problem?  ( I was familiar and living with it for years, but
someone suggested mailing this list)

In the current solaris 9 environment, the mail spool and home 
directories are local.
I've seen 100's of these stale processes, typically to home DSL or cable 
boxes.
Is there a reason imapd does not die, on a non-graceful disconnect?

-Terry Figel

_______________________________________________
Imap-uw mailing list
[email-masked]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw

---

From: Mark Crispin <[email-masked]>
Date: Thu, 22 Dec 2005 16:05:37 -0800

> othertimes you need to kill the imapd process on the server.

I suspect that this is a client issue, not a server issue.

There is no such thing as "setting IMAP to check every 15 minutes". 
Presumably, what is happening is that the client is set to issue an IMAP 
command, even if it's just a no-op, at least every 15 minutes in order to 
cycle the protocol and cause new mail notification.

If the client uses the IDLE extension (e.g., Outlook and Outlook Express), 
make sure that you have the most recent release of UW imapd (imap-2004g), 
due to the following issues:

There is an issue caused by client use of NAT which will cause the NAT 
mapping to expire if the session is idle for more than a couple of 
minutes.

To avoid this, recent versions of UW imapd send an announcement while in 
IDLE mode, even if there is no new mail to announce.

There is another issue related to IDLE; Outlook Express does not terminate 
IDLE mode at 29 minutes, even though the specification (which Microsoft 
helped write!) requires that it do so.  The result is that the server 
autologouts at 30 minutes.  The client sees this, but doesn't make that 
fact clear to the user (it's a tiny little icon), and then the user 
complains that they aren't getting told about new mail any more.

This issue is also resolved by recent versions of UW imapd, which fake a 
"new" message near the end of the permitted IDLE period.  Outlook Express 
wakes up to get the new message, UW imapd immediately says that the 
fake "new message" was "expunged", so OE puts the session back in IDLE 
mode with a fresh 30 minute autologout timeout.

> In the current solaris 9 environment, the mail spool and home directories 
> are local.

I can't tell you much about how Solaris behaves.  imapd certainly tries to 
commit suicide after 30 minutes of inactivity.  I suspect that those stale 
processes are in the process of committing suicide, but the announcement 
of that fact is blocked in TCP output wait.  The question is why TCP never 
times out that output.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
_______________________________________________
Imap-uw mailing list
[email-masked]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw

---

From: "Clive McDowell" <[email-masked]>
Date: Wed, 4 Jan 2006 09:46:19 -0000

Folks,

it has been decreed that we have to switch our efficient, reliable unix based message store to an Exchange Server. Does anyone
have any information on how well the IMAP function of that software conforms to the protocol? I'm concerned that our significant
body of non-Outlook users may lose functionality.

Thanks,

 Clive McDowell

Information Services
The Queen's University of Belfast

---

From: Erik Kangas <[email-masked]>
Date: Wed, 11 Jan 2006 14:14:22 -0500

Hello,

This is a pretty simple question.  I am considering writing some software 
to cache imap message/header data.  In thinking about this, I have been 
going through the Perl Mail::Cclient docs for ways I can determine easily 
if there are changes: new messages, deleted messages, messages with changed 
flags.  I am using mbx formatted folders.

New messages: compare current vs saved "uidnext" can be examined to see if 
there have been new messages.

Deleted messages: I am not sure how to detect this short of getting a list 
of all uids and comparing with my local list and removing missing ones.

Messages with changed flags: I am not sure how to do this without fetching 
the flags for all messages and updating my local cache.

Are there better ways of doing these things with imap/cclient -- the 
overall goal is to ease the server workload as much as possible through 
caching.  If we have to re-scan headers every time, then caching locally is 
not much better than just grabbing the headers directly each time.

Any suggestions are appreciated.

Best,

-Erik Kangas
LuxSci.com

---

From: "Tomas Pospisek's Mailing Lists" <[email-masked]>
Date: Wed, 11 Jan 2006 21:20:13 +0100 (CET)

On Wed, 11 Jan 2006, Erik Kangas wrote:

> This is a pretty simple question.  I am considering writing some software to 
> cache imap message/header data.  In thinking about this, I have been going 
> through the Perl Mail::Cclient docs for ways I can determine easily if there 
> are changes: new messages, deleted messages, messages with changed flags.  I 
> am using mbx formatted folders.
>
> Deleted messages: I am not sure how to detect this short of getting a list of 
> all uids and comparing with my local list and removing missing ones.
>
> Are there better ways of doing these things with imap/cclient -- the overall 
> goal is to ease the server workload as much as possible through caching.  If 
> we have to re-scan headers every time, then caching locally is not much 
> better than just grabbing the headers directly each time.
>

Have a look at mailsync.sf.net
*t

--
-----------------------------------------------------------
   Tomas Pospisek
   http://sourcepole.com -  Linux & Open Source Solutions
-----------------------------------------------------------
_______________________________________________
Imap-uw mailing list
[email-masked]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw

---

From: Mark Crispin <[email-masked]>
Date: Wed, 11 Jan 2006 13:40:37 -0800

> there have been new messages.

Also check uidvalidity to make sure that it has not changed.  If it has 
changed, discard your cache.

> all uids and comparing with my local list and removing missing ones.

The fact that UIDs are strictly ascending (unlike POP where UIDs are 
random) and the provision of consecutive sequence numbers creates some 
interesting mathematical relationships that can ease the burden.  Often 
you can avoid having to reload the entire UID map by observing that there 
are no missing UIDs within a particular range.

Hence my oft-repeated statement that a good IMAP client uses *both* UIDs 
and sequence numbers.

> the flags for all messages and updating my local cache.

Yes, but only when first synchronizing the cache.  Once you have done so, 
you don't need to do so again in the session since the server is required 
to announce flag changes.

> better than just grabbing the headers directly each time.

I don't know much about the Perl module that calls c-client, and your 
question is a bit vague for me to answer specifically.  You are best off 
looking at existing successful programs that call c-client (e.g., Pine) 
and see how they work, and then ask questions once on specific points.

-- Mark --