mailing list archives

I have been seeing a problem with mozilla Thunderbird client when using 
the charter.net imap server. When thunderbird checks for new messages it 
just does a FETCH since the inbox was already SELECTed at startup. It 
does not detect new messages unless another mailbox is SELECTed and 
inbox is re-SELECTED and then FETCHed. I think thunderbird is following 
the IMAP spec but charter.net server is not since it requires a 
re-SELECT on and already selected mailbox to signal new email. Am I right?

-gene

Didn't the old UW IMAP server act that way with certain mailbox formats?
It locked the mailbox and it couldn't receive new mail.

In any case, I don't think the spec precludes implementing it that way, but
it's certainly not the normal implemention.

Brandon

On Feb 18, 2017 1:52 PM, "Gene Smith" <gds@chartertn.net> wrote:

> I have been seeing a problem with mozilla Thunderbird client when using
> the charter.net imap server. When thunderbird checks for new messages it
> just does a FETCH since the inbox was already SELECTed at startup. It does
> not detect new messages unless another mailbox is SELECTed and inbox is
> re-SELECTED and then FETCHed. I think thunderbird is following the IMAP
> spec but charter.net server is not since it requires a re-SELECT on and
> already selected mailbox to signal new email. Am I right?
>
> -gene
> _______________________________________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20170218/2fba8ecf/attachment.html>

The charter IMAP server is openwave according the login response. So are 
you saying it is OK for the IMAP server to require a new SELECT before 
doing a FETCH on an already selected mailbox for the FETCH response to 
indicate new email? If so, this is a bug in thunderbird.

I have noticed that at least one client (kmail) always does SELECT and 
FETCH when checking for new mail (even when inbox is already selected). 
However, thunderbird and claws-mail only do a FETCH and don't re-do the 
SELECT and, therefore, don't detect new mail unless another folder is 
looked at first and then inbox is returned to.

-gene

On 02/18/2017 05:00 PM, Brandon Long wrote:
> Didn't the old UW IMAP server act that way with certain mailbox 
> formats?  It locked the mailbox and it couldn't receive new mail.
>
> In any case, I don't think the spec precludes implementing it that 
> way, but it's certainly not the normal implemention.
>
> Brandon
>
> On Feb 18, 2017 1:52 PM, "Gene Smith" <gds@chartertn.net 
> <mailto:gds@chartertn.net>> wrote:
>
>     I have been seeing a problem with mozilla Thunderbird client when
>     using the charter.net <http://charter.net> imap server. When
>     thunderbird checks for new messages it just does a FETCH since the
>     inbox was already SELECTed at startup. It does not detect new
>     messages unless another mailbox is SELECTed and inbox is
>     re-SELECTED and then FETCHed. I think thunderbird is following the
>     IMAP spec but charter.net <http://charter.net> server is not since
>     it requires a re-SELECT on and already selected mailbox to signal
>     new email. Am I right?
>
>     -gene
>     _______________________________________________
>     Imap-protocol mailing list
>     Imap-protocol@u.washington.edu <mailto:Imap-protocol@u.washington.edu>
>     http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>     <http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20170218/398e1ecc/attachment.html>

You shouldn't have to reselect, and doing so is really inefficient on some
servers, so I wouldn't recommend it as the default mechanism.

Seems like for this server there is no benefit to keeping the connection
open.

I would consider a modern server which does this as pretty broken, but it
may not violate the spec.

On Feb 18, 2017 2:29 PM, "Gene Smith" <gds@chartertn.net> wrote:

> The charter IMAP server is openwave according the login response. So are
> you saying it is OK for the IMAP server to require a new SELECT before
> doing a FETCH on an already selected mailbox for the FETCH response to
> indicate new email? If so, this is a bug in thunderbird.
>
> I have noticed that at least one client (kmail) always does SELECT and
> FETCH when checking for new mail (even when inbox is already selected).
> However, thunderbird and claws-mail only do a FETCH and don't re-do the
> SELECT and, therefore, don't detect new mail unless another folder is
> looked at first and then inbox is returned to.
>
> -gene
>
> On 02/18/2017 05:00 PM, Brandon Long wrote:
>
> Didn't the old UW IMAP server act that way with certain mailbox formats?
> It locked the mailbox and it couldn't receive new mail.
>
> In any case, I don't think the spec precludes implementing it that way,
> but it's certainly not the normal implemention.
>
> Brandon
>
> On Feb 18, 2017 1:52 PM, "Gene Smith" <gds@chartertn.net> wrote:
>
>> I have been seeing a problem with mozilla Thunderbird client when using
>> the charter.net imap server. When thunderbird checks for new messages it
>> just does a FETCH since the inbox was already SELECTed at startup. It does
>> not detect new messages unless another mailbox is SELECTed and inbox is
>> re-SELECTED and then FETCHed. I think thunderbird is following the IMAP
>> spec but charter.net server is not since it requires a re-SELECT on and
>> already selected mailbox to signal new email. Am I right?
>>
>> -gene
>> _______________________________________________
>> Imap-protocol mailing list
>> Imap-protocol@u.washington.edu
>> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20170218/c54cf5e9/attachment.html>

On 18 Feb 2017 at 17:29, Gene Smith wrote:

> The charter IMAP server is openwave according the login response. So
> are you saying it is OK for the IMAP server to require a new SELECT
> before doing a FETCH on an already selected mailbox for the FETCH
> response to indicate new email? If so, this is a bug in thunderbird. 

