wasm-demo/demo/ermis-f/imap-protocol/cur/1600094983.22553.mbox:2,S

38 lines
1.6 KiB
Plaintext

MBOX-Line: From blong at google.com Sat Feb 18 14:00:05 2017
To: imap-protocol@u.washington.edu
From: Brandon Long <blong@google.com>
Date: Fri Jun 8 12:34:55 2018
Subject: [Imap-protocol] Is SELECT required before FETCH to detect new
mail?
In-Reply-To: <bb8d0ae1-dda0-dbce-186a-2a668946ec7b@chartertn.net>
References: <bb8d0ae1-dda0-dbce-186a-2a668946ec7b@chartertn.net>
Message-ID: <CABa8R6tLdckvJ9c-UHHijbvJ95fBGBN41fxhypO1yWzt0tGOMQ@mail.gmail.com>
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>