improved popminpoll handling

[Phil Chambers]

On my old UW POP server I added a patch to limit the polling frequency.  Rather than 
just apply a fixed minimum time interval I made it give some flexibility.  The patch 
allows users to do a few checks in quick succession but would fail if the longer 
term rate was too high.  This is something which our POP users found to be a major 
improvement.

On moving to cyrus, the rigid limit has caused many complaints.

I have worked the same algorithm into cyrus's popminpoll handling.  However, since I 
have not had time to really get to grips with the cyrus code, I have had to limit 
the possible impact my code would have.  Perhaps someone with more knowledge of 
cyrus would like to improve matters for me.

The algorithm needs to store an integer value between connections.  Since the time 
of the last pop connection is stored in the inbox's cyrus.index file, that seemed 
the sensible place to store the new value.  However, I did not want to extend the 
size of the data stored and create unforseen problems!  My solution was to pack the 
new value in with "minor_version", using the top 16 of the 32 bits allocated in 
cyrus.index.

My patch involves making imap/mailbox.c pack and unpack the new variable with 
"minor_version" in mailbox_write_index_header() and mailbox_read_index_header().  
Also, to add a function which does the checking to imap/pop3d.c, which is called 
from openinbox() where openinbox() normally compares the elapsed time with 
pipminpoll.

If there is sufficient interest, perhaps the cyrus team might consider rolling it 
in.

My patch is currently to 2.1.13, but I am about to apply it to 2.1.15 too. I will be 
happy to to pass the patch to anyone who is interested (particularly anyone who can 
do a proper job of storing an extra integer in cyrus.index).

Phil.
---------------------------------------
Phil Chambers (postmaster at exeter.ac.uk)
University of Exeter