One of the major reasons IMAP has such detailed provision for unsolicited 
responses is so that the server can report the arrival of new messages in a 
mailbox *without* the client having to re-select it. Depending on the back-end, 
SELECT can be a fantastically "expensive" operation, and even on servers 
where it's well-optimized, it's probably going to incur significant overhead.

Speaking without any pretence of being authoritative, I'd say that if the only way 
the server can report new messages in a mailbox is through reselection, then it's 
broken, if only because there's no way for a client to learn procedurally that 
that's what the server wants.

In my own client code, I issue periodic NOOP commands and expect to see new 
messages reported as part of the response sequence to that command: that's 
how I would have expected most clients would do it.

Cheers!

-- David --

------------------ David Harris -+- Pegasus Mail ----------------------
Box 5451, Dunedin, New Zealand | e-mail: David.Harris@pmail.gen.nz
           Phone: +64 3 453-6880 | Fax: +64 3 453-6612

Real newspaper headlines from US Papers:
   "Thieves steal burglar alarm".

Surely a noop should work to cause an update?





On Sun, 19 Feb 2017, at 09:36, Brandon Long wrote:

> You shouldn't have to reselect, and doing so is really inefficient on
> some servers, so I wouldn't recommend it as the default mechanism.
> 

> Seems like for this server there is no benefit to keeping the
> connection open.
> 

> I would consider a modern server which does this as pretty broken, but
> it may not violate the spec.
> 

> On Feb 18, 2017 2:29 PM, "Gene Smith" <gds@chartertn.net> wrote:

>> The charter IMAP server is openwave according the login response. So
>> are you saying it is OK for the IMAP server to require a new SELECT
>> before doing a FETCH on an already selected mailbox for the FETCH
>> response to indicate new email? If so, this is a bug in thunderbird.
>> 

>>  I have noticed that at least one client (kmail) always does SELECT
>>  and FETCH when checking for new mail (even when inbox is already
>>  selected). However, thunderbird and claws-mail only do a FETCH and
>>  don't re-do the SELECT and, therefore, don't detect new mail unless
>>  another folder is looked at first and then inbox is returned to.
>> 

>>  -gene

>> 

>>  On 02/18/2017 05:00 PM, Brandon Long wrote:

>>> Didn't the old UW IMAP server act that way with certain mailbox
>>> formats?  It locked the mailbox and it couldn't receive new mail.
>>> 

>>> In any case, I don't think the spec precludes implementing it that
>>> way, but it's certainly not the normal implemention.
>>> 

>>> Brandon

>>> 

>>> On Feb 18, 2017 1:52 PM, "Gene Smith" <gds@chartertn.net> wrote:

>>> 

>>>> I have been seeing a problem with mozilla Thunderbird client when
>>>> using the charter.net imap server. When thunderbird checks for new
>>>> messages it just does a FETCH since the inbox was already SELECTed
>>>> at startup. It does not detect new messages unless another mailbox
>>>> is SELECTed and inbox is re-SELECTED and then FETCHed. I think
>>>> thunderbird is following the IMAP spec but charter.net server is
>>>> not since it requires a re-SELECT on and already selected mailbox
>>>> to signal new email. Am I right?
>>>> 

>>>>  -gene

>>>>  _______________________________________________

>>>>  Imap-protocol mailing list

>>>> Imap-protocol@u.washington.edu

>>>> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol

>> 



> _________________________________________________

> Imap-protocol mailing list

> Imap-protocol@u.washington.edu

> http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol



--

  Bron Gondwana

  brong@fastmail.fm


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20170219/fac5e25f/attachment.html>

On 02/18/2017 06:12 PM, David Harris wrote:
> On 18 Feb 2017 at 17:29, Gene Smith wrote:
>
>> The charter IMAP server is openwave according the login response. So
>> are you saying it is OK for the IMAP server to require a new SELECT
>> before doing a FETCH on an already selected mailbox for the FETCH
>> response to indicate new email? If so, this is a bug in thunderbird.
>
> One of the major reasons IMAP has such detailed provision for unsolicited
> responses is so that the server can report the arrival of new messages in a
> mailbox *without* the client having to re-select it. Depending on the back-end,
> SELECT can be a fantastically "expensive" operation, and even on servers
> where it's well-optimized, it's probably going to incur significant overhead.
>
> Speaking without any pretence of being authoritative, I'd say that if the only way
> the server can report new messages in a mailbox is through reselection, then it's
> broken, if only because there's no way for a client to learn procedurally that
> that's what the server wants.
>
> In my own client code, I issue periodic NOOP commands and expect to see new
> messages reported as part of the response sequence to that command: that's
> how I would have expected most clients would do it.

Thunderbird sends a NOOP when get mail timer expires on "get new mail" 
button is clicked, before doing the FETCH. However, the charter IMAP 
server always just responds with "OK NOOP completed" and provides no 
additional update info even when new email is definitely present on the 
server.
(Note: other IMAP servers that I access with thunderbird have no 
problem, e.g., gmail, yahoo, and cyrus.)

-gene

On 02/18/2017 05:44 PM, Bron Gondwana wrote:
> Surely a noop should work to cause an update

I don't see thunderbird sending periodic NOOPs when idle. But I will 
check again...
.

On 02/18/2017 05:56 PM, Gene Smith wrote:
> On 02/18/2017 05:44 PM, Bron Gondwana wrote:
>> Surely a noop should work to cause an update
>
> I don't see thunderbird sending periodic NOOPs when idle. But I will
> check again...

Tb does send NOOP in response to the get new mail timer or if get mail 
is clicked. However, charter server only returns OK, thank you and 
provides no unsolicited info, even when new email is definitely present 
in INBOX.

-gene