[Dovecot] v2.0.alpha1 released

[Ed W]

Timo Sirainen wrote:
> On Wed, 2009-10-14 at 00:14 +0100, Ed W wrote:
>   
>>> next_still_here_sending_timestamp = imap_idle_notify_interval -
>>>   (time(NULL) + crc32(username)) % imap_idle_notify_interval;
>>>
>>> The username CRC32 is there to avoid network/load spikes when all the 
>>> processes try to send the "Still here" at the same time.
>>>       
>> Just to kick this around a bit - I guess it's possible for one username 
>> to be logged in on three different computers (eg I have several laptops 
>> with identical config and sometimes several of them are on at once).  On 
>> the other hand my original idea was to compromise on "hashing" by IP 
>> address, this is obviously wrong in the sense that frequently multiple 
>> users are behind large NAT ranges, especially if they are on some sort 
>> of WAN connection
>>     
>
> And it's especially bad if Dovecot is run behind proxy and doesn't know
> anyone's IP address.
>   

I think under the most useful scenario of 3G/wifi networks, it's 
practically a given that there is a NAT involved...


>> However, I guess for maximum polish it would be optimal to hash based on 
>> both username and ip address?  This would appear to be useful in your 
>> algorithm above anyway though?
>>     
>
> I'm just wondering if some mobile networks can give you different IPs
> for different connections, like when you open first connection in area X
> and then move around to area Y and open another connection it gives you
> a new IP, but still keeps the old connections working? In that situation
> adding IP to the hash wouldn't be a good idea.
>   

I'm currently having problems with my vpn when using a UK "Three" SIM.  
I haven't fully investigated, but I *think* it's because the IP changes 
regularly even while the connection is up and in progress?  I think this 
setup is rare, but exists (on some broadband connections also 
apparently?).  I actually think that in this situation all the tcp 
connections *should* die...?

One of the problems I have been having is that with Thunderbird, 
assuming the IP *is* changing (not tested), it seems like my end of the 
link is continuing as though the connection is alive and the far end is 
obviously treating me as a new connection and the end result is a bunch 
of errors "server is not an IMAP4 server".

So my (unfounded) guess is that if the IP changes on you quietly, then 
actually the TCP connection will eventually fall apart and this is not a 
problem worth tracking on the dovecot side?


I think the main cases to optimise for are a) mobile users behind a NAT, 
b) users possibly leaving one desktop machine on broadband, but checking 
the same account via a mobile device (same login). I think this coverst 
the 90% situation?

Ed W