Re: [Imap-protocol] Is SELECT required before FETCH to detect new mail?

Gene Smith <[email protected]> Sat, 18 Feb 2017 17:29:04 -0500
Newsgroups gmane.mail.imap.general
Message-ID <[email protected]>
This is a multi-part message in MIME format.
--===============6283734124191832029==
Content-Type: multipart/alternative;
 boundary="------------95AE1D1C7304B99FDF487AF0"

This is a multi-part message in MIME format.
--------------95AE1D1C7304B99FDF487AF0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

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" <[email protected] 
> <mailto:[email protected]>> 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
>     [email protected] <mailto:[email protected]>
>     http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
>     <http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol>
>


--------------95AE1D1C7304B99FDF487AF0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">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.<br>
      <br>
      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.<br>
      <br>
      -gene<br>
      <br>
      On 02/18/2017 05:00 PM, Brandon Long wrote:<br>
    </div>
    <blockquote
cite="mid:CABa8R6tLdckvJ9c-UHHijbvJ95fBGBN41fxhypO1yWzt0tGOMQ@mail.gmail.com"
      type="cite">
      <div dir="auto">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.
        <div dir="auto"><br>
        </div>
        <div dir="auto">In any case, I don't think the spec precludes
          implementing it that way, but it's certainly not the normal
          implemention.</div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">Brandon</div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Feb 18, 2017 1:52 PM, "Gene Smith"
          &lt;<a moz-do-not-send="true" href="mailto:[email protected]">[email protected]</a>&gt;
          wrote:<br type="attribution">
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">I have
            been seeing a problem with mozilla Thunderbird client when
            using the <a moz-do-not-send="true"
              href="http://charter.net" rel="noreferrer" target="_blank">charter.net</a>
            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
            <a moz-do-not-send="true" href="http://charter.net"
              rel="noreferrer" target="_blank">charter.net</a> server is
            not since it requires a re-SELECT on and already selected
            mailbox to signal new email. Am I right?<br>
            <br>
            -gene<br>
            ______________________________<wbr>_________________<br>
            Imap-protocol mailing list<br>
            <a moz-do-not-send="true"
              href="mailto:[email protected]"
              target="_blank">[email protected]</a><br>
            <a moz-do-not-send="true"
              href="http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol"
              rel="noreferrer" target="_blank">http://mailman13.u.washington.<wbr>edu/mailman/listinfo/imap-prot<wbr>ocol</a><br>
          </blockquote>
        </div>
      </div>
    </blockquote>
    <p><br>
    </p>
  </body>
</html>

--------------95AE1D1C7304B99FDF487AF0--

--===============6283734124191832029==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman13.u.washington.edu/mailman/listinfo/imap-protocol
--===============6283734124191832029==--